I’ve spent a lot of my career in highly regulated environments, which means I have spent a TON of time reading various compliance requirements. Of course, that also means I’ve had to figure out how to meet those requirements, as well. In much of my career, this sort of activity was thrust at me with little to no notice. As in… the auditors are in the conference room and they’d like you to answer these questions. Needless to say, that was never fun and I have made it one of my professional goals to never have that type of thing happen to me again.
That’s all well and good… but you can’t stop the auditors from coming. So, how do you prepare? The answer is to work with your internal partners in the business to find out what is expected of IT and IT Security. This can come from discussions about upcoming audits, specific regulatory requirements within the company’s vertical, or contractual requirements by critical third parties. Without these discussions, you’re in for some surprises. So, you’ll want to understand where the compliance focus should be.
Often times, folks getting started in GRC can easily identify the core compliance requirements. For example, a retail organization accepts a ton of credit card data and will most likely need to be PCI compliant. A healthcare org will need to focus on HIPAA. A service provider will need to look at SOC2. A manufacturer, especially in Europe, may need to look at ISO 27001. Other times, this info can be hard to identify or an org could need to comply with multiple. So, where do you begin?
I typically tell people that they have two ways to quickly get started with a security framework. First, if the organization has a deadline to meet, just go with that. For example, if there is a contractual obligation to be PCI-DSS compliant by a set date, you should probably settle on that framework as a starting point. Other times, you may have no such pressing matter. In that scenario, I tell folks to start with a framework that covers a lot of ground… many controls that apply across the organization. Things that might typically fit this bill would be NIST CSF or CIS. The challenge with some frameworks is that they may have a limited scope. For example, much of PCI is focused on the part of the organization that handles credit card data, which in some orgs could be fairly small.
I typically recommend organizations leverage the NIST Cybersecurity Framework. The reason is that the NIST CSF is fairly broad and should cover an organization’s complete security program, as opposed to a particular product they make or a small section of the environment. Additionally, the NIST CSF provides organizations to some flexibility in how they implement the required controls. This is in contrast to certain other frameworks, like CIS. While CIS is a fantastic framework, it usually requires too many specific controls for organizations on the lower side of the maturity scale to implement, leading to the review of a lot of controls that just won’t exist. It would be like testing me in calculus when I have no intention of going beyond basic addition and subtraction: I’ll get a lot of red ink with no real value.
Tons of resources exist around the NIST CSF today, including from NIST themselves. Here’s a short list of resources you may want to check out as you get started:
- NIST CSF
- Security Checkbox – the site allows organizations to pull CSVs of common frameworks, including the NIST CSF
Later in this series, we’ll talk about other aspects of GRC, including controls. Until then, best of luck!