By Yuri Braz, CISSP, CRISC, PMP

Information Security, or cybersecurity, has become more relevant every day. One of the main reasons is because information has become the main asset of most companies. Thus, this information needs to be safeguarded or companies would not be able to create value for society and its shareholders. Large institutes, such as (ISC)², help to develop and democratize the information security field, so that today the majority of medium and large companies have an information security policy. An infosec policy is the first step towards risk governance, essential for the practice of due care and due diligence, which aim to make a reasonable effort to ensure that all efforts and investments made by the company are carried out within known and acceptable risk criteria.

In this sense, this post is a provocation in order to encourage the discussion of an extremely relevant topic, but one that is often kept in the background in companies, including large corporations: the exceptions to security policy. This means that while most companies may have an information security policy, as a rule there are exceptions that may go unnoticed, or underestimated, by risk governance.

Firstly, it is necessary to define what is (and what is not) an exception to security policy. We will define an exception here as what is excluded from the policy, a deviation from the normal. This exclusion, which is only valid for a small and specific group of people or single person, is usually performed to dispense, or loosen, the operation of a security control in order to meet a business requirement that emerged after the policy was established. In other words, a specific business need, which was not visible when the policy was discussed.

This already helps us to understand what is not a valid security policy exception. an exception to the security policy is not. An exception is not opening a breach in corporate security, increasing the risk to levels possibly higher than acceptable, to meet a desire that does not translate into an effective business need. It also helps us to clarify that this exception must be temporary. That is, either it has to be excluded because it was a temporary requirement, or it has to be incorporated in some way into the security policy as a whole, since it is an authentic business requirement.

It is necessary to emphasize that the exception must be within the company’s risk appetite. An exception to meet a business requirement creates a new need for risk assessment (or creation of a new risk), and that risk must be assessed to ensure that it is within the limits of the risk appetite, otherwise it cannot be accepted nor as an exception!

An exception always raises the level of risk, since the control that has been loosened has been implemented to mitigate a risk. Exactly for this reason, a risk reassessment must be carried out before any exception to the security policy is approved, because this is the only way to guarantee that the level of risk remains at levels acceptable to the organization. The exception must be within the company’s risk appetite and this must be non-negotiable from the point of view of corporate governance. In most cases, it is necessary for compensatory controls to be evaluated and implemented, in order to return to an acceptable level of risk.

As stated, ideally, every exception should be temporary. This means that the business requirement that emerged must be considered in the security architecture of the controls implemented, so that the company has a consistent and simple infrastructure, where risks are mapped and controls implemented, all clearly and without excessive exceptions, as these increase the level of complexity of information technology, and complexity is risk.

Finally, a workflow must be created for handling exceptions to the security policy, so that such exceptions receive the proper visibility, are properly analyzed and approved by the responsible persons. In addition, this flow must already contain the necessary triggers for reassessing the exception, deleting it, or generating a demand for policy update.

Let’s summarize to make sure the provocations were clear:

• Exception to the security policy is what is excluded from the policy, a deviation from the normal
• Exception is not meeting a desire that cannot be translated into a business need
• An exception loosens a security control that has been implemented to mitigate a specific risk and this necessarily raises the company’s risk level
• That is why it is necessary to reassess the risk before implementing the exception, in order to validate whether the level of risk remains within the threshold
• Exceptions usually require compensatory controls
• Exceptions must be temporary and must be incorporated into the security strategy before the expiration
• A workflow with the appropriate approvals and scheduled reassessment triggers is required to handle exceptions