Document an unfixed vulnerability with a short exception record: what the finding is, why it cannot be fixed now, what reduces the risk in the meantime, who approved the delay, and the date it will be reviewed. Without all five, an open finding looks like neglect to a buyer.
Why this record matters in a first enterprise deal
Every real codebase has open findings. Buyers know that. What they test is whether you know about yours and handle them on purpose. A scan report with unexplained open items invites doubt. The same report with a clean exception register invites trust.
The register also protects you internally. Six months later nobody remembers why a medium severity issue was left alone, and the record answers that.
The five fields
| Field | Example content |
|---|---|
| Finding | Package, version, advisory identifier, where it is used |
| Reason for delay | No upstream fix, breaking change, planned migration |
| Compensating control | Feature disabled, input blocked at the edge, network access limited |
| Owner and approver | A named engineer owns it; someone other than the code owner approves |
| Review date | A real date, not "later" |
Two details are worth stressing. The approver should not be the person who wrote the code, to keep the record honest. And the review date should expire automatically in your tracker, so the exception returns to the queue instead of living forever.
Reachability changes the story
Many open findings sit in code your application never calls. If you can show that the vulnerable function is not reachable, the exception becomes a documented analysis rather than a shrug. State how you checked, whether by tooling or by reading the code, and note what would change the answer, such as a new feature that starts using that function.
Be careful with the wording. "Not exploitable in our product" is a claim about your code. "Not affected" in a formal exchange format is a statement others may rely on. Keep it specific to the version you ship.
Steps to set this up in an afternoon
- Create one register, a spreadsheet or a labeled issue type, with the five fields.
- Back fill every open high and critical finding from your latest scan.
- Assign owners and review dates for each.
- Add a rule that any exception past its review date is escalated.
- Export a dated copy for your evidence folder.
Do not delete closed entries. Closing an exception with the fix date shows the full lifecycle.
What to tell the buyer
Share the register, redacted, or a summary: how many exceptions are open, their age, and the oldest. If you have a count, make sure it is current. You can also say that exceptions beyond a set age go to a named executive. For wording on timelines see how to write a vulnerability remediation SLA policy.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how the check decides whether a finding is reachable, which is the core of a good exception reason.
Safeguard offers reachability analysis and policies that can record why a finding was accepted. You can start with a free scan.
Quick check
How long should an exception last?
Short enough to force a recheck. Many teams use 30 to 90 days for high findings, but set it by your own risk policy.
Can I accept a critical finding?
Sometimes, with a compensating control and executive approval. Record it just as carefully, and be ready to explain it to a buyer.
Last reviewed: 19 October 2026.
