A security exception process lets a team knowingly miss a policy requirement for a limited time, with a named owner, a stated reason, compensating controls and an expiry date. Without one, exceptions still happen, but invisibly and forever.
Why you need one
Every policy meets reality. A legacy system cannot take a patch, a vendor cannot support the required setting, a launch cannot wait. If the only choices are comply or hide, people hide.
A formal path gives you a record of residual risk and a trigger to revisit it.
The request form
Keep the form short. It should capture:
- The requirement being excepted and the system affected.
- Business reason, in a sentence or two.
- The risk if something goes wrong, in plain language.
- Compensating controls already in place or planned.
- Requested duration.
- Requester and the business owner who accepts the risk.
Avoid forms that need an essay. People will skip the process if it costs an hour.
Approval tiers
Set tiers by impact, not by who asks.
- Low impact. Security team lead approves, logged automatically.
- Medium impact. Security leader plus the system owner's director.
- High impact. CISO plus a business executive, reported to the steering committee.
The person who accepts the risk must be the person whose budget or customer bears the loss. Security advises. It does not accept risk on behalf of the business.
Always set an expiry
Ninety days is common for medium risks, with a hard maximum of a year. At expiry the exception either closes (the issue was fixed), renews with a fresh review, or escalates. Never allow auto renewal.
Add a reminder thirty days before expiry to the owner and approver.
Track and report
Maintain one register of open exceptions and publish three numbers monthly: how many are open, how many are past expiry, and how many are high impact. Rising counts usually point to a policy that is unrealistic, which is useful feedback.
Review the whole list quarterly. Look for patterns, such as many exceptions against one control, and fix the underlying cause.
For software teams
Exceptions in code, such as shipping with a known vulnerable dependency, need the same structure. Link the exception to the finding, record why the code path is or is not reachable, and set a re-check date. Policy tools can enforce this by making a gate pass only while a valid, unexpired exception exists.
Quick check
Who can approve a security exception?
The business owner who bears the risk, advised by security. Security alone should not accept risk on the business's behalf.
How long should an exception last?
As short as practical. Ninety days is a common default, with no automatic renewal.
Last reviewed: 19 October 2026.
