Preparing for a SOC 2 Audit: Automating Vulnerability Compliance Evidence

SOC 2 vulnerability management
security compliance evidence
audit-ready security alerts
SOC 2 audit preparation
SOC 2 compliance automation
automating SOC 2 evidence
vulnerability remediation proof
SOC 2 SLA adherence
security audit readiness
accepted risk logs
remediation history tracking
InstaSLA
compliance officer software
CTO audit tools
SOC 2 evidence export
automated vulnerability tracking
SOC 2 type 2 vulnerabilities
security compliance automation
vulnerability management SLA
automated risk acceptance
Preparing for a SOC 2 Audit Automating Vulnerability Compliance Evidence
Back to blog
The SOC 2 Vulnerability Management Mandate
What Auditors Actually Look For

1. Proof of SLA Adherence (Time-to-Remediate)
2. Accepted Risk Logs (Exception Management)
3. Complete Remediation History (The Paper Trail) Why Severity Alone Isn't Enough Anymore The Trap of Manual Evidence Collection The Anatomy of an Audit-Ready Alert What Automated Evidence Collection Looks Like in Practice Steps to Prepare Your Vulnerability Management for SOC 2 Conclusion Sources & Further Reading Preparing for a SOC 2 Audit: Automating Vulnerability Compliance Evidence For CTOs and compliance officers, the weeks leading up to a SOC 2 audit can feel like a high-stakes scavenger hunt. Your engineering and security teams have been patching systems, closing bugs, and maintaining a strong security posture all year. But in SOC 2 compliance, doing the work is only half the battle. The other half — the part that causes most of the panic — is proving it.

Auditors evaluating vulnerability management don't just want to hear that your team fixes critical bugs. They want time-stamped, verifiable evidence: when a vulnerability was discovered, who owned the fix, how long remediation took, and whether that timeline matched your own documented policy.

Gathering that evidence manually — spreadsheets, ticket exports, screenshots pulled from Slack threads — is a reliable way to burn out your team and still end up with auditor findings. This article breaks down what auditors actually check during the vulnerability management portion of a SOC 2 Type II assessment, why manual evidence collection keeps failing, and what a well-automated evidence pipeline looks like in practice.

The SOC 2 Vulnerability Management Mandate
SOC 2 audits are built on the AICPA's Trust Services Criteria (TSC), a framework whose core structure was set in 2017 and last substantively revised in 2022. Security is the only mandatory category; Availability, Processing Integrity, Confidentiality, and Privacy are added based on what you've committed to customers.

The Security category is organized into nine "Common Criteria" families: control environment (CC1), communication and information (CC2), risk assessment (CC3), monitoring activities (CC4), control activities (CC5), logical and physical access (CC6), system operations (CC7), change management (CC8), and risk mitigation (CC9). Vulnerability management lives primarily in CC7, which has five sub-criteria (CC7.1–CC7.5), with change management support from CC8.

Specifically:

CC7.1 requires detection and monitoring procedures that catch configuration changes introducing new vulnerabilities, and susceptibility to newly discovered ones — in practice, defined hardening standards, infrastructure/software monitoring, change-detection tooling, and vulnerability scans run on a regular cadence and after significant changes.
CC7.2 requires monitoring system components for anomalies that could indicate malicious activity, natural disaster, or error.
CC7.3 requires evaluating those anomalies to determine whether they constitute actual security events, and acting on the ones that do.
CC8.1 requires that changes to infrastructure, data, and software — including the patches that resolve vulnerabilities — go through an authorized, tested, and documented change process.
Auditors in 2026 also increasingly stretch CC9.2 (risk from vendor and business partner relationships) to cover AI vendors and third-party model providers, which is worth flagging if your stack includes LLM APIs, model fine-tuning services, or AI coding assistants — more on that below.

In plain English: you need a systematic way to detect vulnerabilities, evaluate their risk, fix them within a defined and defensible timeline, and prove the whole chain happened as documented.

What Auditors Actually Look For

1. Proof of SLA Adherence (Time-to-Remediate) Most Information Security Policies set remediation windows by severity — something like Critical within 48 hours, High within 14 days, Medium within 30, Low within 90. The auditor samples vulnerabilities from the audit period and checks the actual timeline: when the scanner flagged the issue, when the fix was merged and deployed, and when the scanner confirmed it was resolved. A gap between your stated SLA and the observed timeline is a control exception on your report.

It's worth knowing that severity-only SLA tables are starting to look dated next to where the field is heading. In June 2026, CISA issued Binding Operational Directive 26-04, which moves federal civilian agencies away from flat CVSS-severity timelines toward a four-factor risk model: whether the affected asset is publicly exposed, whether exploitation can be automated, whether it grants full or partial system control, and whether there's evidence of active exploitation. Vulnerabilities that hit all four triggers get a 3-day remediation window plus mandatory forensic triage; lower-risk combinations get 14- or 60-day windows, or can wait for a routine upgrade. It supersedes the older approach under BOD 22-01, which simply gave everything on CISA's Known Exploited Vulnerabilities (KEV) catalog a flat two-week deadline (six months for pre-2021 CVEs).

BOD 26-04 is only binding on federal agencies and FedRAMP cloud providers — it doesn't apply to a typical SaaS company's SOC 2 scope. But it's a useful reference point: auditors and enterprise customers are increasingly receptive to SLA tables that factor in exposure and exploitability rather than CVSS score alone, because it signals a genuinely risk-based program instead of a policy nobody actually follows.

1. Accepted Risk Logs (Exception Management) You can't patch everything immediately. A patch might break a legacy dependency; a "High" CVSS finding might be neutralized by a compensating control like a WAF. Auditors expect a formal Risk Acceptance process for these cases, documenting:

The specific CVE or finding.
The business justification (false positive, compensating control, accepted risk).
An expiration date for the acceptance — it should be reviewed, not permanent.
Sign-off from an authorized person, typically the CISO or CTO.
Undocumented, aging, unpatched vulnerabilities with no risk acceptance on file are one of the most common reasons companies pick up exceptions on an otherwise clean report.

1. Complete Remediation History (The Paper Trail) Auditors want an unbroken chain of custody: scanner alert → engineering ticket → code change → deployment → re-scan confirmation. If pull requests aren't linked back to the originating security ticket, the auditor has no way to verify that the specific fix addressed the specific flagged issue.

This is also where vendor and AI risk increasingly surface. Verizon's 2025 Data Breach Investigations Report found that breaches involving a third party roughly doubled year over year — a trend that's pushed more auditors to ask pointed questions about how you assess vendor and model-provider risk under CC9.2, not just your own codebase.

Why Severity Alone Isn't Enough Anymore
A CVSS score tells you how bad a vulnerability could be in theory — it says nothing about whether anyone is actually exploiting it. Two other signals have become standard complements:

EPSS (Exploit Prediction Scoring System) is a machine-learning model, now on version 4, that estimates the probability a given CVE will be exploited in the next 30 days. It's useful for triaging the long tail of vulnerabilities that will never see a public exploit.
CISA's KEV catalog lists CVEs with confirmed, real-world exploitation — a slower but far more certain signal than EPSS.
Combined, a common prioritization matrix looks like: KEV-listed and high CVSS and high EPSS gets emergency treatment; high EPSS and CVSS but not yet KEV gets patched within the week; high CVSS with low EPSS and no KEV listing gets monitored and patched on the normal cycle.

One caveat worth building into your process: independent research comparing EPSS scores before and after KEV additions found the score often moves far more after a CVE is confirmed as actively exploited than before — in one study of CVEs added to KEV between late 2025 and early 2026, the median EPSS jump after listing was over 100x the movement beforehand. In other words, EPSS is a reasonable prioritization tool for the broad population of CVEs, but it shouldn't be your only trigger for urgent action — pair it with KEV and your own threat intelligence rather than relying on EPSS alone to catch fast-moving exploitation.

The Trap of Manual Evidence Collection
When the audit's Information Request List (IRL) lands, the default response is still, at a lot of companies, a scramble: export scanner data into a spreadsheet, manually cross-reference it against JIRA ticket IDs, screenshot Slack approvals and code merges to prove the right person signed off.

This approach breaks down for a few predictable reasons:

Human error at scale. Manually cross-referencing thousands of rows produces mismatched tickets and missed timestamps — exactly the kind of thing that turns into a control exception.
Point-in-time blindness. Manual collection is retrospective. If a critical vulnerability quietly breached its SLA three months ago, you find out during audit prep, when it's too late to fix — only to document.
Wasted engineering time. Senior engineers taking screenshots of consoles for a week is a poor use of anyone's time, and it corrodes goodwill toward the compliance process.
Data that doesn't reflect current threat intelligence. Trying to manually track SLA timelines that should shift based on live EPSS or KEV status is not something a spreadsheet keeps up with.
The Anatomy of an Audit-Ready Alert
Escaping the manual trap starts with treating evidence generation as a byproduct of the engineering workflow, not a separate task. A well-formed vulnerability alert should carry, from the moment it fires until it's resolved:

Source attribution — which scanner or tool generated it, and exactly when.
Asset context — which repo, service, or environment is affected, so in-scope systems are demonstrably being monitored.
A dynamic SLA — a deadline calculated automatically from your policy and the finding's severity (and ideally its exploitability signals, per the discussion above).
Ownership — an immutable record of who it was assigned to.
Bidirectional status sync — the alert updates automatically when the corresponding pull request merges or the scanner re-verifies the fix, rather than depending on someone remembering to click "resolved" in a dashboard.
Alerts built this way stop being operational noise and start being structured compliance artifacts in their own right.

What Automated Evidence Collection Looks Like in Practice
There's now a fairly mature ecosystem of tools that fill different parts of this pipeline, and most SOC 2-ready vulnerability programs stitch a few of them together rather than relying on one:

Vulnerability and exposure scanners (e.g., Snyk, Wiz, Tenable, Qualys, Rapid7, AWS Security Hub) generate the initial findings and, increasingly, tag them with KEV status and risk-based prioritization scores rather than raw CVSS alone.
Ticketing and version control (Jira, Linear, GitHub, GitLab) hold the actual remediation trail — commit messages, PR reviews, deploy logs — that proves who did what and when.
Compliance automation platforms (e.g., Vanta, Drata, Secureframe, Sprinto, Thoropass) sit across both, continuously pulling evidence from your cloud infrastructure, ticketing system, and scanners so that control mappings reflect live state instead of a snapshot someone took the week before the audit.
The architectural pattern that actually saves audit prep time is the bidirectional sync described above: findings flow into tickets automatically, ticket resolution flows back to the scanner for verification, and the whole chain is exportable on demand rather than reconstructed by hand. Whichever combination of tools you use, that's the property to build for — not any specific vendor.

Steps to Prepare Your Vulnerability Management for SOC 2
Step 1: Define SLAs you can actually meet. Don't write a policy that commits to remediating Medium findings in 7 days if your real engineering velocity is closer to 45. Set severity-based baselines (Critical in 48–72 hours, High in 14–30 days is a common starting point), and consider layering in exposure and exploitability — a public-facing, actively exploited finding deserves a much shorter window than an internal one with no known exploit.

Step 2: Consolidate your security tooling. Auditors are wary of fragmented evidence. If five scanners don't talk to each other, you'll struggle to tell one coherent story about your posture. Bring findings into a single aggregation layer where possible.

Step 3: Automate SLA enforcement and evidence collection. Move off spreadsheets. Every finding should be automatically ticketed, tracked against policy, and logged immutably on resolution or formal risk acceptance.

Step 4: Run a mock audit. A few months before the real thing, pull a sample of 25 closed and 25 open vulnerabilities. Can you produce time-to-remediate evidence for the closed ones in under an hour? Do the open, SLA-breaching ones have a signed risk acceptance on file? If not, that's your gap list.

Step 5: Don't forget vendor and AI risk under CC9.2. If your product relies on third-party APIs, model providers, or AI coding tools, document how you assess their security posture and how quickly you'd know if one of them disclosed a vulnerability. This is a growing area of auditor attention, and it's also relevant if you serve customers in the EU, where the AI Act's general-purpose AI obligations began phasing in from August 2025.

Conclusion
SOC 2 compliance is a real signal of trust to enterprise customers, but it shouldn't cost your engineering team weeks of screenshot-taking every audit cycle. Auditors are looking for a systemic, provable approach: detection that actually works, remediation that respects your own stated timelines, exceptions that are documented rather than ignored, and an evidence trail that holds together without manual reconstruction.

Manual evidence collection is the expensive, error-prone way to get there. Automating it — from scanner to ticket to deploy to verified evidence export — turns vulnerability management from an annual scramble into something closer to a byproduct of doing the work well in the first place.

Sources & Further Reading
AICPA Trust Services Criteria — overview
SOC 2 Common Criteria (CC1–CC9) breakdown
CC7.1 detection and monitoring requirements
CC7 system operations, CC7.2/CC7.3 explained
CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
BOD 26-04 remediation timeline breakdown
CISA BOD 22-01 — KEV catalog and remediation deadlines
EPSS explained, EPSS v4
EPSS lag vs. KEV listing, 2025–2026 study
SOC 2 controls list and CC9.2 AI/vendor risk trends (2026)Compliance evidence