Accept an exception
Sometimes a diagram has to keep a gap: an old database until next year's migration, a direct call the platform cannot carry yet. An exception records that gap with its scope, its reasons, the controls that compensate and an expiry date, so the finding is covered instead of hidden.
On this page
Before you start
- Editor or owner of the workspace to grant an exception. Anyone who can request one can fill it in; it waits as requested until an editor or owner grants it.
- The finding or the standard the exception is about: for the example, the STD-01 finding on the Claims database, which runs PostgreSQL 12.
Request an exception
- Start from the finding
In the review, on the finding, select Request an exception… The form is linked to the finding's rule and elements. You can also start from the Governance menu with Request an exception…
- Say what it covers
Give it a title (Claims database stays on PostgreSQL 12 until the Q3 migration) and its scope: elements of this diagram, a rule, or a technology of the radar.
- Say why, and what compensates
Write the rationale. Under Compensating controls, select Add a control identifier for each control, written as a framework identifier, for example PR.PS-02 from NIST CSF 2.0.
- Set the dates and save
Set Expires, required, and a Review date before it. Add the Work item link of the migration ticket if you have one. Save.
The exception has a key such as EX-0001, and the finding shows Exception requested · until it is granted.
Grant it
An editor or owner opens the exception in the Governance register and sets it to Granted. The finding then reads Covered by EX-0001 and no longer counts as open. A decision can grant an exception too: the register then says Granted by decision.
The life of an exception
| State | What it means | Who moves it |
|---|---|---|
| Requested | Written, waiting for a decision | an editor or owner grants or revokes it |
| Granted | Covers its findings until it expires | it expires on its date, or is revoked |
| Expired | Past its date: no longer covers anything | an editor or owner can grant it again with a new date |
| Revoked | Withdrawn before its date |
Two checks keep exceptions honest:
- GOV-02 Exception due for review: medium once the review date has passed, low when the exception expires within 30 days.
- GOV-01 Expired exception: high. The gap it covered is unmanaged again.
To see what needs attention, filter the governance register on Expired, due for review or expiring within 30 days.
Exception, accepted risk or dismissal
- Exception: a gap to a standard, accepted until a date, with controls. Use it when the gap will be fixed later.
- Accept the risk, on a finding: a reason and an optional review date, for one finding. See Run checks and handle findings.
- Dismiss: the finding does not apply (by design, a false positive). Nothing to follow up.
If it doesn't work
The finding is still open after the exception
The exception is still Requested, or its scope does not include the finding's elements or rule. Ask an editor or owner to grant it, or widen the scope.
A control identifier is refused
It does not match a framework of the workspace. Write it as the framework does, for example PR.AA-03 for NIST CSF 2.0.
“Your role cannot change this record”
Only editors and owners grant, revoke or renew an exception. Ask one of them, or ask for the role: see Roles and permissions.
More: Standards.
Was this page helpful?Your answer is anonymous and counts only if you accepted measurement.
What went wrong?
Don't write personal data.