Cybersecurity Exceptions - Part 3 (FINAL)

Welcome to the Executive Cyber Education podcast, cyber risk management driving real impact; I am Dr. Bill Souza. As I mentioned in my previous episode, today we will discuss exceptions tracking and expirations.

Exceptions to any cybersecurity policy or standards must be reviewed and approved by management and then tracked for expiration and mitigation. Here are a few elements you should have in your exception record:

• Title (perhaps goes without saying, but just in case)
• Business justification
• Mitigation or remediation plan
• Owner

These elements are the minimum required from the individual entering the exception; everything else will be entered by the cybersecurity department, such as inherent risk, residual risk, expiration date, security control, and who in the organization will be signing/accepting the risk. The rule of thumb is the following:

• Very high or high exceptions not to exceed 12 months (or six months if you have the resources)
• Medium not to exceed two years
• Very low and low not to exceed three years

Your organization may have different timelines in place, or you plan to implement either more restrictive or relaxing timelines; the bottom line is that you need to have an expiration date in place. There is no such thing as permanent exceptions; if a permanent exception is required, one without an expiration date, that becomes the standard, rather than the exception, and your documentation needs to reflect that practice.

Depending on the size of your organization, tracking exception expiration dates can be as simple as a spreadsheet or MS Access database and as complex as having a GRC application with complex workflows and sign-offs. Regardless of your situation, the fundamental thought process is the same; however, I will discuss two scenarios to picture it better.

First, you are a small organization and leverage a spreadsheet or a simple MS Access database for your exception process; in this scenario, make sure to have the following steps in place:

• Sort and forecast all your exceptions by month; this will give an idea of the workload ahead.
• Start communication (sending emails) with the exception owner as early as 90 days. I suggest establishing a cadence of 90, 60, 30, 15, 7, and 1 day before expiration to allow the owner plenty of time to respond if the exception is still needed.
• If the exception is still needed, start the assessment again and review if anything has changed, including the mitigation/remediation plan; re-assess the residual risk, and validate if the owner is still the same.
• Send the exception for signatures. The strategic business unit (SBU) and cybersecurity will sign off on the exception again.
• Once approved, change the date in your spreadsheet accordingly.
• If the exception is no longer needed, close it and back out any previously made changes for the exception.

Second, if you are in a mid-size or large organization, or even in a highly complex/regulated organization, you will need a GRC application. The GRC application will automate the steps previously mentioned above, allowing you to perform the following:

• Create customized dashboards for your team to review
• Draft standard communication (emails) that will go out in assigned intervals.
• Develop approval workflows adapted to your organization's needs.
• Keep a historical record of all your exceptions

I’ve done my share of GRC implementations, so here is a tip for you. If you are to implement a GRC application or process, make sure to define success, document your requirements, talk to everyone involved, develop a charter and get leadership sign-off. This won’t guarantee success, but it will save you many heartaches, as requirements will change, objectives readjusted, and memories fail.

If you are embarking on this journey, I wish you all the best; this process must exist in any organization. This was part 3 and the final part of this podcast series on standard exceptions. If you have any questions regarding standard exceptions, feel free to reach me on LinkedIn or Twitter.