Matt Kelley


In many industries that have Information Security requirements, particularly Gaming, there is a commonly held misconception that compliance equals security. Not only is this idea wrong, it can lead many organizations to, pardon the pun, have a false sense of security.

“Our auditors found nothing remiss with our deployment of [insert system or application here].” Every time I hear this, or something similar, I cringe.

Compliance, as defined by Merriam Webster’s dictionary is: conformity in fulfilling official requirements. It is a set of specific things that are minimally required to operate your business.

Additionally, there is so much room for interpretation in some of these documents that you could realistically convince your auditor of almost anything!

The definition of hubris is: exaggerated pride or self-confidence.

The hubris of compliance is easy to locate, if you care to look.

As one example, in the current iteration of PCI-DSS, v3.2.1, requirement 2.4 states that you need to “maintain an inventory of system components that are in scope for PCI-DSS.” (Emphasis mine.)

Rather than taking greater security into account, the prevalent action is to simply move items and systems out of the Card Holder Data Environment, or CDE. Rather than have all of your organization’s system in scope for a compliance check, one simply segregates the area under scrutiny. The question though is, what about the rest of your environment?

For another, the National Indian Gaming Commission MICS audit checklist has a requirement for “adequate backup and recovery procedures in place,” which are “tested on a sample basis at least annually.”

Your auditors ask for proof of backups of all relevant systems and the ability to restore an example. Are you able to do so for more than the bare minimum, or are you playing with fire? Have you tested your domain controllers, the center of your operations or just the financial systems?

As you can see, there is plenty of room for maneuvering to meet the minimum requirements. Is that what your organization’s end goal should be though – a minimally viable business?

With all of that said, compliance is still important to your business. It is an attestation that you meet some specific and targeted minimum requirements. It should be viewed as a baseline only, not the desired goal.

Courtesy of iStock

It is relatively easy to become seduced by solutions or vendors that tout their ability to meet your compliance needs. The same goes for the Information Security domain. They are two sides of the same coin, with each facing a different direction. Janus, the iconic Roman god of beginnings and endings is an example of this. We should look backward at compliance as something already met and surpassed, look forward to better security that we have yet to attain.

I have personally had vendors, either prospective or long-term, tell me that this one solution will satisfy everything I need. “You can get rid of system Z and just use this!”

First of all, if you hear a similar thought from someone who does not know your environment intimately, be wary. Second, there could be some forgotten “compliance” reason for that system to be there in the first place. As an example, if you are a HIPAA compliant facility, such as a mixed responsibility Tribal organization, you are running a certified SCAP application. You would also know that there are only 14 companies that meet those requirements set by the government.

That list, maintained by NIST’s Computer Security Resource Center (CSRC), is not long.

We have so many compliance areas to satisfy, particularly in a Tribal organization, that it can be overwhelming. If compliance itself is a difficult goal to achieve, how can we manage a tougher destination, that of better overall information security? How can we differentiate between the two states of being?

As I have mentioned in previous Gaming & Leisure articles, NIST’s Cybersecurity Framework (CSF) provides excellent guidance and is also mapped to other common compliance documents such as ISO 27001, HIPAA and more.

Frameworks are your friend. You should hold them near and dear because they will help you maintain better security through targeting your efforts to that versus multiple compliance areas at varying times.

However, as Information Security professional Jerry Bell discussed in this tweet, frameworks are imperfect.

Information Security is difficult because it seems to never reach an end, a conclusion to all of the effort. The industry always seems to move the goal posts; aim for compliance, but don’t stop there! Follow your framework, but that isn’t quite enough!

Both statements are true, but that doesn’t make it any easier to do.

What about that infamous fish tank? How was that able to access player data or other information?

So, compliance does not equal security, and security does not always meet compliance. How are you, as an executive, supposed to manage these nebulous expectations and sometimes opposing details?

This is the time and space in which you rely on your teams: security, compliance and your auditors. If you leave them to work in a void, absent of each other’s context and end goals, you will get disparate and sometimes divergent results, none of which serves your organization.

Compliance should bring together your requirements as a problem to solve. Security should provide solutions to these that are within the means of the business. Audit should then be able to verify that the solution works and can be verified. Rinse and repeat as needed.

From my own experiences, it is much better to focus on initiatives, such as compliance, in ways that can be attained and sustained. Compliance is useless if you do not have a plan or process in place to maintain it.

My advice regarding compliance would be to view your organization from above and see what your external pressures are, and how they affect the core of your business.

Do you have international customers from maybe Europe or Canada? Have you analyzed GDPR and the new breach law in Canada?

You perform your annual audits, but have you mapped any of your financial data to the relevant IRS publication?

If you’re part of a Tribal organization, have you considered the federal requirements on information security in dealing with the government and its agencies?

Once you identify all of your applicable compliance areas, it becomes easier to maximize the impact in meeting all of them at once, one technological or administrative area at a time. This is possible after you have mapped each to a central framework, such as the NIST CSF. As an example, data retention and restoration appear in almost every compliance document I have seen. Why would you meet the requirements of one, then assess another to repeat the process? It makes more sense to find your minimally acceptable baseline across the entire compliance portfolio and base your efforts on that standard.

If you are able to calculate the difference between your current posture and where compliance dictates that you be, your teams can come up with a strategy to make achievable goals that are acceptable to the business.

Once you are able to match up your policies and procedures, you now have a sustainable position.

My final thought is that compliance is a measurement, a singular state at a point in time. Maintaining that state is a process. Proclaiming that you are compliant and being satisfied with that is pure hubris. It would be the same as me stating that I am an average height male – it doesn’t really mean a whole lot.

Compliance is great for what it is, but strive to be better.

Matt Kelley, CISSP, is the IT Manager for a Tribal organization that supports Gaming and Government operations. He is also the co-founder of Korr Group, a business venture that aims to improve the Information Security of small businesses and nonprofit organizations. Matt started out in the infrastructure side of technology nearly 20 years ago, and has found his calling in Information Security, specifically GRC. To stay current with Matt, he can be followed @kelley12matt or on his blog at