Getting from 'Paper' Policies to Regulatory Compliance

I have lost count of the number of times I have stated the equivalent of; “Without good policies you’ll never have real security. “. Then again, security is what I do for a living, so it’s obvious to me, but clearly it’s not obvious to the thousands of organisations who think policies are just pieces of paper you use to tick a compliance box.

Then it occured to me that maybe organisations just don’t know how to take a policy and turn it into something that can be used to both demonstrate and validate adherence to a regulatory compliance regime such as GDPR or PCI. Or perhaps just as importantly, pass a due diligence audit for a potentially huge client.

It goes without saying that this would be a whole lot easier if the senior leadership was actively involved and you had a governance function to manage it, but this is so rarely the case that predicating the blog on them is pointless. I will instead assume you, the reader, are a ‘lowly’ IT/IS Manager/Director who has been tasked with getting your systems compliant with something.

Step 1: The first thing you do obviously is to find a policy set most appropriate to your needs. At a minimum, these should be:

  1. Comprehensive – must cover all aspects of information/data security, not just cybersecurity;
  2. Mapped to the framework of your choice – whether it be ISO 27001, NIST, or whatever, you must ensure the policy set has adequate coverage;
  3. Aspirational – there’s no continual compliance without it;
  4. Customised/Bespoke – These policies need to reflect YOUR business and its culture; and
  5. Available to all – no point having them if no one can find them.

Step 2: Run a risk assessment / security control gap analysis to ensure that the next step has the necessary detail and management sign-off for what the controls should be. In other words, ‘management’ must sign off on a risk appetite so that the controls put in place can meet or exceed it.

Step 3: With the help of subject matter experts (SMEs) from all relevant functions (e.g. systems admins, developers, DBAs, process owners etc.), define all relevant standards that support the policy’s intent. A standard is a detailed baseline for how something is to be configured/performed, should reflect industry good practice, and embody the accepted ‘control minimums’ established in the previous step.

Step 4: With the help of those who perform all functions, document the procedures required to implement and maintain all standards baselines. These are step-by-step instructions on how everyone is to perform a specific task in an identical fashion.

Step 5: Develop a list of ‘compliance measures’ that, when collected, represent sufficient evidence that not only are the above standards in place, but that procedures are being followed.

OK, that’s it, but this still doesn’t help, so here’s an example of what this actually looks like in the real world;

For Step 1: Go here for an example policy, and here for a mapping of that policy to both ISO 27001 and the PCI DSS v3.2.1.

For Step 2: How the risk assessment will run is entirely dependent on the organisation in question, but for the sake of argument, let’s say that the organisation’s BoD has mandated a LOW risk tolerance and that security controls must be demonstrably in-line with not only the ISO 27001 objectives, but established industry best practices.

For Step 3: Go here for a sample of an Authentication Standard that supports the above policy.

For Step 4: Go here for an example of a Procedure that enables part of the above Standard.

For Step 5: see Sections 3.1 of the above Policy and Standard for the ‘Compliance Measures’ that should cover the demonstration / validation requirements of whatever standard / regulation is to be covered. This ‘validation evidence’ could/should also be mapped to the regulatory standard in question, but I’m giving enough away as it is.

For those of you who need PCI compliance, this is how you manage the DSS’s ‘Testing Procedures’, and for those looking for ISO 27001 alignment/certification, this is how you provide the lead auditor the ‘records’ they require.

Most organisation will have 20-odd policies, 20 – 30 standards, and up to 50 or so procedures to support their security program. None of these documents is complicated, most of them aren’t event difficult to produce. The issue is that there is a LOT of work to do with little to no support from management, and no plan.

A good Policy Set and a good security consultant can help you put all of this in place. And even though it’s completely back-assward, the final results can be used to get senior leadership on-board thereby ensuring the program’s continued success.

It really doesn’t take much capital to get this program running, so there are very few excuses regulatory auditors will accept for not making a start.

[If you liked this article, please share! Want more like it, subscribe!]

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.