We read it everywhere: “compliance is not enough”.  “Security must be more than compliance.”  Granted.  When the phrase “checking the box” only means working from a compliance checklist and never looking at how your servers are configured, you are vulnerable.

When security professionals point this out, they are responding to the well intentioned attitude of one or more colleagues who are either too focused on compliance or too ready or willing to see it as a be all, end all.  These folks think that a set of industry standards or regulations are the equivalent of the definition of an effective security program.  And they’re just wrong.

But having said that, we tend to dismiss compliance and pigeonhole it into less than it can be as a principle of design for an effective security program.   To use the architectural metaphor often used to describe design: when you say compliance is a foundation, are you comparing it to an unadorned slab of concrete?  Because it really is more than that.  To follow through on the metaphor if your organization has the attitude that compliance is the window dressing (blinds) that keeps the sunlight (regulators) out then you have a bigger challenge ahead of you than I am addressing here.

Compliance can be a design principle.  But to be that, it cannot be marginalized.

Maybe Compliance gets marginalized because you are fighting those who want to do the bare minimum to pass an audit (they don’t get the point of protecting data) or because there are those in your organization who (secretly) bristle at the thought of obeying the rules (these are not those kind of rules).  But understating the value of the content of the regulations does not make for a strong program.  And it does not mean that compliance is less of a good input for designing a security program.

So, **on the 2^nd anniversary of this blog**, here are some things to consider about “compliance as a design principle”.

First of all, Data Protection standards and regulations were always created with input from experts like you.  Even if you feel the final reg has been mangled by being put in legalese, take the time to translate it back into what the security experts were trying to say.  Once I do that, my experience is that the regs fit nicely into what I think is appropriate anyway.  And this exercise helps immeasurably when talking to auditors because it demonstrates how seriously you take the regulations.

Secondly, remember the words of Bruce Rogers, a typographer (typographers were the predecessors of web designers) in the last century.  In his book Paragraphs on Printing, Rogers explains better than anyone I’ve ever found, how constraints put on us by others can be dealt with and capitalized upon (slightly modified):

One of the minor discouragements of any [security professional] is the occasional intrusion into [their security framework] of…stipulations by the [regulators] or others…Honest limitations as to cost, size, purpose, etc., should be duly accepted, and in fact a stimulation can often be found in the very limitation itself.  But there are times when the designer feels that his work is in danger of being spoiled by others, well intentioned though they may be.  It is at such times that he will require of himself much self-control, realizing that this is a problem that his fellows, great and small, have all had to face…He will find, if he remains calm and reasonable (and does not take himself too seriously) that in most instances he will emerge with a large part of his work untouched, and he will find that his own constancy will usually outwear these occasional interferences. (page 25, 1943, the gender biased pronouns left in for historical accuracy)

In other words, it is not enough to say “compliance is not enough”.  You have to take the compliance requirements and use them to your advantage in designing a program.  This is distinctly NOT by telling your enterprise “you gotta do it because the regs say so”.  That’s hiding behind the regs, not using them.  You know you are succeeding when you start referencing the requirements at times when you don’t have to, when you find you are complying with the spirit of a law and not just the letter.  A good example of where you will be hard pressed to find detailed regulatory requirements in most general data protection regs and standards but where they clearly apply: server hardening standards.

The HIPAA security rule, for example, does not specifically say you must have server hardening standards and enforce them.  Though you’d expect those standards to be part of the “technical safeguards” the rule calls for.

I am always surprised then when I hear someone ask with respect to any of the details of a security program “can you show me where it says we have to do that in the regs?”.    The more you’ve connected compliance to how you’ve designed your program, the easier it is to answer that question.