Your SOC 2 Type II audit is scheduled. Somewhere in the auditor's request list is a line that looks harmless:
"Provide evidence of your vulnerability management process, including identification, prioritization, and remediation of vulnerabilities during the observation period."
This maps to CC7.1 of the Trust Services Criteria — and it's one of the most commonly flagged gaps in SOC 2 audits. Not because companies don't scan. Because they can't prove what happened after the scan.
This article walks through what auditors actually request for CC7.1, why most vulnerability management evidence falls short, and how to build a defensible audit evidence trail without an enterprise GRC platform.
Prefer automation over spreadsheets? You can generate much of this evidence locally with VulnPilot:
pip install vulnpilot vulnpilot analyze scan.csv --evidence soc2Runs locally. MIT licensed. No cloud upload. github.com/PatchVex/vulnpilot
What CC7.1 actually requires
The control text:
The entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
In practice, a Type II auditor sampling your observation period asks for some combination of:
- Your vulnerability management policy — the documented process
- Scan reports — proof scans actually ran, at the stated frequency, across the stated scope
- Prioritization rationale — how you decided what to fix first
- Remediation records — tickets, timelines, and closure evidence
- Re-scan or validation evidence — proof the fix actually worked
Most companies can produce #2. The audit findings pile up at #3, #4, and #5.
The gap auditors flag most: "show me how you prioritize"
A scanner export with thousands of findings is not evidence of a process — it's evidence of a scanner. When an auditor asks "walk me through how this Critical finding was handled," the failing answers sound like:
- "We work through them by CVSS score" (then why are these 9.8s from January still open?)
- "The engineers know which ones matter" (undocumented = doesn't exist, in audit terms)
- "We fixed the important ones" (define important; show the definition existed before the audit)
What passes: a documented, deterministic prioritization methodology applied consistently. Deterministic matters — if the auditor re-runs your process on the same inputs, they should get the same list. Consistency is what auditors evaluate: the methodology itself can vary between organizations, but it should be documented, repeatable, and applied consistently over time. Risk-based prioritization using public threat intelligence (CISA KEV for confirmed exploitation, EPSS for exploitation probability) satisfies this cleanly, because the inputs are public, timestamped, and auditable.
What this looks like with real numbers
Example (illustrative): Consider a scan with approximately 4,800 findings. CVSS alone rates 190 of them as Critical. Cross-referenced against threat intelligence: 19 are in the CISA KEV catalog (confirmed exploited in the wild) and 31 have EPSS scores above 90%.
The defensible position: those ~40 findings remediated first, documented as such, with the remaining CVSS-only criticals scheduled by the written methodology. The auditor sees a risk-based vulnerability management process with rationale — not a team drowning in 190 "criticals" with no order.
The second gap: proving remediation actually happened
Closing a Jira ticket is not proof a vulnerability was fixed. Auditors increasingly ask for validation evidence — a subsequent scan showing the finding is gone.
Two traps here:
Trap 1 — the missing re-scan. Teams patch, close the ticket, and never scan again until next quarter. The evidence trail shows intent, not outcome.
Trap 2 — the shrinking scope. A finding "disappears" from the next scan because the host wasn't scanned at all. If your evidence claims it as remediated, and the auditor notices the host missing from the scan scope, you now have a credibility problem larger than the original finding. Scope consistency between scans is something experienced auditors specifically check.
The observation-period problem
Type I audits assess a point in time. Type II audits assess operation over 6–12 months — which means evidence must be contemporaneous. You cannot reconstruct six months of scan history the week before fieldwork. Timestamped records of each scan, each prioritization run, and each remediation cycle must exist as they happened.
This is the single best reason to automate evidence collection early: history cannot be backfilled.
The lifecycle your evidence must cover
Nessus / Qualys scan
│
▼
KEV + EPSS enrichment
│
▼
Prioritize (documented methodology)
│
▼
Remediate (tickets, timelines)
│
▼
Verify (re-scan, scope-consistent)
│
▼
Evidence pack + sign-off
Each arrow is a place auditors probe. Evidence that covers only the first two steps is where most audit findings come from.
What a defensible CC7.1 evidence pack looks like
For each scan cycle, one document containing:
- Scan metadata — date, scope, source file, tool
- Summary metrics — total findings, confirmed-exploited (KEV) matches, high-probability (EPSS) findings, severity distribution
- The prioritization methodology — written down, with weights, applied identically every cycle
- The prioritized list — top findings with scores and rationale flags
- Remediation status — fixed / in progress / risk-accepted, with dates
- Validation results — which previously-open findings are confirmed absent in the current scan
- Management sign-off — reviewed-by signature and date
Assemble this manually and it's a few hours per cycle. Skip it and it's a finding. Automate it and it's a command.
The same evidence package can help support vulnerability management evidence for controls such as ISO 27001 A.8.8 (management of technical vulnerabilities), HIPAA Security Rule requirements related to risk management, and DPDP security safeguard documentation. Organizations should determine whether additional evidence is needed based on their specific audit or regulatory requirements.
Automating it
This is exactly why we built these features into VulnPilot, a free, local-first CLI:
# Prioritized findings + CC7.1 evidence pack from a Nessus export
vulnpilot analyze scan.csv --evidence soc2
# Validate remediation against your previous scan
vulnpilot verify new_scan.csv
The evidence pack includes the methodology, prioritized findings, control mapping, and sign-off block. Every run is recorded to a local history database — building the contemporaneous trail Type II requires, from your first scan. And verify flags hosts missing from a new scan's scope instead of counting their findings as fixed — the exact trap auditors check for.
Everything runs locally. Scan data never leaves your machine.
What this doesn't replace
Honest limits: an evidence pack covers the vulnerability management control — one control, done properly. It is not a full SOC 2 program, does not write your policy, and does not replace your auditor's judgment. Asset criticality and business context still belong to your team.
New to KEV and EPSS? Start with the first article in this series: Why CVSS Alone Doesn't Tell You What to Patch First.
The one-sentence summary
Vulnerabilities are expected. An undocumented or inconsistent vulnerability management process is what creates audit findings. A repeatable process backed by contemporaneous evidence is far easier to defend than a last-minute reconstruction during an audit.
If you're preparing for a SOC 2 Type II audit, try generating your next vulnerability evidence pack locally:
pip install vulnpilot
vulnpilot analyze scan.csv --evidence soc2
Free. Open source. Runs entirely on your machine.
References
- AICPA Trust Services Criteria
- CISA Known Exploited Vulnerabilities Catalog
- FIRST Exploit Prediction Scoring System (EPSS)
Built by PatchVex — privacy-first security tools for DevSecOps teams.
Top comments (0)