A system doesn’t meet the encryption standard, so someone requests an exception. A supplier can’t complete the security questionnaire before the contract deadline, so the project proceeds anyway. A legacy application can’t support multi-factor authentication, so it’s granted a waiver “for now.”
Each of these gets logged somewhere as an exception. Few of them get treated as what they actually are: a decision to carry risk that hasn’t been properly evaluated, owned, or time-limited.
This is where a lot of risk programmes quietly break down. Exceptions accumulate, nobody revisits them, and the organisation ends up carrying risk it never consciously chose to accept.
What Is a Risk Exception?
A risk exception is formal permission to deviate, temporarily and within a defined scope, from an established policy, standard, or control requirement.
For example, an organisation may require all internet-facing systems to use multi-factor authentication. A legacy application may not currently support it. Rather than quietly ignoring the requirement, the system owner submits an exception explaining why the control can’t be implemented, what exposure remains, and how that risk will be managed until the issue is resolved.
A properly written exception should answer: what requirement isn’t being met, why the exception is necessary, which systems or users are affected, what additional risk it creates, what compensating controls will be used in the meantime, who’s accountable for remediation, and when it expires.
The exception doesn’t make the original requirement irrelevant. It documents a controlled, temporary deviation from it.
What Is Risk Acceptance?
Risk acceptance is a formal, deliberate decision that the organisation is willing to tolerate a particular level of risk, based on an understanding of the threat, the affected asset, existing controls, likelihood, impact, and residual exposure.
An organisation might accept a risk because further treatment costs more than the expected loss, the risk already falls within approved tolerance, additional controls would seriously disrupt the business, or no practical treatment currently exists.
This is a governance decision, not an administrative approval. The person accepting the risk needs the authority to actually commit the organisation to the consequences. A system administrator can identify a risk. They usually can’t accept a major financial, legal, or regulatory exposure on the business’s behalf.
Why the Distinction Matters
A risk exception permits a deviation. Risk acceptance authorises the organisation to live with the resulting risk. An exception may involve some temporary tolerance of risk, but that isn’t the same as permanently accepting the underlying exposure.
Take a six-month exception granted for a legacy system that can’t support encryption at rest. The exception lets the system keep running while a replacement is implemented, with compensating controls such as restricted access, segmentation, and closer monitoring in the meantime. The organisation is temporarily tolerating the risk, conditional on the replacement actually happening before the exception expires.
When that deadline arrives, a real decision has to be made again: close it because the control is now in place, extend it with fresh evidence and approval, apply different compensating controls, escalate it, formally accept the risk for longer, or retire the system. Skip that step, and a temporary exception quietly becomes a permanent, unexamined control gap.
Why Organisations Confuse the Two
Exceptions usually live in email threads, spreadsheets, or ticketing systems, approved once and rarely revisited. That creates the appearance of governance without the structure needed to actually manage the risk.
Approval becomes a substitute for analysis. An approved exception gets treated as proof the risk has been handled. But approval only shows someone agreed to the deviation. It doesn’t show the residual risk was actually measured, or accepted by someone with the authority to do so.
Exceptions have no meaningful expiry. A date might be written on the request, but nothing happens when it arrives. No reminder, no escalation, no reassessment. The exception stays open because no one is actively responsible for closing it.
The wrong person accepts the risk. A security manager might understand the technical exposure, but the business owner is often the one actually accountable for the operational or financial consequences if it materialises. Technical approval and risk ownership aren’t automatically the same person.
Compensating controls are assumed rather than verified. A request might state that monitoring or restricted access will offset the gap, but if nobody owns, tests, or evidences that control, it exists only on the exception form, not in practice.
Exceptions are disconnected from the risk register. Exceptions live in one system, enterprise risk in another. Ten individually reasonable exceptions can add up to a real concentration of risk that nobody can see, because nothing connects them.
A Proper Risk Exception Process
1. Identify the exact requirement. Reference the specific policy, standard, control, or obligation involved. “The system is noncompliant” is too vague to act on. Naming the exact requirement also makes it possible to see whether the exception touches other frameworks or obligations.
2. Define the scope. Limit it to named assets, systems, users, or environments. “Legacy systems are exempt” creates uncontrolled exposure. “This application, this environment, this period” doesn’t. Narrow scope makes the risk easier to actually assess.
3. Document the business justification. Technical limitations, supplier constraints, implementation timelines, disproportionate treatment cost, these are valid reasons. Convenience alone isn’t. Include the cost of refusing the exception too, so approvers see the full tradeoff, not just the security side of it.
4. Assess the resulting risk. Consider the assets and data affected, the relevant threat scenario, which controls remain operational, how effective the proposed compensating controls actually are, and the resulting likelihood, impact, and residual risk. Link the exception to an existing risk record, or create one, so it’s reflected in the wider risk picture rather than existing in isolation.
5. Establish compensating controls. Where the required control can’t be implemented, look for alternatives: network restrictions, stronger password requirements, tighter privileged access, enhanced monitoring, more frequent access reviews. Each compensating control needs a named owner, an implementation date, and evidence it’s actually working, not just a mention in the request.
6. Route the decision to the correct authority. Approval level should match the severity of the residual risk. A low-risk, short-term exception might be fine at the control-owner level. Anything touching regulated data, critical operations, or significant financial exposure needs to go higher, sometimes to an executive or risk committee. A useful test: would this approver be comfortable explaining the decision to the board if the risk materialised? If not, it’s going to the wrong person. Note too that the person approving the operational deviation and the person accepting the residual risk aren’t always the same individual, and that distinction should be explicit rather than assumed.
7. Set an expiry date. Every exception needs one, and it should reflect the level of risk and the realistic remediation timeline, not just a default. Higher-risk exceptions deserve shorter review periods. A reasonable default for most operational exceptions is around 90 days, with renewal only for a documented reason. The expiry date isn’t a reminder, it’s the point at which the previous decision stops being valid unless someone actively reassesses it. Exceptions should never auto-renew.
8. Track remediation. Every exception needs a treatment plan behind it: the actions required, the owner, target dates, dependencies, and what evidence will show it’s done. Without that plan, the organisation isn’t managing a temporary exception. It’s documenting a permanent weakness with a polite label.
9. Reassess before renewal. Renewal should require a fresh decision, not a date change. Has the justification changed? Has the scope changed? Are the compensating controls actually working? Has the remediation plan made real progress, or stalled quietly? A second or third renewal request deserves real scrutiny, and repeated renewals should trigger escalation rather than a rubber stamp. At that point it’s worth asking honestly whether this is still a temporary gap, or whether the organisation has quietly decided to accept a permanent one without ever calling it that.
10. Close it properly. An exception should only close when there’s evidence the control was implemented, the affected system was retired, the scope no longer exists, or the risk has moved through a genuine, separate risk acceptance process. Keep that closure evidence for audit purposes.
Risk Acceptance Must Remain a Separate Decision
Sometimes remediation just isn’t going to happen on a reasonable timeline. The legacy system will run for years. The cost of replacement doesn’t justify the risk reduction. The residual exposure is judged genuinely tolerable.
At that point, the right move isn’t another renewal. It’s a formal risk acceptance process that records the specific risk being accepted, the expected likelihood and impact, the controls already in place, why further treatment won’t be pursued, the duration and conditions of the acceptance, the accountable owner, the approving authority, and a scheduled review date.
Accepted risk should still be reviewed periodically. Acceptance isn’t a decision made once and forgotten, it’s a position that should be revisited as circumstances change.
What Management Should Actually See
A mature exception programme gives leadership more than a count of open requests. Useful reporting shows active exceptions by risk level, exceptions approaching expiry, overdue remediation actions, exceptions whose compensating controls have never actually been verified, exceptions that have been renewed repeatedly, and the total residual risk currently sitting behind active exceptions.
That turns exception management into a real part of risk oversight, rather than a hidden administrative process nobody looks at until an audit forces the question.
How PurpleWASP Supports Exception Management
Exceptions become hard to govern when policies, assets, risks, controls, and evidence live in separate spreadsheets and inboxes, which is exactly how they end up forgotten. PurpleWASP links each exception to the requirement it deviates from, the affected asset, the relevant risk scenario, the responsible owner, the compensating controls, and the remediation plan, with expiry dates and approval history tracked in one place. Instead of discovering expired exceptions during an audit, teams can see overdue reviews, unverified compensating controls, and repeatedly renewed exceptions as part of normal, ongoing governance.
Frequently Asked Questions
What’s the difference between a risk exception and risk acceptance? An exception is a temporary, scoped deviation from a policy or standard, with an active plan to close the gap. Risk acceptance is a considered, longer-term decision by someone with real authority to formally agree the organisation will carry a given risk.
Can an exception be renewed indefinitely? It shouldn’t be. Repeated renewals without progress on remediation usually mean an unaddressed risk is being treated as though it’s actively managed, when in practice nobody has made a real decision about it. At that point it belongs in a formal acceptance process instead.
Who should approve a risk exception? Someone whose authority matches the risk involved. Low-impact exceptions can often be approved locally. Anything touching critical systems, regulated data, or customer-facing services needs a more senior or centralised approver, and the person approving the deviation isn’t necessarily the same person accepting the residual risk.
What happens if a remediation plan tied to an exception fails to happen? The exception should be escalated, not quietly extended. At that point the organisation needs to either commit real resources to closing the gap or move it through a formal risk acceptance process.
The Bottom Line
An exception is a bridge, not a destination. It exists to give the organisation time to reach compliance, not to quietly replace the decision about whether a risk is acceptable. Left unmanaged, exceptions don’t reduce risk, they just hide it behind a label that sounds more controlled than it actually is. Managed properly, with clear scope, verified compensating controls, the right approver, an expiry date, and honest review, they do exactly what they’re supposed to: buy time toward a real decision, rather than avoid one.
