DEV Community: PatchVex

SOC 2 CC7.1: What Auditors Actually Ask For in Vulnerability Management

PatchVex — Thu, 02 Jul 2026 11:01:04 +0000

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 soc2
Runs 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

Built by PatchVex — privacy-first security tools for DevSecOps teams.

Why CVSS Alone Doesn't Tell You What to Patch First (And How KEV + EPSS Changes Everything)

PatchVex — Wed, 01 Jul 2026 19:51:17 +0000

Your Nessus scan just finished. You have 4,847 findings. CVSS says 200 of them are Critical.

Where do you actually start?

If your answer is "sort by CVSS score and work from the top" — you are making the same mistake most security teams make. And it is costing you hours every week while leaving your most dangerous vulnerabilities unpatched.

This article isn't arguing that CVSS is bad. CVSS is an excellent severity metric. The problem is using it as the only prioritization metric.

Try VulnPilot — free and open source

pip install vulnpilot
vulnpilot update-feeds
vulnpilot analyze scan.csv

Runs locally. MIT licensed. Your scan data never leaves your machine.
github.com/PatchVex/vulnpilot

The problem with CVSS

CVSS (Common Vulnerability Scoring System) measures the theoretical severity of a vulnerability. It answers the question: how bad could this be in the worst case?

It does not answer: is anyone actually exploiting this right now?

A CVSS 9.8 vulnerability on an isolated internal test server with no internet access is less urgent than a CVSS 7.0 vulnerability on your public-facing web server that attackers are actively exploiting today.

CVSS cannot tell you which one to fix first. It was never designed to.

CVSS only	KEV + EPSS + CVSS
Severity score only	Real-world exploit intelligence
Manual cross-referencing	Automatic prioritization
Hours of triage per scan	Results in seconds
No exploit context	Confirmed exploitation data
Misses active threats	Flags what attackers use today

What CISA KEV actually means

The Cybersecurity and Infrastructure Security Agency maintains a catalog called the Known Exploited Vulnerabilities (KEV) list.

This is not a theoretical list. Every CVE on this list has been confirmed as actively exploited in the wild. Real attackers. Real infrastructure. Right now.

At the time of writing, the KEV catalog contains only a tiny percentage of all published CVEs — those confirmed to be actively exploited in the wild.

If your Nessus scan returns 4,847 findings and 19 of them match the KEV catalog — those 19 are your actual priority. Not the 200 that CVSS calls Critical.

What EPSS predicts

FIRST (Forum of Incident Response and Security Teams) publishes the Exploit Prediction Scoring System (EPSS).

EPSS uses machine learning trained on real-world exploitation data to estimate the probability that a CVE will be exploited in the next 30 days.

A CVE with a high EPSS score has a high probability of being exploited in the near term. A CVE with a very low EPSS score is unlikely to be exploited soon — regardless of its CVSS score.

This is far more actionable than severity alone.

A real example — Log4Shell

CVE-2021-44228 (Log4Shell) has:

CVSS: 10.0 (maximum)
KEV: Yes — confirmed exploited
EPSS: Very high exploitation probability

Now consider a CVSS 9.8 vulnerability in an obscure library with no public exploit code, no KEV entry, and a very low EPSS score.

On a CVSS-sorted list it sits above Log4Shell. In reality it should be deprioritized until the confirmed exploited vulnerabilities are patched.

CVSS cannot make this distinction. KEV and EPSS can.

The composite scoring approach

VulnPilot combines KEV, EPSS, CVSS, and scanner severity into a transparent composite score designed to prioritize real-world risk.

The current scoring model uses:

Signal	Weight	What it tells you
CISA KEV	40%	Actively exploited right now
FIRST EPSS	35%	Exploitation probability
CVSS	15%	Severity context
Scanner rating	10%	Additional context

Any finding confirmed in the KEV catalog scores a minimum of 75/100 regardless of other factors. KEV means patch immediately — no further analysis needed.

The weighting is intentionally transparent and may evolve based on community feedback.

How VulnPilot works

Nessus CSV (local only)
        │
        ▼
   VulnPilot CLI
        │
   ┌────┴────────────┐
   │  CISA KEV       │  ← downloaded from cisa.gov
   │  FIRST EPSS     │  ← downloaded from first.org
   │  CVSS           │  ← from your scan data
   └────┬────────────┘
        │
        ▼
  Composite Score
        │
        ▼
  Prioritized Report

Only public threat intelligence feeds are downloaded. Your vulnerability scan data never leaves your machine.

What this looks like in practice

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  VulnPilot by PatchVex — Vulnerability Prioritization
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Total findings   : 4,847
  KEV matches      : 19    ← fix these first
  EPSS >= 90%      : 31
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  #  Score   Priority      CVE              Finding
  1  100.0   CRITICAL NOW  CVE-2021-44228   Log4Shell ★KEV
  2  100.0   CRITICAL NOW  CVE-2023-34362   MOVEit SQLi ★KEV
  3  99.8    CRITICAL NOW  CVE-2020-1472    Zerologon ★KEV
  4  11.5    LOW           N/A              SSH Weak Ciphers

The SSH weak ciphers finding sits at the bottom where it belongs — no KEV match, low EPSS. On a CVSS sort it would consume time that should go toward patching actively exploited vulnerabilities.

The time cost of doing this manually

Most security teams spend hours per scan cycle doing this manually:

Export Nessus CSV
Open in Excel
Sort by CVSS
Manually check KEV catalog
Manually check EPSS scores
Build remediation priority list
Repeat next week

The data already exists. The challenge is bringing it together automatically.

The missing piece for many teams is automating this workflow — locally, privately, without uploading scan data to a third-party service.

Why local-first matters

Vulnerability scan results often contain internal hostnames, IP addresses, software inventories, and infrastructure details. Many organizations prohibit uploading this information to third-party services. A Nessus CSV is essentially a map of every weakness in your infrastructure.

VulnPilot performs all analysis locally on your machine. Only public threat feeds are downloaded. Nothing about your infrastructure is ever transmitted.

What VulnPilot doesn't do

Being honest about limitations builds trust:

It does not replace your vulnerability scanner
It does not eliminate false positives
It does not make business risk decisions for you
It does not tell you asset criticality — you still need to consider what each host does

It helps prioritize remediation using publicly available exploit intelligence. The rest of the decision still belongs to your team.

VulnPilot currently supports Nessus CSV exports, with additional scanner support planned in future releases.

Install and try it

pip install vulnpilot
vulnpilot update-feeds
vulnpilot analyze scan.csv

# Generate a shareable HTML report
vulnpilot analyze scan.csv --html report.html

Free and open source. MIT licensed. Python 3.10+.

CVSS was designed to measure severity — not remediation priority.

If you're still sorting thousands of findings by CVSS alone, you're doing far more work than necessary.

VulnPilot combines publicly available exploit intelligence to help you answer one simple question:

What should I patch first?

Links:

Feedback welcome — drop a comment below or open a GitHub issue.

References

Built by PatchVex — privacy-first security tools for DevSecOps and security teams.