I sat in a presentation recently where the words “regulatory compliance” were used no less than 27 times across 45 PowerPoint slides. I’ve even found myself using the term in meetings more times than should be legally allowed, and rarely a day passes where “regulatory compliance” is not written within an email or seen in a document or uttered in the men’s room.
Similarly, never have so many consultants been able to rub their hands together in glee as we are bombarded by an ever increasing need for RC (as I shall now refer to it), and the requirement for us to be audited, checked, tested, and examined most intimately all in the name of proving compliance. Even within the business we are subjecting ourselves to more audits all in the name of RC. SOX, PCI, HIPPA, GLBA…the list of acronymns is growing at a rate where more of us are demonstrating our knowledge of RC by virtue of the number of different acronyms we can drop into casual conversation. Those of us with the greatest knowledge can even use RC related humour (“how many SOX consultants does it take to change a lightbulb? ” etc etc).
What does RC really mean? And are we becoming so obsessed with RC that we are forgetting what it’s really all about and treating it as an exercise to get all the right boxes checked as cheaply and quickly as possible? In fact, look at any of the RC standards and they are simply addressing those three basic tenets of information security: The confidentiality, integrity, and availability of data. Looked at in this way, RC should not be a difficult exercise – if you’re struggling then you’re probably failing to address the basics. And if that’s the case then RC has not come a moment too soon for you.
Where I think we have the most difficulty is where the RC bodies fail to make it clear exactly what they mean with some of the language that they use. Take clause 6.3.2 of the PCI data security standard: “Separate development, test, and production environments”. What do they mean? Logical, or physical separation? What if we’re talking about a small business that integrates its development and test environments: not best practice for sure but certainly not unusual – can they still be PCI compliant? The associated audit procedures provide no additional guidance for auditors: it’s a black or white answer. Similarly, a SOX auditor recently requested of one business I’m aware of to see evidence of information security employee qualifications. What, I ask, does that have to do with mitigating risk? Particularly as in the case concerned the audit overall had been successful, thus demonstrating good management practices being in place.
It strikes me that consultants are being given carte blanche by RC bodies to act like the RC police with the potential for businesses to suffer unnecessary financial and resource burden as a result. What we need is clarity in the questions being asked and clarity as to what the acceptable solutions are. Then, for the consultants whom our businesses are being forced to pay, enough detail to ensure that their questions (and answers) are consistent with good practice and common sense.
That’s 13 mentions of “regulatory compliance” (now 14) in a single blog. Is this a record?