Don’t Let Misguided Security Documentation Create Unnecessary Risks

Published On October 25, 2019

When it comes to information security and managing a resilient network environment, simplicity trumps complexity. Many IT and security leaders believe just the opposite — that more security “stuff” translates into lowered risks. This is especially true of security documentation. Most organizations have policies and related documents that give the illusion that all is under control in IT — the more documentation, the greater level of perceived security. In many situations, though, this couldn’t be further from the truth.

The Real Deal With Security Documentation

The interesting thing about security policies and procedures, disaster recovery plans and the like is that they often say one thing while the day-to-day operations show quite the opposite. It’s not difficult to create security ground rules and processes to call upon. You can go online and download someone else’s policies, or purchase a canned set to customize. However, it’s more difficult to put that documentation into practice. Business culture and politics dictate how security functions more than any document can. When executive management does not fully buy into IT and information risk-related initiatives, it can create widespread security challenges with no real solutions.

During security audits, documentation can create a façade of proper risk management, giving a false sense of security that the business is immune to external attacks against web applications, gullible users giving up their login credentials and missing patches that facilitate ransomware infections. It’s just not that simple. Security documentation is not what gets hacked — it’s weak systems, people and processes. It’s not futile to create a reasonable set of security documentation, you just can’t rely on it to ensure protection as so many organizations do. Your documentation is there to provide general guidance.

Security Policies Done the Right Way

Another common mistake made with security policies is to put them in place without fully understanding the risks. The main purpose of policies is to convey “this is how we do things here.” Policies should be written based on known risks — both confirmed and potential — to your specific organization, and should outline the following:

• Specific objectives
• Organization rules
• Disaster recovery plans
• Incident response plans

These policies should be included in business agreements and employee handbooks. They should be clear, concise, well-thought-out and used in day-to-day operations. Each policy should also be accompanied by procedures that aid implementation, and shared with employees, contractors and executive management. Anything less will hurt rather than help the organization.

The last thing your business needs is security documentation that promotes a standard that can’t be met. If you say you’re doing something in the context of security, then make sure you’re doing it. No policy is better than one that’s not enforceable or not being enforced. For documentation to be an effective component of your security program, ensure that executive management is on board with all security-related initiatives, especially the approval and enforcement of security policies. Ideally, this would come in the form of a small, yet diverse security committee that represents the organization well.