Most compliance requirements are completely absurd

Compliance is probably one of the dullest topics in cybersecurity. Let’s be honest, there’s nothing to get excited about because most people view it as a tick-box exercise. It doesn’t matter which compliance regulation you talk about – they all get a collective groan from companies whenever you start talking about it.

The thing is, compliance requirements are often being poorly written, vague and confusing. In my opinion, the confusion around compliance comes from the writing, so it’s no surprise companies are struggling, especially when they have to comply with multiple requirements simultaneously.

Poor writing is smothering compliance regulations

Take ISO 27001 as an example. Its goal is to improve a business’ information security management and its process has six-parts, which include commands like “conduct a risk assessment”, “define a security policy” and “manage identified risks”. The requirements for each of these commands are extremely vague and needlessly subjective.

The Sarbanes-Oxley Act (SOX), which covers all businesses in the United States, is no better. Section 404 vaguely says that all publicly traded organizations have to demonstrate “due diligence” in the disclosure of financial information, but then it does not explain what “due diligence” means.

The Gramm-Leach-Bliley Act (GLBA) requires US financial institutions to explain information-sharing practices to their customers. It says financial organizations have to “develop a written information security plan”, but then doesn’t offer any advice on how to achieve that.

Even Lexcel (an accreditation indicating quality in relation to legal practice management standards) in the United Kingdom, which is written by lawyers for lawyers, is not clear: “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 maintain absolute clarity, I’m surprised Lexcel allows this type of subjectivity in its compliance requirements.

It’s not easy to write for such a wide audience

Look, I understand. It’s a pretty tricky job to write compliance requirements. It needs to be applicable to all organizations within a particular field, each of which will have their differences in the way they conduct business and how they’ve set up their technological infrastructure.

Furthermore, writers are working against the clock with compliance requirements. IT regulations are changing at such a quick pace that the requirements they write today might be out of date tomorrow.

However, I think those who write requirements should take the Payment Card Industry Data Security Standard (PCI DSS) as an example. The PCI DSS applies to all organizations that store cardholder data and the requirements are clear, regularly updated, and you can find everything you need in one place.

The way PCI DSS compliance is structured (in terms of requirement, testing procedures and guidance) is a lot clearer than anything else I’ve seen. It contains very little room for subjectivity, and you know exactly where you stand with it.

The GDPR is also pretty well written and detailed. The many articles referring to data protection are specific, understandable and implementable.

For example, when it comes to data access, this sentence is perfectly clear: “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 very clear when it comes to auditing processes: “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 faced with many compliance requirements, you need to have a good strategy in place. However, it can get complex when you’re trying to comply with multiple mandates. If I can give you one tip, it is to find the commonalities between all of them, before coming up with a solution.

You need to do the basics right

In my opinion, the confusing nature of compliance only spawns the relentless bombardment of marketing material from vendors on “how you can be compliant with X” or the “top five things you need to know about Y”.

You have to understand that at the core of any compliance mandate is the desire to keep protected data secure, only allowing access to those who need it for business reasons. This is why all you need to do with compliance is to start with the basics: data storage, file auditing and access management. Get those right, and you’re on your way to demonstrating your willingness to comply.