Every control programme grants exceptions. A control cannot be applied to a legacy system that will be retired next year. A vendor will not sign the clause. A team needs ninety days to finish the migration that makes the control possible. Refusing to grant any exception does not produce a compliant organisation; it produces an organisation that stops telling you about the gaps.
So the exception is not the problem. The problem is the exception nobody came back to. It was granted for ninety days, the ninety days passed, and the control is still bypassed three years later — not because anyone decided that, but because nothing made the return date real. By the time an auditor asks, the person who granted it has left and the justification is a sentence nobody can reconstruct.
An exception, properly recorded, is a promise to come back. Everything below is about what makes that promise enforceable rather than aspirational.
One register, whatever the exception is about
Exceptions arrive from more than one place. Someone raises a policy exception because a control cannot be applied to a system that is being retired. Someone else, working through the control library, grants a control exception because the platform provider satisfies that control under the shared responsibility model and the provider’s attestation is the evidence. A third is a vendor finding the organisation has decided to accept.
Those are the same kind of decision — run a known gap, on purpose, with a reason — and they belong together. This register holds the three that come from policies, controls and vendor findings, and says which is which: the Applies to column names the policy or the control the exception is about, and labels the kind. Filter tabs cover the states an exception reaches here, including the ones people forget to ask for: Revoked, for a bypass that was withdrawn, and Active.
One caveat worth knowing before you rely on it. Talarity has a second, wider register at
Exception Register (/app/exceptions), which also gathers risk acceptances raised against endpoint,
cloud-posture, attack-path and application-security findings — eight types in total. If your
programme accepts risk from those scanners, that is the page that shows everything; this one shows
the three kinds raised against policies and controls. Two registers over one table is a seam, not a
feature, and it is the thing to reconcile first if you are choosing where to look.
The counters above the table count the same definition as the table beneath them — every kind of exception, not one. They are not always the same population: the register loads the most recent hundred and says so when there are more, while the counters are taken over the whole set. That sounds like a fine distinction until you have read a dashboard that quietly conflated the two.
And read the five counters as five separate questions, not as a breakdown that adds up. Total counts everything; Pending, Approved, Expiring Soon and Expired each count one state. A control exception is created active, and a withdrawn one is revoked — neither has a counter, so in a register holding both you will find rows that Total counts and no state card does. That is a gap rather than a subtlety: those two states deserve counters, and they will not get them until the page’s own guide defines what each figure counts, because a number a reader cannot look up is worse than a number that is missing.
What a bypass has to record before it is worth granting
Four fields do the work, and one of them is the one teams skip.
What it applies to and why are the obvious pair. The justification is what an auditor reads first and what the person who inherits this decision reads instead of asking you.
What compensates. An exception without compensating controls is not an exception; it is an unmanaged gap with paperwork. Choose the controls that carry the risk with Browse — they are recorded as links, not as a sentence — and add prose only if the chosen controls need explaining. That ordering matters more than it looks: an approver can act on a linked control, and cannot act on a paragraph.
When you come back. This is the field that separates an exception from a permanent bypass. An expiry date says when the exception dies. A re-review cadence says when someone has to look at it again while it is still alive. The daily sweep chases that date rather than depending on anyone remembering: when it arrives, the person who raised the exception is told it is due — not that it is expiring, because it is not — and asked to confirm the reason still holds and the compensating controls still work. It fires once per cycle, and renewing resets the clock.
The interval has to fit inside the exception’s own life. A ninety-day re-review on a seventy-five-day exception is a promise that can never be kept, so the form refuses it and says why. “Only at expiry” is a legitimate answer for a genuinely single-shot exception; the default is ninety days because most exceptions are not.
The approver has to see what they are being asked to trust
An approval screen that shows only the request and a text box is asking for a rubber stamp. This one shows the justification, the current expiry, and the compensating controls by name — not a count of them. “Two controls linked” tells an approver how many things they are trusting; it does not tell them which, and those are different questions.
The approval itself is gated. The rationale is required, and the expiry can be adjusted at the moment of approval rather than inherited silently. The restriction that matters most is enforced on the server: only the assigned approver or an administrator can decide, checked against the freshest record inside the transaction rather than on the strength of what the page happened to load. A stale tab cannot approve something that was reassigned while it sat open.
Disposition: what happened, and when
Every state change is on one timeline: the request, the decision with its rationale, each renewal with its new end date, and a revocation with the reason it was withdrawn. Actors appear by name.
Renewal is the state worth understanding, because it is where exceptions quietly become permanent. Renewing resets the reminder cycle rather than inheriting a spent one — an exception renewed after its thirty-, fourteen- and seven-day warnings have fired would otherwise go silent for the whole of its new life, having already “sent” every reminder it had.
Where this feature stops
Worth knowing before you take it to scale, and none of it is hypothetical.
The register loads the most recent hundred exceptions and says so when there are more; the filter tabs and the search box narrow what is loaded rather than re-querying the whole set, so an organisation past a hundred cannot reach the older ones from here.
A policy exception cannot be edited. A justification typed wrongly is permanent — the remedy is to revoke it and raise a replacement. (A control exception can be edited, from the control’s own detail page, which is its own inconsistency.) Revocation is not performed here either: the row action takes you to the governance register, which owns that verb. Bulk actions cover approve and reject only; renewal is one row at a time.
An approver cannot decide their own request. The permission model separates the two verbs — filing an exception and deciding one are different permissions — but page access grants both together, so anyone who can reach this register to raise a bypass could once also grant it. The product now refuses that transition, and refuses it for org admins and platform admins as well: seniority is not what makes a decision independent. Assign a different reviewer and it goes through. Bulk decisions skip only your own rows — each is reported as a failure with its reason while every other row in the batch is still decided — so one of your own requests in a selection of twenty does not cost you the other nineteen. The separation is structural, which means it is evidenced by the tool rather than around it.
There is no CSV or PDF export from this page — exceptions reach a report through the report builder or the public API — and an exception is not yet a citable item inside an evidence package.
Finally, the governance KPIs and the executive dashboards count policy exceptions only, while this register counts three kinds. They read the same table; they do not ask it the same question, so the numbers will differ and both are right about what they measure. Knowing which one you are reading matters more than either figure.
None of that blocks the workflow this article describes. All of it is the honest shape of the feature at the edges, which is what you want to know before you rely on it.
What you walk away with
An exception is a promise to come back. The promise is only real if three things are written down: what compensates, who decided, and when someone looks again. A register that holds every kind of exception, an approval screen that shows the compensating controls by name, and a re-review date the platform chases are what turn that promise into something a programme can actually keep.