An exception process exists because policies are written for the general case and reality produces specific ones. Refusing to have one does not eliminate exceptions - it just makes them undocumented. The risk is the opposite failure: a register that grows without limit until the exceptions describe your environment better than the policy does.
Exception vs risk acceptance
The terms are often used interchangeably, but the distinction is useful:
- An exception is a time-bound deviation from a specific requirement - a legacy system that cannot support MFA until it is replaced next year.
- A risk acceptance is a decision to live with a residual risk that sits above appetite, with no plan to reduce it further.
Exceptions imply an end date; acceptances imply a periodic re-decision. Both need an owner with the authority to carry the consequence.
What a request must contain
If any of these is missing, the request is not ready for a decision:
- The specific requirement being deviated from, cited precisely - not "the security policy".
- What will be done instead, and why the requirement cannot be met.
- The risk this creates, described concretely - what becomes possible that otherwise would not be.
- Compensating controls that partially cover the gap. An exception with none is a pure acceptance and should be scrutinised harder.
- Scope - which systems, which users, which data. Exceptions expand quietly when scope is vague.
- An expiry date, and the plan to reach compliance by it.
- The requesting owner - a named person, not a team.
The expiry date is the single control that keeps the register from becoming permanent. Open-ended exceptions are not exceptions; they are undeclared policy changes.
Keep exceptions visible and expiring
GRC Copilot tracks exceptions against the controls they affect, holds the approval trail, and surfaces them as they approach expiry - before an auditor finds them first.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Who approves what
Approval authority should scale with the residual risk, not with who is asking. A workable ladder:
- Low risk, short duration - the control owner or security lead.
- Medium - the CISO or equivalent, with the business owner co-signing.
- High - an executive accountable for the affected business area.
- Above appetite - the risk committee or board, because that is what exceeding appetite means.
Two rules matter more than the ladder itself. The approver must be the person who bears the consequence, not the person who wants the exception. And security should advise rather than approve business risk acceptance - otherwise the security function ends up owning risks it cannot control.
Keeping the register healthy
- Review quarterly. Every exception past expiry either gets closed, renewed with a fresh justification, or escalated.
- Renewal is not automatic. A second renewal should require a higher approver than the first; a third should force an explicit decision to change the policy or fund the fix.
- Watch for clusters. Fifteen exceptions against the same requirement is not fifteen special cases - it is a requirement that does not fit your environment. Fix the policy.
- Report the total to management alongside compliance metrics. A rising exception count with a flat compliance score is a misleading picture.
- Link exceptions to the risk register so the residual risk reflects them. An exception that never touches the risk register is invisible where it matters most.
What auditors look for
Auditors do not object to exceptions - they object to undocumented ones. Expect them to check that a formal process exists, that approvals came from the stated authority, that expiry dates exist and are respected, that compensating controls are real, and that the register is reviewed. An organisation with a well-run exception register reads as mature; one with none at all reads as either exceptionally disciplined or not looking.
Frequently asked questions
How long should an exception last?
Tie it to the remediation plan, and cap it - twelve months is a common maximum, with anything longer requiring re-approval at a higher level.
Can we accept a risk indefinitely?
You can accept it, but not indefinitely without review. Annual re-confirmation by the risk owner keeps the decision current as the business changes around it.
What if the business proceeds without approval?
That is a policy violation rather than an exception, and it belongs in the corrective action process. Retrospective approval normalises the behaviour.
Should exceptions block certification?
Not in themselves. A documented, approved, time-bound exception with compensating controls is a managed decision. An expired one with no owner is a finding.
Key takeaways
- Exceptions are time-bound deviations; acceptances are re-decided periodically.
- No expiry date means it is a silent policy change, not an exception.
- The approver must bear the consequence - security advises, the business accepts.
- Clusters against one requirement mean the requirement is wrong, not the environment.