How to Pass Every Audit - Exception Process

We’ve talked about scope and measuring for an audit. There is a nuanced component that lives across both of those worlds. The exception process. An exception process is not a way to manage out of scope. Exceptions are still in scope. Exceptions are risk acceptances in some way that you need to account for. There are a few things that should be true about exceptions:

1. They must be transparent

2. They must be included in the scope (exception ≠ out of scope)

3. They must have reference to the formal risk register so that they are not managed on an island

4. They must have an expiration date

If these things are true, then your audit is fine. So, what is an exception.

1. The CEO of the recent acquisition refuses to use MFA

2. That one board member expects to be treated differently

3. There is an old system living in a closet that doesn’t support the current MFA technology

4. There is a test account that is needed for a mobile development team that breaks their app if they use MFA

These are all similar to situations I’ve seen. They are not something I’m ok with per se, but at least the last two make sense. I am going to document the risk of allowing this, make a recommendation that it doesn’t happen, and then get sign off from someone above me. Once I have that, I will document the compensating controls and log the exception in some system of record. This is all you need to maintain your metrics and satisfy audit requirements.