A SOC 2 Type II audit will eventually ask a specific question: there's a critical CVE in your dependency graph, and you didn't fix it within your stated SLA — explain. Programs that have a defensible answer pass. Programs that don't either start the remediation conversation late or end up with a finding in the report. The defensible answer increasingly involves reachability evidence: the vulnerability exists, but our analysis demonstrates it is not reachable from any user-facing input, so the residual risk is below our remediation threshold. With the analysis attached, the auditor moves on. Without it, the conversation becomes uncomfortable.
What auditors actually ask in 2026
Three recurring questions:
- Show the SBOM for the in-scope service. Then: "Why is CVE-X open? It's been 90 days."
- Show the SLA. Then: "Why does your SLA exception process apply here?"
- Show the documented residual risk. Then: "What evidence supports this risk acceptance?"
Each question has a clean answer if you have reachability data. Each gets harder without it.
What reachability evidence looks like
Three concrete artefacts:
Per-finding reachability classification. Each CVE in your SBOM has a documented status — reachable, not reachable, or under review — with a timestamp and the analyzer version that produced it.
Taint path documentation. For reachable findings, the documented path from source to sink. For unreachable findings, the explicit list of why the vulnerable function is not in any reachable code path.
Configuration provenance. What configuration of the analysis produced the result. Static-only, runtime-augmented, framework-aware? The auditor wants this documented.
The three together constitute "we made a deliberate, documented decision," which is the standard SOC 2 expects.
Where the audit conversation actually breaks
Two recurring failure modes:
No reachability data at all. The auditor asks why the CVE is unaddressed; the team answers "it doesn't affect us in production." That answer requires evidence. Without evidence, it sounds like rationalisation.
Reachability data that isn't kept current. Stale reachability classifications can be worse than none. An auditor sees a "not reachable" classification from 18 months ago and asks if it has been re-evaluated since the last release.
The second is more common than the first in customer programs. Continuous reachability is the antidote.
How to fold this into the existing program
Three steps:
Generate reachability classification on every release. Tie it to CI; produce the artefacts as build outputs.
Tag findings in your tracker with reachability status. Make the classification visible alongside CVSS and SLA fields.
Include reachability in the SLA exception process. "Not reachable" is a valid reason to extend SLA; document it explicitly in the exception form.
The cumulative effect: when the auditor asks, the answer is in the system, not in the head of one engineer.
How Safeguard Helps
Safeguard's reachability classification is generated continuously and stored as audit-grade evidence per finding. The classification is queryable via API for evidence packets, exportable as CSV/JSON for audit submissions, and timestamped with the analysis configuration. For SOC 2 (and ISO 27001, and EU CRA self-assessment) workflows, this turns a recurring audit conversation from an uncomfortable defence into a documented exhibit.