An exception management process must let authorised reviewers approve temporary deviations while keeping every approved deviation auditable, time boxed and linked to the risk register. The workflow runs from request through review, decision, documentation, tracking and closure. Business owner acceptance and documented compensating controls are non negotiable, and no exception should exist without an expiry date tied to a central register.
TL;DR:
- For vulnerability requests, assess exploitation state, automatable risk, scope, and mitigation status; distinguish temporary exceptions from decisions to accept residual exposure.
- The business owner accepts residual risk; emergency approvals require documented CISO review within 24 to 72 hours, while reviewers verify controls and evidence.
- Request forms must identify the control, affected assets, justification, risk owner, expiry, and safeguards; preserve attachments and timestamps to protect the evidence.
- Set hard expiry dates, alert owners 30, 14, and 7 days beforehand, and require fresh approval for renewal rather than automatic rollover.
- Link every record to its risk register entry, verify controls on dated schedules, and escalate expired cases as findings to senior leadership.
Table of Contents
- The operational workflow for processing exception requests
- Who approves what: roles and the approval authority matrix
- What to capture on the exception request form
- Reviewer checklist: what counts as a valid approval
- Logging, auditing and tracking exceptions over time
- Expiry, renewal and escalation rules that stop silent drift
- Proven templates and a rollout path for exception management
- Why exceptions quietly fail, and the fixes that work
- How we help you put this process into practice
- FAQ
- Sources
The operational workflow for processing exception requests
A working process has six steps, and skipping any one of them is how exceptions quietly become permanent gaps.
- Submit the request. The requester completes mandatory fields (control reference, justification, affected assets, proposed compensating controls, expiry date) and attaches supporting evidence.
- Triage and classify. The governance team decides whether this is a true exception (temporary, compensating controls in place) or a risk acceptance (the organisation simply lives with the residual exposure), a distinction the CERG risk register and exception process sets out clearly, then routes it to the right reviewer.
- Technical review. A security or engineering reviewer checks whether the proposed compensating controls are feasible and actually reduce the exposure, not just document it.
- Risk assessment. A risk assessor weighs residual exposure against business impact, using exploitability and scope data where a vulnerability is involved.
- Decision and documentation. The approver records the outcome (approve, approve with conditions, or deny), states any conditions, and fixes a hard expiry date rather than an open-ended one.
- Closure and linkage. Once remediated or expired, the exception is closed and the record is linked permanently to the risk register entry it relates to.
For vulnerability related exceptions, the review stage benefits from structured criteria rather than a gut call. The CISA SSVC guide sets out decision points including exploitation state, automatable risk, scope and mitigation status, and using these consistently stops similar requests getting inconsistent outcomes depending on who reviews them. The same discipline applies to triage timelines: our approach to 72 hour triage and 30 day fixes follows a comparable logic of bounding every stage of the process to a fixed window.
Who approves what: roles and the approval authority matrix
Clear ownership prevents exceptions drifting through the process with nobody accountable for the outcome.
- Requester: submits the request with full evidence and proposes compensating controls.
- Engineering or security reviewer: assesses technical feasibility and whether proposed controls actually mitigate the gap.
- Risk assessor: evaluates residual exposure and the business impact of approving versus denying.
- Governance owner: maintains the register, enforces expiry rules and tracks renewals.
- Approver: the authorised individual who accepts residual risk, with authority scaled to severity, for example a team lead for low risk, a security manager for medium, the CISO for high, and an executive sponsor for critical, broadly reflecting the thresholds described in CERG's procedure.
Security teams review and advise, but it is the business owner who formally accepts the residual risk, since they carry the operational consequences if the exception leads to an incident. Emergency situations need a defined fallback: an operational leader may authorise immediately, provided the CISO or equivalent issues documented post hoc approval within a strict window, typically 24 to 72 hours. Delegation rules and the evidence each tier requires should be written down once and reused, not improvised each time.
What to capture on the exception request form
Reviewers can only move quickly when the request arrives complete, so the intake form should force the right fields before submission.
- Control reference identifying the specific policy or standard the request deviates from.
- Business justification explaining why compliance is not currently feasible.
- Affected assets or systems, scoped precisely rather than described broadly.
- CVE or KEV Catalog reference, where the exception concerns a known vulnerability.
- Proposed compensating controls, described in enough detail to be independently verified.
- Expiry date, never left open ended.
- Risk owner, the named individual accountable for the residual exposure.
- Attachments, including scan output, architecture diagrams or vendor advisories.
For vulnerability exceptions specifically, reviewers need the exploit state, the scope of affected systems and the mitigating steps already in place before they can form a view, mirroring the evidence categories in CISA's BOD 26-04 implementation guidance. Whichever intake channel is used, a ticketing system, a governance portal or a central mailbox, attachments and timestamps need to stay immutable once submitted, since altering evidence after the fact undermines the record entirely.
Reviewer checklist: what counts as a valid approval
Before signing off, reviewers should work through a consistent checklist rather than relying on memory or precedent.
- Compensating controls: are they real, specific and verifiable, not just a description of intent?
- Scope: does the exception cover only the assets named, with no silent scope creep?
- Exploitability: does the exploit state and automatable risk category justify urgency or allow more time?
- Residual exposure: is the remaining risk proportionate to the business justification offered?
Decision outcomes should be recorded as one of three states: approved, approved with conditions, or denied, with conditional approvals spelling out exactly what must happen before the next review. Escalate to a higher authority whenever the request exceeds the reviewer's tier, or convert the request to a formal risk acceptance when the organisation is effectively choosing to live with the exposure rather than mitigate it temporarily.
Pro Tip: Require an explicit validation step with its own re-check date for every compensating control, since an unverified control is functionally the same as no control at all.
Logging, auditing and tracking exceptions over time
Treat every exception as a first class auditable record rather than a note in a spreadsheet that nobody revisits.
- Immutable history: once logged, prior states of the record are preserved, not overwritten.
- Register linkage: each exception references the specific risk register entry and control record it relates to.
- Verification tracking: compensating control checks carry a date and attached evidence, not just a tick box.
- Automated surfacing: dashboards and periodic reviews flag exceptions approaching review dates.
The NIST Risk Management Framework frames this well: authorising officials make risk decisions based on credible evidence, and continuous monitoring keeps that evidence current rather than frozen at approval time. Our guidance on audit trail requirements covers the specific properties, immutability, timestamps and attachment handling, that regulated teams need their records to hold.
Expiry, renewal and escalation rules that stop silent drift
Every exception needs a finite life span with no automatic renewal, since open-ended exceptions are how temporary becomes permanent without anyone deciding it should.
- Set a hard expiry date at approval; renewal requires a fresh request and a fresh decision, never a rollover.
- Trigger warnings at 30, 14 and 7 days before expiry, each prompting the risk owner to act.
- After repeated renewals of the same exception, raise the approval tier and require a documented remediation plan.
- On expiry with no closure, auto-generate a finding and escalate to senior leadership immediately.
This mirrors the warning chain AWS Well-Architected guidance recommends for tracked exceptions: automated alerts, no silent renewals, and escalation the moment a compensating control fails verification at its next review.
Proven templates and a rollout path for exception management
Rolling this out does not need to start from a blank page. Our audit ready risk escalation process anchors escalation tiers to risk appetite, and our one page issue escalation matrix adapts directly into an approval authority table for exceptions. Where exceptions touch AI assisted systems, governance-first deployment practices such as those in tekRESCUE AI's guidance on private LLM deployment are worth consulting for the controls mapping involved.
- Pick one high-risk domain to pilot, rather than rolling out organisation-wide on day one.
- Instrument the exception register before the first request arrives, not after.
- Automate the 30/14/7 day alert chain from the outset.
- Onboard approvers with the authority matrix in hand, so tier decisions are not improvised.
Our operational change control approach applies the same bounded-timeline thinking to closing exposures that exceptions have temporarily opened.
Why exceptions quietly fail, and the fixes that work
Silent renewal is the single most common failure mode I see: an exception approved once, never revisited, until it has been in place for years with nobody able to explain why. Enforcing a hard expiry and demanding fresh justification at every renewal closes that gap on its own. Pair it with register linkage and compensating control evidence, start with one domain, prove the process works, then scale it.
— Peter
How we help you put this process into practice
We build governance processes like this one into daily operations rather than leaving them as a policy document nobody opens. We help map your exception workflow end to end, establish approval authority tiers, and implement a compensating control evidence trail to support audit readiness.
Our Videra PM platform then takes that mapped workflow and turns it into a live, auditable exception register, with automated expiry alerts and dashboards that surface anything drifting towards silent renewal before it becomes a finding. For healthcare, construction or facilities teams with sector-specific compliance demands, Videra Healthcare, Videra Hard Services and Videra Construction apply the same approach to your specific regulatory environment. If you would rather start with hands-on process design before adopting the platform, our consultancy service is the place to begin: get in touch to scope a guided pilot on one high-risk domain and see the exception register working within weeks.
FAQ
What are the 5 steps of vulnerability management?
Vulnerability management typically covers identification, prioritisation (often using exploitability and scope criteria such as those in the CISA SSVC guide), remediation or exception, verification and ongoing monitoring. Exceptions sit within the remediation stage whenever a vulnerability cannot be patched immediately and a compensating control is proposed instead.
What are some examples of management by exception?
Management by exception means routine, compliant activity proceeds without senior involvement, while only deviations from policy or standard get escalated for a decision. A temporary waiver from a patching deadline with a compensating control and a fixed expiry, reviewed under an exception process, is a typical example.
What is the process of handling an exception?
Handling an exception means moving it through submission, triage, technical review, risk assessment, a documented decision and, eventually, closure linked to the risk register. Each approved exception carries compensating controls, a named risk owner and a hard expiry rather than an open-ended waiver.
What is an exception process?
An exception process is the formal route for requesting, reviewing and approving a temporary deviation from a policy or control, distinct from a risk acceptance where the organisation simply accepts the residual exposure permanently. It exists to keep deviations time boxed, evidenced and visible to governance rather than informal and untracked.
Sources
These are the primary documents referenced for vulnerability prioritisation, risk management and exception tracking, alongside our own methodology pages for rollout.
- CISA — Stakeholder-Specific Vulnerability Categorization (SSVC) guide
- NIST SP 800-37r2 — Risk Management Framework
- CERG — procedures: risk register and exception process