Compliance has got to be one of the dullest topics in cybersecurity. Let’s face it, there’s very little to get excited about because, despite all the positive spin from marketing people, most still view it essentially as a tick-box exercise. It doesn’t matter which compliance regulation you talk about — GDPR, HIPAA, FISMA, PCI, SOX, GLBA, you name it — each gets a collective groan from businesses whenever it arises on the agenda.
The whole tick-box exercise is one reason compliance is dull, the other reason is the sheer language itself that compliance uses to express itself. Compliance requirements have a knack of being poorly written, vague, verbose and confusing. As far as I’m concerned, most of the confusion around compliance stems from the writing, so it’s no reason organizations struggle, especially when they need to comply with multiple requirements simultaneously.
Smothered by poor writing
Let’s look at ISO 27001, for example, which aims to improve an organization’s information security management. It has a six-part process, which include commands like “define a security policy”, “conduct a risk assessment” and “manage identified risks”. The requirements for each of these are incredibly sketchy and unhelpfully subjective.
The Sarbanes-Oxley Act (SOX), which covers all businesses in the US is no better. Section 404 vaguely states that all publicly-traded organizations demonstrate “due diligence” in the disclosure of financial information, but then does not explain in any great detail as to what constitutes “due diligence”.
The Gramm-Leach-Bliley Act (GLBA), which requires US financial institutions to explain information-sharing practices to their customers, states financial organizations must "develop a written information security plan” but doesn’t offer advice on how to do that.
HIPAA, which applies to US healthcare organizations, is slightly clearer but still states the likes of “policies are required to address proper workstation use”.
Even Lexcel in the UK, which is written by lawyers for lawyers, is unclear: "Practices must have an information management policy with procedures for the protection and security of the information assets."
For a profession that prides itself on being able to uphold watertight clarity, I’m surprised Lexcel allows this sort of subjectivity within its compliance requirements.
Writing for a wide audience isn’t easy, by any means
Look, I get it. Those writing compliance requirements have a tricky job on their hand. They’ve got to write something that’s applicable to all businesses within a particular field, each of whom will have their subtle differences in the way they do business and the way they’ve set up their technology infrastructure.
Not only have they got to write for such a wide audience, but writers also realize they’re up against the clock with regulation simply because of the pace of change with IT — and the requirements they write today may well be out of date come tomorrow.
However, I think those that write requirements should take a leaf out of the PCI DSS’s book. PCI DSS, which applies to all organizations that store cardholder data, is clear, regularly updated, and you can find everything you need to know in one place.
The way the PCI has structured its compliance (in terms of requirement, testing procedures and guidance) is much clearer than anything else I’ve seen, and contains very little room for subjectivity. You know exactly where you stand with it.
The GDPR, for all its sins, is also well written and detailed. The numerous articles referring to the protection of data are specific, practical, understandable and implementable.
For example, it is perfectly clear when it comes to data access: “Unauthorized access also includes accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of personal data transmitted, stored or otherwise processed” (Articles 4, 5, 23 and 32). It’s also clear when it comes to auditing processes: or “You need to maintain a record of data processing activities, including information on ‘recipients to whom the personal data have been or will be disclosed’ i.e. whom has access to data” (Articles 5, 28, 30, 39, 47).
So, while you’re surrounded by multiple compliance requirements barking orders at you, you undoubtedly need to have a strategy in place, which can get complex when you’re trying to adhere to multiple mandates. The trick is to find the commonalities between all of them, before coming up with your solution.
Before you do anything else, make sure you do the basics right
As far as I’m concerned, the sheer confusing nature of compliance just gives rise to the incessant bombardment of marketing material by vendors on “how you can be compliant with X” or the “top five things you need to know about Y”. With the GDPR deadline coming up, the sheer noise around compliance is deafening (despite the fact it’s actually one of the better-written ones).
The best place to start with a compliance strategy, though, is simply with the basics — data storage, file auditing and access management. Get these right, and you’re well on your way to demonstrating your willingness to comply.