You can be compliant but not secure. You can be secure and not compliant. I submit to you that although they intersect, the two are quite different.
Compliance is a one-size-fits-all solution: it’s binary, you’re either compliant or you’re not.
Security however, is very local and it’s the little nuances that make the difference for your organization. Does your company value availability more than confidentiality? Or is data integrity what you care about most?
Sure, you could argue that a merchant that handles credit card data would care about confidentiality more than anything. But what if I told you that this merchant has a vendor portal where partners can log in, and those partners have less than optimal information security practices? And what if those partners got hacked, had their credentials stolen, and those credentials were used to move laterally within the merchant’s network and steal millions of credit card numbers? What then, huh?
In case you haven’t guessed, yes, I’m talking about the Target breach late last year.
Target was compliant, yet got breached. Why?
Well, technology moves faster than compliance documents can. Take heartbleed for example. If you were PCI compliant, but didn’t patch for heartbleed then you’re compliant but not secure. Not very useful.
I don’t want to sound like I’m saying that compliance (particularly PCI) is relatively useless. It’s definitely a step in the right direction, but that’s all it is. It’s a floor, a minimal security baseline. But when business units see compliance as the end result, it can do more harm than good to simply be compliant.