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:
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:
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:
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:
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.