“Show me how you manage vulnerabilities.” When your SOC 2 auditor says this, they don’t want a yes—they want evidence: scan reports, severity ratings, remediation tickets, and dates.
The good news for small teams: the proof is a handful of repeatable artifacts, and most of them can be produced automatically.
Why proving vulnerability management trips up small teams
Vulnerability management is one of the controls every SOC 2 auditor scrutinizes—and it’s where lean teams most often scramble. You probably do fix security issues. The problem is that SOC 2 isn’t satisfied by “we fix things.” It’s satisfied by demonstrable, repeatable evidence that you detect vulnerabilities on a schedule, rate them, fix them within defined timelines, and can prove all of that happened over months.
This is the natural next step after you’ve decided to pursue SOC 2 in the first place. If you’re still at the “an enterprise customer just asked and I’m panicking” stage, start here: An Enterprise Customer Asked for SOC 2. What Should You Do?. Once you’re actually in the readiness process, vulnerability management is the control this guide gets you through.
For context, vulnerability management maps primarily to the CC7.1 criterion in the AICPA Trust Services Criteria—the requirement that you use detection procedures to identify new vulnerabilities—with support from the risk-assessment (CC3.x) and monitoring (CC4.1) criteria. You don’t need to memorize the codes. You need to know what the auditor will ask to see.
Why this evidence is so hard to produce after the fact
Answer: Because vulnerability management is judged over a period of time, and you can’t retroactively create months of history the week before your audit.
Three things catch small teams off guard:
- “We fix stuff” isn’t evidence. Auditors don’t accept good intentions or memory. If a fix isn’t tied to a dated finding and a ticket, from their perspective it didn’t happen.
- Type 2 needs a track record. A Type 2 report attests that controls operated effectively over the observation window—often 3 to 12 months. A single scan run the day before the audit proves nothing about the months prior.
- Scope gaps undermine everything. If your scan only covered the main domain but you also run three subdomains and an API, the auditor sees an incomplete picture—and an incomplete picture reads as an uncontrolled one.
The fix is to set up the right artifacts before your observation window starts, then let them accumulate automatically. For why a point-in-time view isn’t enough on its own, see: Security Monitoring vs. Security Audits: What’s the Difference?.
The 7 pieces of evidence that prove vulnerability management
1) A written vulnerability management policy
What it is: A short, documented policy stating how your company detects, rates, prioritizes, and remediates vulnerabilities—including how often you scan and how fast you fix issues by severity.
Why it matters: This is the first artifact an auditor asks for, because it’s the standard you’ll be measured against. SOC 2 doesn’t dictate exact numbers; it checks that you defined a reasonable process and then followed it. No policy means there’s nothing to test your evidence against.
Prove it:
- Write a one-to-two page policy covering scan frequency, the severity scale you use, remediation timelines per severity, and who owns the process.
- Keep it realistic—if you commit to “weekly scans,” you must produce weekly scan evidence. Don’t promise more than you’ll do.
- Most compliance automation platforms (Vanta, Drata, Secureframe) provide a template you can adapt in an afternoon. Adapt it; don’t copy it blindly.
2) Evidence you actually scan—on a schedule
What it is: Dated, exportable reports from a vulnerability scanner showing that scans ran regularly across the observation window, not just once.
Why it matters: This is the core of CC7.1. The auditor wants to see that detection is continuous and repeatable, with a clear cadence. A folder of timestamped scan reports spanning your observation period is exactly the proof they’re looking for.
Prove it:
- Run scans on the cadence your policy states (continuous or at minimum monthly is typical for SaaS).
- Retain every scan report with its date—don’t overwrite them. The history is the evidence.
- Cover your real attack surface: web applications, network/ports, and TLS/configuration—not just one of them. If you’re choosing a tool, see: Best Vulnerability Scanner for Startups Without a Security Team.
3) An asset inventory that matches your scan scope
What it is: A maintained list of every in-scope asset—domains, subdomains, public IPs, and exposed services—that you can hold up next to your scan reports and show they cover the same things.
Why it matters: Coverage is where vulnerability-management evidence quietly fails. If your inventory lists five subdomains but your scanner only touched two, the auditor sees three unmonitored assets. You can’t prove you manage vulnerabilities on systems you didn’t know you had.
Prove it:
- Keep a live inventory rather than a stale spreadsheet—new subdomains and services appear constantly.
- Reconcile inventory against scan scope: every public asset should be covered, and you should be able to explain any exclusion.
- Automate discovery so forgotten staging sites and preview URLs don’t become silent blind spots. See: How to Discover All Your Internet-Facing Assets (Before Hackers Do).
4) Risk-based severity ratings
What it is: A consistent method for scoring each finding—commonly CVSS combined with asset context (is it production or staging, customer-facing or internal)—so high-risk issues are clearly distinguished from noise.
Why it matters: SOC 2’s risk-assessment criteria expect you to prioritize based on risk, not treat every finding equally. Severity ratings are also what make your remediation SLAs meaningful—“fix criticals in 7 days” only works if you’ve defined what “critical” means.
Prove it:
- Use a documented, repeatable scoring approach (CVSS is the common default) and apply it consistently.
- Layer in context: a critical on your production login page outranks the same critical on an unused staging box.
- Make sure your scan output records the severity, so the rating is part of the evidence, not a judgment call made later.
5) Defined—and met—remediation SLAs
What it is: Timelines in your policy stating how quickly you fix issues by severity (for example: critical in 7 days, high in 30, medium in 90), plus evidence that real findings were actually closed within those windows.
Why it matters: This is where auditors separate paperwork from practice. They’ll pull a sample of findings and check whether each was remediated inside your stated SLA. Defining SLAs you consistently miss is worse than setting modest ones you reliably hit.
Prove it:
- Set timelines you can realistically meet as a small team—then meet them.
- For each sampled finding, be able to show the discovery date and the remediation date, and confirm the gap fits your SLA.
- If you’ll occasionally miss an SLA (everyone does), document a risk-acceptance or exception process so the auditor sees a controlled decision, not a gap.
6) A closed remediation loop you can trace
What it is: A clear trail from finding → ticket → fix → re-scan that confirms it’s gone. Each vulnerability links to a record showing it was tracked and resolved, not just noticed.
Why it matters: A list of open vulnerabilities with no resolution trail tells an auditor your process detects but doesn’t manage. The closed loop—especially a re-scan proving the issue no longer appears—is the single most convincing piece of evidence that vulnerability management actually works.
Prove it:
- Turn findings into tickets in whatever you already use (Linear, GitHub Issues, Jira) so remediation is tracked, dated, and assignable.
- Re-scan after fixing and keep the “after” report showing the finding resolved.
- Plain-English remediation notes help here—if anyone on the team can act on a finding, the loop closes faster. Fix guidance that replaces CVE codes with steps is the difference between a ticket that sits and one that gets done.
7) Continuous monitoring across the observation window
What it is: Evidence that detection and remediation ran consistently over the entire Type 2 period, not as a pre-audit sprint.
Why it matters: Type 2 is the whole point of the observation window—the auditor is testing that controls operated effectively over time. Continuous monitoring produces that timeline as a natural byproduct: an unbroken record of scans, findings, and fixes from start to end of the period. It’s also what keeps your real security honest between audits, since fast-moving codebases regress constantly. See: Vibe-Coded SaaS Security: Hidden Risks (and How Founders Can Fix Them Fast).
Prove it:
- Switch from occasional manual scans to continuous monitoring so the evidence builds itself.
- Make sure new assets are picked up automatically and enter the same detect-rate-fix loop.
- At audit time, export the full history for the observation window—an auditor would rather see a steady record than a perfect-but-recent one.
Your SOC 2 vulnerability-management evidence checklist
Set this up before your observation window starts, and the evidence accumulates on its own. Run through it in a single sitting:
- Write the policy (45 min). Scan frequency, severity scale, remediation SLAs per severity, process owner. One to two pages. Adapt your automation platform’s template.
- Turn on continuous scanning (30 min). Cover web apps, network/ports, and TLS across every public asset. Confirm reports are dated and exportable.
- Reconcile inventory vs. scope (30 min). List every domain, subdomain, IP, and service. Confirm each is in scan scope. Investigate anything your scanner isn’t touching.
- Confirm severity ratings are captured (15 min). Each finding should carry a CVSS-based score plus production/staging context, recorded in the output.
- Wire findings into your tracker (30 min). Findings become dated tickets in Linear/GitHub/Jira, assigned to an owner.
- Do one full loop now (varies). Take a current finding, fix it, re-scan, and save the “resolved” report. That’s your template evidence for the auditor.
- Set a reminder to export monthly (5 min). A monthly evidence export keeps the observation-window record complete and audit-ready.
For the broader external-surface view that feeds steps 2 and 3, see: External Attack Surface Management: The Complete 2025 Guide for SMBs.
FAQs
Which SOC 2 control covers vulnerability management?
Vulnerability management maps primarily to CC7.1 in the AICPA Trust Services Criteria, which requires using detection procedures to identify new vulnerabilities. It’s supported by the risk-assessment criteria (CC3.x), which expect risk-based prioritization, and the monitoring criteria (CC4.1). You don’t need to cite the codes—you need evidence of detection, rating, and remediation.
How often do I need to scan for SOC 2?
SOC 2 doesn’t mandate a fixed frequency, but you must define a cadence in your policy and follow it consistently. Most SaaS companies run continuous monitoring or at least monthly scans. The key is that whatever frequency you commit to, your dated scan reports must prove you actually met it across the observation window.
Do I need a paid vulnerability scanner to pass SOC 2?
You need credible, dated evidence of regular scanning across your in-scope assets—the tool matters less than the coverage and the record. Many small teams use a continuous monitoring platform because it produces the dated reports and history automatically, which is exactly what auditors sample. Free or manual scanning can work but is harder to evidence consistently over months.
What remediation timeline does SOC 2 require?
SOC 2 doesn’t prescribe specific timelines; you define remediation SLAs by severity in your policy, and the auditor checks that you met them. A common pattern is critical within 7 days, high within 30, and medium within 90, but you should set windows your team can realistically hit. Meeting modest SLAs consistently beats missing aggressive ones.
Does SOC 2 require a penetration test in addition to scanning?
A penetration test isn’t strictly mandated by the criteria, but many auditors and enterprise customers expect an annual one, and it strengthens your vulnerability-management evidence. Treat scanning as the continuous control and a pen test as the periodic deep check. The two complement each other rather than replacing one another.
What evidence does the auditor actually ask to see?
Typically: your written vulnerability management policy, dated scan reports spanning the observation window, your asset inventory reconciled against scan scope, severity ratings on findings, and a sample of findings traced from discovery through remediation within your stated SLA. A re-scan confirming a fix is resolved is especially convincing.
Can I get a SOC 2 report if I still have open vulnerabilities?
Yes. SOC 2 doesn’t require zero vulnerabilities—it requires a working process for managing them. Open findings are fine as long as they’re within your remediation SLA windows or formally risk-accepted with documentation. What fails an audit is undetected vulnerabilities or findings left open past your own stated timelines with no explanation.
Final Thoughts
Proving vulnerability management for SOC 2 isn’t about being perfectly secure—it’s about showing a controlled, repeatable loop: detect, rate, fix within a deadline, and prove it happened over time. Auditors aren’t impressed by zero findings; they’re convinced by a clean trail from discovery to resolution, running consistently across the observation window.
The teams that breeze through this control don’t do more work at audit time—they set up the right artifacts once and let continuous monitoring build the evidence for them. Write the policy, scan everything on a schedule, track findings to closure, and keep the history. When the auditor says “show me,” you send a link instead of scrambling.
Want vulnerability-management evidence that builds itself—without a security hire?
Try Warin — continuous external monitoring with dated scan history, risk-prioritized findings, and plain-English fix guides, so the proof is ready before your auditor asks.
Start your free trial.