Defining Exceptions to Policies and Controls
Life would be so simple if every person, system, application, or process explicitly followed all of our policies and controls. Unfortunately, we know from experience that there will always be situations where compliance is completely outside of our control. We need to analyze the risk and determine whether it is something that we can accept or if we need to take action to reduce the risk. If we determine that risk reduction is necessary, then we track the risk and work required using our standard risk management processes. If, however, we determine that this exception is something that we can accept, we still need to track our authorization and justification for that decision and ensure that it continues to be re-reviewed on a regular basis.
As an example, almost every organization out there has a documented Password Policy. While NIST's guidance has recently changed with respect to password rotation, many Password Policies still reflect a requirement to change passwords every 90 days and this is likely still a good idea for your organization's service accounts. Inevitably, however, there will be applications within your organization that cannot rotate their passwords every 90 days. Often times these applications support production applications with significant uptime requirements and downtime is required to change the passwords. As a result, the business has decided to only have their passwords changed as part of a major release or upgrade and that process happens only once or twice a year. In that situation, you have a choice to make. Do you go against the needs of the business and incur additional downtime to patch a password that hasn't been compromised? Or do you document this situation as an exception to your stated policy and change the password the next time there is an acceptable window of downtime to make the change?
This situation is typically exacerbated where third-party external auditors are involved in ensuring the effectiveness of your controls. These auditors will typically ask for a copy of your stated policies and then evaluate your systems against them to find places where your controls are failing. If you are unable to provide a sufficient justification as to why, these will end up being highlighted as control deficiencies that may be brought to your executive management team or Board of Directors. If you've documented these policy and control exceptions, however, you simply point the auditors at them. Now, you've been able to prove that 1) you were already aware of this exception to your policy, 2) why you believe this exception was justified, 3) the decision was approved by management and 4) the decision will be reviewed again in the future to make sure the situation hasn't changed. This documentation is typically enough for an auditor to accept it and move on to other issues.
In SimpleRisk, we can track all of your policy and control exceptions by clicking on "Governance" followed by "Define Exceptions". When an exception is first reported by clicking the plus button, it will go into the "Unapproved Exceptions" tab until a user with the "Able to Approve Exceptions" permission in SimpleRisk determines that the exception has been approved. Once approved, the "Policy Exceptions" and "Control Exceptions" tabs will provide you with a list of all of your approved exceptions along with the policy or control they are linked to, the justification, and next review date.
You can click on the exception to view even more details about it. These exceptions integrate with our Email Notification functionality to check daily for exceptions coming due for a review and will automatically send out emails to your defined stakeholders to let them know that it's time for another review.
