Not long ago, I was reading a debate on a Linkedin.com forum discussing all kinds of edge cases that some participants were arguing needed to be considered in a security policy regarding some particular aspect of security. In fact, I forget what the issue was, but it was clear that the folks in the discussion were losing sight of the big picture.
Information security is about managing risks. Security Policy is a written statement by management that provides high-level, directional guidance about how to manage the risk that is the topic of the policy. Policies are approved by executive management after they understand the policy, and how the countermeasures in the policy address the risks that the policy addresses. Risks can rarely be eliminated in entirety. Generally, the goal is to reduce the risks to an acceptable level. Therefore, if a security policy can address the majority of the information security risks with the exception of some edge cases—it is still a good security policy.
What about the edge cases that are still a concern? This is where a Security Policy Exception Process should come into play. The Security Policy Exception Process should identify the specific places where there issues with policy compliance so that the issue is elevated to the proper level of management to ensure that the risk is recognized and if appropriate, managed with a compensating control.
A simple way to implement a Security Policy Exception Process is to use your organization’s ticketing system. This way, open tickets that pertain to security policy exceptions can be reviewed regularly and closed when the exception has been rectified. It is better to have a system to accommodate exceptions to security policy and thereby communicate areas of risk than to think that there is 100% compliance to all security policy. Information Security is about reducing risk, not eliminating it—that is the big picture.