5 ways compliance hurts security

Most of us in the IT security business know that compliance isn’t the same as security. Compliance is an auditing, paperwork, checklist mentality. Security is a tactical, real-world cybersecurity, risk-reduction mentality. Compliance is “Do you have a patch management program that applies critical patches in a timely manner — yes or no?” Security is figuring out which patches to apply and when, applying those critical patches, and then re-verifying those patches are applied. One helps you pass an audit. The other actually secures you.

Both are supposedly working at the same goal: to reduce cybersecurity risk. But compliance is so, so much worse at it that I’m not sure it does much to reduce real risk at all. Here are five reasons why:

1. Compliance is binary

Security risk is not binary, but compliance is about binary questions and answers, yes or no. Do you or don’t you do such and such? It doesn’t allow a lot of room for outside-the-box thinking or even stronger, better security. For example, most compliance regulations require complex passwords that are eight characters or longer. Even though a 20-character, non-complex password is inarguably harder to crack and easier to use, you wouldn’t be able to use it in most organizations.

Another example, most regulations require a policy that locks out a user’s account after the password has been entered incorrectly a set number of times. If you require sufficiently long passwords, then you don’t need the account lockout policy and you would have lower risk.