Appearance
Exceptions
Where to find it: Risk Management, then Exceptions (/exceptions).
An Exception (EXC-YYYY-NNNN) is a formal, time-bound, approved decision to deviate from a requirement or control.
What an exception is for
Every organisation has situations where the prescribed control is not achievable: a legacy platform that cannot support a modern authentication method, a regulatory requirement that conflicts with another jurisdiction, a control that will be met once a migration completes in nine months.
The choice is between recording that honestly with an owner and an expiry, or letting it sit as an unexplained red item that gradually stops being read.
An exception is the first option.
What an exception is not
An exception never makes an unmet requirement satisfied
When an approved exception covers a gap, OrviQ records:
- Requirement satisfaction: unchanged — still
not_satisfiedif the control is ineffective - Governance disposition:
accepted_deviation, referencing the exception
Satisfaction is not overwritten, and it is not replaced by a value like "exception applied". The obligation remains unmet, and the record says so. The exception records what the organisation decided to do about an unmet obligation.
This is what makes an exception defensible. An exception that turned a red item green would be a mechanism for hiding gaps; one that leaves the gap visible and adds an approved, expiring decision on top of it is a governance control.
Lifecycle
| Status | Meaning |
|---|---|
draft | Being prepared |
requested | Submitted for review |
in_review | Under review |
approved | Approved; effective within its validity window |
rejected | Declined, with rationale |
active | In force |
expired | Validity window has passed |
closed | Closed before expiry |
revoked | Withdrawn |
An exception is effective only when it is approved or active and the current time falls within its validity window. An approved exception whose end date has passed automatically becomes ineffective.
What an exception record carries
| Field | Purpose |
|---|---|
| Business reference | EXC-YYYY-NNNN |
| Title, description, justification | What is being deviated from and why |
| Affected records | Framework, requirement, obligation, control, scope |
| Compensating controls | What mitigates the residual exposure |
| Related risk | The risk this deviation contributes to |
| Owner | Who is accountable |
| Requested by and at | Maker record |
| Reviewed, approved or rejected by and at | Checker record |
| Validity from and until | The effective window |
| Reassessment date | When it must be re-examined |
| Approval or rejection rationale | The reasoning, on the record |
| History | Every transition |
Maker-checker segregation of duties
A requester cannot approve their own exception
Segregation of duties is enforced at the service layer: the person who requested an exception cannot approve or reject it.
Requesters are excluded from their own review queues, and returned or rejected exceptions route back to the requester's Workbench.
The default chain is four-eye: draft and submit, then review and approval, then a decision. A six-eye chain adding an executive stage is available through workflow template configuration for exceptions that warrant it.
Compensating controls
An exception with no compensating control is a statement that you are simply carrying the exposure. Sometimes that is the honest position; more often something does mitigate it.
Recording the compensating control does three things: it gives the approver something to weigh, it gives the reassessment something to test, and it gives an assessor an answer to the inevitable follow-up question.
Expiry and reassessment
Every exception has an end date. Exceptions do not renew silently.
The reassessment date drives a GRC Calendar entry and a Workbench task, so the exception comes back for a decision before it expires rather than after.
A permanent exception is a control gap with better manners
If an exception has been renewed four times over three years, the underlying issue is not temporary. Either fix it, accept the risk formally through risk acceptance, or change the control standard. Perpetual renewal is a way of never making that decision.
AI assistance
OrviQ can draft an exception justification from the context of the affected requirement and control. The draft is a starting point; the requester owns what is submitted, and the approver decides.
Requires the AI entitlement.
Permissions
| Action | Permission |
|---|---|
| View the register and details | exception.read |
| Request a new exception | exception.create |
| Update, edit or cancel a draft | exception.manage |
| Review requests and assess compensating controls | exception.review |
| Approve, reject or grant temporary exception | exception.approve |
| Close, renew or retire | exception.close |
All require the compliance_core entitlement.
Example
Exception EXC-2026-0031 — MFA on legacy trading platform service account.
| Field | Value |
|---|---|
| Affected control | CTL-2026-0041 MFA Standard |
| Affected requirement | A.8.5 |
| Justification | "The trading platform's integration service account authenticates via a vendor protocol that does not support MFA. The vendor has committed to protocol support in release 8.2, scheduled for Q4. The account cannot be removed without interrupting settlement processing." |
| Compensating controls | "Account restricted to a single source IP on a dedicated segment; credentials held in the privileged vault with dual-control checkout; all sessions recorded and reviewed weekly; alerting on any authentication from an unexpected source." |
| Related risk | RSK-2026-0014 |
| Requested by | IT Security Operations Manager |
| Approved by | Chief Risk Officer |
| Validity | 90 days |
| Reassessment date | Day 75 |
Effect on assurance:
| Dimension | Value |
|---|---|
| Requirement satisfaction | not_satisfied — unchanged |
| Governance disposition | accepted_deviation, referencing EXC-2026-0031 |
| Exception posture | active |
What the board pack shows: an accepted deviation with a named approver, a compensating control set, a 90-day expiry and a reassessment date — not a green tick, and not an unexplained red one.
On day 75 the exception returns to the Workbench. If release 8.2 has shipped, it closes. If not, a renewal decision is made by a person, with the same approval requirements as the original.
Troubleshooting
"The requirement still shows not satisfied." Correct and intentional. Check the governance disposition — it will read accepted_deviation.
"I cannot approve an exception I requested." Maker-checker segregation of duties. A different approver is required.
"An exception stopped applying." Its validity window passed. Expired exceptions become ineffective automatically.
"I want to extend an exception." Use renewal. It goes through the same approval chain — extension is a decision, not an edit.
"Exceptions is not visible." Requires the compliance_core entitlement and exception.read.