Write the policy so that reachability and exploitability change the order and timing of work, never whether a finding gets a decision. Define each term, name the signals, state who decides, require a recorded reason and review date, and keep a default for findings you cannot classify. Then follow your own words.
Why wording matters
An auditor tests what the policy says, then tests whether you did it. A vague line such as "we prioritize by risk" can be defended in a meeting but is hard to sample. A specific line gives them something to check, and gives your team something to follow at 5 p.m. on a Friday.
NIST's Secure Software Development Framework supports this shape. It asks organizations to analyze each vulnerability for enough information to plan a response, gives estimates of exploitability and impact as an example input, and describes making a risk based decision to remediate or address the risk by other means.
A structure that works
Use five short sections.
1. Definitions
Define the words you use. Example terms: reachable, not reachable, unknown, exploited in the wild, and exposed. Keep each to one sentence and say which is a fact about code and which is a fact about the outside world.
2. Signals and sources
List what you consult, such as the published severity, the CISA KEV catalog and your reachability analysis. CISA says organizations should use KEV as an input to a prioritization framework, so name it as an input and not as the whole rule.
3. Response targets by class
Use a table so it can be tested.
| Class | Condition | Target action |
|---|---|---|
| A | Listed as exploited in the wild and component present | Act first, decision within your stated window |
| B | Reachable, no exploitation signal | Fix within the standard window |
| C | Unknown reachability | Treated as B until analyzed |
| D | Not reachable with a recorded reason | Monitor, review at release |
Put your own windows in the table. Do not copy numbers from another company.
4. Decision rights
Say who can classify a finding as D, who approves a deferral, and who reviews exceptions. Separate the person who finds from the person who accepts where you can.
5. Records and review
Require a reason, a date, the build analyzed and an owner on every D and every deferral. Require a review at each release and on any advisory change.
Two clauses that cause trouble
- "Not reachable findings are closed." Closed forever is wrong. Say they are monitored and reopened on change.
- "Reachability analysis is conclusive." It is not. Say it is one input and name its limits.
Test it before the auditor does
Sample five findings from the last quarter and check each against the table. If your team cannot place them, the wording is unclear. See also writing a dismissal comment an auditor will accept.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how classes, owners and states are tracked.
Quick check
Should the policy name a specific scanner?
Name the capability and the record you keep, not the product. Tools change faster than policies.
Do we need legal review of the policy?
If it is referenced in customer contracts, have counsel read it. This post is not legal advice.
Safeguard supports policies, gates and guardrails alongside reachability analysis, so the rule you write can be enforced and evidenced. You can try the free scan.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- Known Exploited Vulnerabilities Catalog, CISA
Last reviewed: 19 October 2026.
