A Five-Step Approach to Compliance With Any Cybersecurity Framework

ISO, SOC, GDPR, NIST: A customer/VC/partner/regulator asked if you were “compliant” to any of these, then mentioned some buzzwords you never heard of. You nodded and started Googling frantically. There were lots of ads, lots of promises…but you’re still not sure how to translate this to your “next steps” to close that deal or get that person on board.

To make it easy for you, here it is, in bullet form; The Five Steps you need to take:

1. Figure out what framework you need to comply with
2. Get familiar with the framework
3. Figure out what gets affected
4. Set up “controls” to enforce policies
5. Show an auditor your controls and get certificate of compliance

To be frank – this isn’t something to complete in an afternoon. It’s going to take an uncomfortable combination of time and money; The less money you want to spend, the more of your resources’ time it’s going to take. Compliance with cybersecurity frameworks is usually a combination of documentation and implementation steps: a collection of “one-offs,” a collection of not-so-frequent “few-offs,” and implementations of controls that will be in place from that moment continuously into the future. These two things are the ones where companies spend the most time and money.

The less time you want to spend on it, the more it’s going to cost to have somebody else spend that time. But no matter how much you spend, this process is always going to require some amount of your time.

Let’s go through these five steps in a little more detail:

Figure out what framework you need to comply with

Everybody has their own idea of how to show that your company is secure. Almost every country has their own idea. Many of the ministries or departments within that country also have their own ideas. Then the companies in that country have their idea, so they can show the country government branches et al that they’re secure, because they checked that you’re secure.

Then there’s the industry verticals: Financial services, Healthcare, Telecom, and Energy, all having different ideas of how you should show you’re secure. This is why there’s so many different security compliance standards, and why they all sound like a foreign language at first.

Ultimately, all frameworks have a common goal; monitoring and communicating to others that your organization is taking reasonable effort to ensure your systems and data are secure. That’s why, as you start to learn more about these things, they’ll start to look similar to each other. But they’re all special unique snowflakes!

Here’s a sentence or two on the ones we get asked about most often:

• ISO 270001: One of the older standards, it’s considered more of an “international” standard - that we see people ask about it more in Europe and Asia across different industries.
• SOC2: Created by accountants in the US to show that the information coming out of systems is reliable for financial reporting and secure; mainly used in the US but we’re starting to see this standard being used by the Financial sector of English-speaking countries in the rest of the world.
• NIST cybersecurity framework: This standard has been well thought-out, like most NIST standards. A newer standard intended for the US, it borrows from the others and therefore is considered a good standard to comply to, as others are relatively easy to comply to afterwards. This might be the standard that most CISOs like
• PCI-DSS: This standard was developed by Visa and Mastercard to ensure that businesses (particularly e-commerce) handle credit card info securely.

So – somebody’s mentioned you need one of these things. Once you confirm which one, you can start working on satisfying that need!

Get familiar with the framework

Security frameworks are not anecdotal stories passed down on campfires by security geeks to each other; All of these frameworks are written down somewhere. We wouldn’t want to submit you to the pain of studying one of these frameworks, but the more familiar you become with the framework, the easier the compliance process will be.

Whatever framework you need to comply with, you can either download them or buy them. Best way to get started is get ahold of a copy of them.

When satisfying a compliance or security framework you’ll have to build a collection of “policies” that spell out how to secure your company. These policies could describe how complex your passwords are, how often your computer systems receive security updates, how do your backup and store data…really anything that has some relationship to the confidentiality, integrity, and availability of computer systems as well as employees in your company. Some compliance standards specify what those policies are in detail, others are very vague and leave it to each company to interpret and implement. One of the things cysense can help with is figuring out what this policy is for your company.

Once you have that policy, you need to figure out what things in your company are affected by it.

Figure out what gets affected

Now that you have this policy document filled with lots of “shoulds” and “musts,” the question is what items in your company are “in scope?"

For a small startup, this is easy; just about every computer and employee will be subject to the compliance policies. For a large enterprise – often those guys have a hard time just keeping track of their computers! Either way, the scope is determined by the compliance standard:
PCI cares more about systems and staff that may touch credit card information.
SOC2 cares more about systems and staff related to financial reporting and data integrity, although it definitely touches almost all your IT resources.
ISO and NIST standards have a wider scope, are more procedural in nature, but encompass many of your resources and processes.

Closer to enlightenment - you understand the scope, you can start creating “controls” to ensure the policy requirements are met.

Set up “controls” to enforce policies

A policy is a human-readable document that describes what you are trying to ensure the security of, and how. We all have better things to do than check by hand that a policy is being followed, so we automate these things where we can. When we have a policy item, and a list of computers that policy affects, we can gather information from those computers and then write some computer logic to ensure that the computers are doing what the policy asks for. This is called a control.

On average, our customers have between 100-200 controls – that’s a lot of things you’d have to do by hand!

Now you just need to convince that person of interest that you have all this stuff working and they’ll become a customer or partner. You’re so close!

Show an auditor your controls and get certificate of compliance

The final step is one we get a lot of questions about: Prove to your customers that you’ve done all this great policy and control work – and that it’s keeping you secure. But…how? You can’t expect a customer to just trust what you say. This is where an auditor (firm or individual) comes in. This is an independent, reputable third party who will review your policies and then ask for examples of your controls working – all with an eye to answer the question of if you are compliant with the compliance standard selected. There is a cost involved, but usually it doesn’t take more than a few days.

We are often asked if we can audit the controls of our customers and give them a certificate. We can provide them with an outside view or something called “an internal audit,” but that is to ensure they are ready for the official audit.

While doing an audit on our own work and providing a certificate would make things easier, we may consider it a conflict of interest: As your company cannot audit its own controls because your customer wouldn’t trust that, we cannot audit the policy or controls we provide you, as it’s in our best interest to say everything looks great and you’re secure. The audit really should be done by an unbiased third party. We’re happy to make recommendations, or you can source one independently from us.

Technically, this isn’t really the final step. Because things change, people change, businesses change, the environment changes, and also regulation changes, every year (or quarter, or several years), you’ll have to talk to the auditor again and have them re-certify the effectiveness of your security program.

Ending Note

See? That’s it! Easy! 😁 In seriousness, it’s not that bad. We’ve helped many companies through this process, and we know how to make it easy for you. Sign up for free today to get started!