Tell customers about accepted risks that affect them or that contradict something you told them. Keep every accepted risk in an internal exception register with a reason, a mitigation, an approver and a review date. Share a summary of the relevant entries, not the whole list, and reword them plainly.
What an exception is
An exception is a decision to carry a known gap for a defined time, such as a vulnerable library with no fix yet, or a system that has not reached a control standard. It is different from an oversight, because someone chose it, wrote down why and set a date to look again.
The register
| Column | Purpose |
|---|---|
| Description | What the gap is, in one sentence |
| Systems affected | Scope |
| Reason | Why it cannot be fixed now |
| Mitigation | What reduces the risk meanwhile |
| Approver | A person with authority to accept it |
| Review date | When it is reconsidered |
| Customer impact | Whether customer data or service is affected |
Which entries to share
| Entry type | Share with customers? |
|---|---|
| Affects customer data or service | Yes, in a summary |
| Contradicts a past claim | Yes, as a correction |
| Internal tool, no customer impact | Usually no |
| Details of an exploitable weakness | Not in writing, give a mitigation summary |
The aim is relevance. Customers want to know what could touch them, and how you are handling it. They do not need a list of every internal tooling quirk.
How to word an entry
Name the condition, the mitigation and the review date. For example: "A component in our reporting service has a known issue with no vendor fix yet. The service is not reachable from the public internet and access is limited to named staff. We will review this on a stated date." Avoid the words minor and trivial. Let the facts carry the weight.
Never publish exploit detail or exact system names. If you do not know whether a risk affects customers, find out before you decide to stay silent.
Review discipline
An exception without a review date is a permanent decision in disguise. At each review, choose one of three outcomes: fixed, extended with a new reason, or escalated. Record the outcome. Count exceptions older than twelve months and report that figure to leadership.
Links to vulnerability handling
Where an exception covers a software vulnerability, record whether the vulnerable code is actually called. Reachability evidence strengthens a decision to carry the risk and supports the wording you give a customer. If a fix becomes available, close the exception and note the date.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis show whether a flagged component is called by your code, and the demo below walks through that vulnerability workflow, which is useful evidence in an exception record.
Try it yourself
Click through it at your own pace, or open it full screen. Look for which findings drop out when reachability is applied.
Quick check
Do we have to disclose every exception?
No. Share those that affect customers or contradict earlier claims, in summary form.
Who can approve an exception?
Someone with authority over the affected system and the risk, recorded by name with a review date.
Last reviewed: 19 October 2026.
