After three decades working in IT, I’ve noticed persistent peculiarities in how people deal with security oversight. It doesn’t matter if it’s a small mom-and-pop shop or the largest of corporations — the same behavior exists. And it’s the driving force behind so many unnecessary risks and subsequent data breaches.

The root of the problem lies in overreliance on security policies — or, really, paperwork. There’s so much credence given to security documentation that it often blinds leadership to how things actually work in and around IT. Those in charge of security make the effort, management sees action, security audits come up clean and all is well with security — or so it seems.

Why Security Policies Alone Won’t Protect Your Enterprise

Those who rely too heavily on security policies often go to great lengths to put their documentation in place. It looks very professional and appears to cover all the right areas, including:

• Acceptable usage;
• Data backups;
• Passwords;
• System maintenance and patching;
• Mobile computing; and
• Travel.

These policies typically go into great detail outlining scope, relevant roles and responsibilities, and even sanctions for when they’re violated. Sometimes the policies are active — meaning that IT and security teams document and communicate them, but nothing’s really happening behind the scenes.

Take, for instance, a typical password policy. I don’t believe I’ve ever reviewed a password policy that goes beyond internal Windows domain accounts. The scope of the policy may claim otherwise, but the devil’s in the details. When looking at network infrastructure devices, applications, databases, mobile devices and so on, policy standards are all over the place.

Some policies are enforced, and some are not. Some are out of the scope of oversight altogether. The same can be said for security event logging and monitoring, data classification and retention, and other critical areas that can quickly introduce risks or otherwise be exploited, leaving the business in a lurch.

Skimming the Surface

In my virtual chief information security officer (CISO) consulting, I work with startups and smaller businesses that often must conform to the various security requirements of highly regulated industries, such as from the Payment Card Industry Security Standards Council (PCI SSC), Commodity Futures Trading Commission (CFTC) and Securities and Exchange Commission (SEC).

Some of these companies have extremely well-crafted security documentation. On the surface, the security policies and procedures I review create the illusion that the business’ cyberdefense strategy is larger and much more advanced than it really is. It also creates what I think is an undue burden on IT and security staff in terms of rising to that level of security and meeting the obligations that have been committed. This is problematic not only because it creates a false sense of security, but it makes it look like that security is being properly addressed even when little to no controls exist.

The problem in this scenario, as well as countless others, is that legal counsel, compliance officers and other parties are writing these policies without involving the very people who are doing the security work. Such documentation is often thrown together at the last minute to look good for an upcoming audit, to meet customer or business partner requirements, or to land big business deals. They’re either drafted internally or downloaded from the internet with little to no customization based upon the business’s unique risks, needs, culture and so on.

Much of this is just businesses putting the cart before the horse by documenting how things work before understanding them. It’s also related to a lack of security operations reviews or formal information risk assessments, including proper vulnerability and penetration testing.

You can’t address — or secure — what you don’t acknowledge. You wouldn’t even know how to address the various areas of IT without fully understanding how they all work and where the opportunities for improvement exist. Still, that’s how many security policies live and grow.

Where Security Policies and Practice Meet

The trend of policies for their own sake is nothing new. I recall back in the 1990s, when the World Wide Web was just taking off, attempting to create a set of rules around internet access for a school system that I was taking online. We in the IT department knew what the boundaries were, but administrators, teachers and students had no clue what to expect. We were living in our own world in IT and expecting everyone to keep up. We assumed that everything was locked down and secure simply because we said so.

If you’re going to have a resilient information security program that truly minimizes IT risk over the long term, you’ll have to drink your own Kool-Aid. It’s as simple as that. Document the rules, but make sure you follow up on their adherence with regular, meaningful audits.

For security policies to be followed, they must be known and enforced wherever possible and reasonable. If your users can’t follow your policies due to business process conflicts, or you can’t enforce the rules due to a lack of technology or another shortcoming you’re unwilling to mitigate, then you’re probably better off not having them at all.