Guide · 6 min read
Writing policy exceptions that hold up
How to write and approve security policy exceptions that stand up to audit: narrow scope, expiry dates, risk rating, real compensating controls, the right approver and register reviews.
Every security policy meets reality sooner or later. An old payroll system can't do MFA. A design team needs USB drives for a client. Exceptions are normal. The problem is exceptions that are vague, permanent and forgotten, because they slowly turn into the real policy.
Keep the scope narrow
An exception should cover only what genuinely can't comply. "MFA exception for Finance" is far too broad. "PayrollOne v8, for four named payroll users and one vendor support account" is a scope you can defend, monitor and remove later.
Give it an end date tied to a fix
If there is no plan to remove the exception, it isn't an exception; it is an accepted risk that nobody wants to call by its name. Link it to the remediation (for example, the upgrade that adds SSO) and set the expiry to match. If the project slips, the expiry forces a fresh conversation instead of a silent extension.
Rate the risk you are accepting
Rate the risk of running without the control, on the facts: what data is exposed, how reachable the system is and how many accounts are involved. An internet-facing login protecting bank details with only a password is a high risk, however small the user group feels.
Compensating controls must address the same risk
This is where most exceptions fall down. A compensating control has to reduce the same risk the missing control would have. MFA stops a stolen password being used. So good compensating controls would be:
- Removing the public login and allowing access only through an MFA-protected VPN.
- Reviewing logins weekly and alerting on unusual times or locations.
- Strong passwords and account lockout, as an extra layer.
Awareness training and antivirus are worth having, but they don't stand in for MFA. Auditors will spot the difference.
Get the right approver
The person approving should have the authority to accept that level of risk. The requester's own manager approving a high-risk exception by email is a classic audit finding. Follow your delegation of authority, which for high risks usually means the CISO or a risk committee.
Review the register
Once a quarter, go through every open exception:
- Expired but still in force? Switch the control back on, or re-assess and re-approve.
- Owner left the company? Reassign it and review it now.
- Remediation done? Close the exception and confirm the control is live.
A short, honest exception register shows an auditor that your policies are real. A long list of forgotten exceptions shows the opposite.