How to Handle an Exception Request: A 5-Stage Process

A policy exception is a formally approved, time-bound deviation from a control, standard or policy requirement, granted alongside compensating controls or a remediation plan. Every organisation generates exception requests. What separates defensible risk management from an audit finding is whether a structured process handles them consistently and documents the reasoning behind each one.

Without one, decisions get made informally. Approvals go to whoever is available that day, compensating controls get agreed verbally and never tracked, and when an auditor asks why a control was switched off for six months, the answer is a search through email threads. Risk sits in granting exceptions inconsistently, without evidence, or without a plan to resolve them.

A policy exception is a formally approved deviation from an established control, standard or policy requirement. It's time-bound, documented and conditional on compensating controls or a remediation plan.

Exceptions are distinct from policy violations. A violation is an unapproved departure. An exception is a managed one, and the difference matters to regulators and auditors, who want to see evidence that governance is active.

Common scenarios that generate exception requests include the following.

1. A legacy system that can't meet current encryption standards pending a scheduled upgrade
2. A third-party supplier that doesn't yet comply with your vendor security requirements but is critical to operations
3. A business unit requesting a temporary deviation from access control policy during a system migration
4. A project team unable to complete mandatory training before a go-live deadline

All of these are legitimate business situations, and all of them require a structured response.

A repeatable exception process moves through five stages: intake, risk assessment, approval, compensating controls and time-boxing, and review. Each stage generates its own documentation, and together they create an auditable chain of decisions.

Stage 1: Structured intake

Every exception request should go through a standard form or workflow that anyone on the team can complete the same way. The intake stage captures what's needed to assess the request fairly and consistently.

1. The policy or control in question: Which requirement is being deviated from, and the relevant clause or reference
2. The reason for the request: Why compliance isn't currently achievable, with supporting evidence
3. The scope: Which systems, processes, people or business units are affected
4. The proposed duration: When the exception is needed from and until
5. Proposed compensating controls: What the requester will put in place to reduce exposure during the exception period
6. The risk owner: The individual accountable for managing the exception if approved

Standardised intake keeps the process from becoming a negotiation and gives the approver everything they need to decide.

Stage 2: Risk assessment

Before any approval decision, the request should be assessed against the organisation's risk appetite. This is the substantive part of the process, where the real judgement gets applied.

The assessment should answer three questions.

1. What is the residual risk if the exception is granted? Consider the likelihood and impact of the exposure, taking into account any compensating controls the requester has proposed
2. Does this residual risk fall within the organisation's risk appetite? If it doesn't, the exception shouldn't be approved regardless of the business justification
3. Are there regulatory implications? Some controls are baseline legal obligations that apply regardless of internal policy, so granting an exception doesn't remove the underlying requirement; it just creates a gap a regulator can still act on

NIS2 Article 21 is a clear example: every in-scope entity has to address all ten of its mandatory risk-management measures, proportionate to its size and risk exposure but never optional at any size. DORA sets a similar floor for in-scope financial entities' ICT risk management. An internal sign-off changes neither obligation.

Record the assessment in the exception register alongside its conclusion. When it's borderline, escalate it to the next tier.

Stage 3: Approval authority

Not every exception carries the same risk, so approval authority should scale with the risk level of the deviation. A tiered model works well in practice.

Define the tiering criteria in advance and apply them consistently. An exception that bypasses the appropriate approval level is itself a governance failure, even when the underlying deviation was reasonable.

Stage 4: Compensating controls and time-boxing

Every approved exception must be time-bound. An end date, always. An open-ended exception functions as an undocumented policy change, made without going through the proper change process.

Set a clear expiry date at approval. The default should be the shortest period that's genuinely necessary, and 90 days is a reasonable starting point for most operational exceptions. Extensions should always trigger a fresh assessment before anything gets renewed.

Compensating controls are the other non-negotiable. And they need to meet three tests.

1. Specific and measurable: A named target with a clear way to confirm it has been met
2. Assigned ownership: A named individual responsible for implementation
3. Verification: Confirmed operational before the exception takes effect where possible

Document both the controls and the verification. If the compensating controls aren't in place when the exception period begins, the exception shouldn't commence.

Stage 5: Monitoring and review

Approval isn't the end of the process. Exceptions need active tracking throughout their duration and a review before they expire.

1. Whether the compensating controls have remained effective
2. Whether the underlying issue that prompted the request has been resolved, or is on track to be resolved
3. Whether the exception should be closed, extended with a fresh assessment, or escalated

If the root cause hasn't been addressed by the expiry date, that's a risk in its own right. Record it, escalate it to the appropriate owner, and reflect it in the risk register before any extension gets considered.

The exception register is the central record of every active and historical exception. Maintain it as a living document, review it regularly, and make it available to auditors on request. A well-maintained register demonstrates that exceptions are managed as a deliberate governance activity.

The table below shows a recommended structure. Each row represents one approved exception.

This structure integrates naturally with a broader risk register, following the approach set out in SureCloud's Complete Guide to Risk Registers, letting exceptions link to the risks they represent and get tracked alongside every other open risk item.

Exception governance is getting more scrutiny than it used to. DORA has applied to in-scope EU financial entities since 17 January 2025, and NIS2's national transposition deadline passed on 17 October 2024, so supervisors are now actively testing how organisations' risk-management maturity holds up under both regimes in practice.

When an auditor reviews your exception management process, they're looking for evidence of consistent governance. Auditors read a populated exception register as a sign the process works. What worries them is the absence of a process to produce one.

An auditor will usually want to see five things.

1. A defined policy setting out how exceptions are requested, assessed, approved and reviewed
2. Evidence that the approval authority was appropriate to the risk level of each exception
3. Documentation showing that compensating controls were agreed and implemented
4. A record of active monitoring during the exception period
5. Closure records confirming how each exception was resolved

An exception that's well-documented, time-bound and linked to a remediation plan reads as mature risk management. One that's been quietly extended three times without review reads as a finding.

The same logic applies under ISO/IEC 27001, which requires organisations to record risk treatment decisions and justify any control excluded from the Statement of Applicability, and under PCI DSS's Appendix B, which lets an organisation use a compensating control only where it can show a documented technical or business constraint prevents it meeting the requirement as stated. Neither framework treats an undocumented gap as acceptable, and regulators increasingly expect to see departures from policy governed with the same rigour as the policies themselves.

The most common failure in exception management is a process that exists only on paper and never gets operationalised. Exceptions pile up, expiry dates pass unnoticed, and compensating controls never get verified.

The fix is to make the process low-friction for requesters while keeping the governance rigorous for approvers. Standardised intake forms, automated reminders at review dates, and a centralised register visible to the risk team all cut the administrative burden without loosening control.

SureCloud Risk Management centralises IT, cyber, operational and enterprise risk in one register and links each risk to the controls and incidents connected to it, so an exception sits alongside the other risk items it affects, in the same register everyone already checks. Gracie AI Agents with Personas and Skills can then surface which exceptions are approaching expiry or drifting from their compensating controls. That's usually where a manual review cycle loses track first.

Handle exceptions consistently and they're evidence of good governance. Handle them informally and they're a finding.