When you triage by reachability and exploitation signals, auditors tend to ask the same ten things: what is the rule, what signals feed it, who decides, how you handle unknowns, how you review, what you do about exploited issues, how you record exceptions, how you test the method, what it misses and how you report it.
The ten questions
1. What is your prioritization rule, in writing?
Show the policy section. If the rule lives in people's heads, write it down first.
2. Which signals do you use, and why?
List them: published severity, exploited in the wild status, reachability and exposure. CISA advises using the KEV catalog as an input to a prioritization framework, so cite it as input.
3. Who can classify a finding as lower priority?
Name the role. Separate it from the role that approves exceptions where you can.
4. What happens when the analysis is inconclusive?
Say unknown is treated as reachable until reviewed. See why reachability analysis says unknown.
5. How often do you revisit lower priority findings?
Give the triggers: each release, dependency change, advisory update and a fixed calendar review.
6. How do you handle vulnerabilities known to be exploited?
Describe the faster path. Show a recent example with dates.
7. How do you record exceptions?
Show a sample record with reason, owner, expiry and approval. NIST's Secure Software Development Framework describes recording approved exceptions as part of planning risk responses.
8. How do you know the analysis is accurate?
Describe validation: seeded tests, spot checks of call paths and review of disputed results. Be frank that no method is perfect.
9. What does the method miss?
Name the blind spots, such as reflection, dynamic loading and plugins. Auditors trust an honest limit more than a claim of completeness.
10. How do you report the results?
Show the metric you use. Report counts for every bucket, including the reachable and the deferred, not only the ones you closed.
How to prepare in an afternoon
| Task | Time |
|---|---|
| Pull the policy and mark the answers to 1 to 3 | 20 minutes |
| Sample five closed findings and check each has a record | 40 minutes |
| Write the three line limits statement for question 9 | 15 minutes |
| Assemble one exception example and one exploited example | 30 minutes |
A note on evidence quality
For every answer, bring one real record, not a description of one. A sample deferral with its owner and review date is worth more than a paragraph about how deferrals work. Redact customer names and internal hostnames, keep the dates, and keep the version of the build so the record still makes sense on its own.
A pattern across the questions
Every answer has the same three parts: a rule, a record and a limit. If you can supply all three for each question, you are ready. If one is missing, that is where to spend your time.
Quick check
Do we need to give auditors the raw tool output?
Offer exports for the sampled items. Share only what the sample needs.
What is the most common weak spot?
Exceptions with no expiry or no named approver.
Safeguard provides reachability analysis, policies and evidence automation that give you a record for each of these answers. You can try the free scan.
Sources
- Known Exploited Vulnerabilities Catalog, CISA
- NIST SP 800-218, Secure Software Development Framework 1.1
Last reviewed: 19 October 2026.
