For SOC 2 Type 2, vulnerability management means you scan on a stated cadence and after significant change, rank findings, fix within targets you chose, document exceptions, and keep dated proof for the whole observation period. The criteria set no fixed numbers. Your policy sets them, and the auditor tests you against it.
What the criteria actually say
The anchor is CC7.1: the entity uses detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. The points of focus describe defined configuration standards, monitoring for noncompliance, change detection and, directly relevant here, conducting infrastructure and software vulnerability scans on a periodic basis and after significant changes, with timely remediation of deficiencies.
Note what is absent: no mandated scan frequency and no mandated fix times. Type 2 adds the test of whether the controls operated over the period, per the AICPA description. So the discipline is consistency with your own commitments.
Set a cadence you can keep
Write one table into your vulnerability procedure.
- What is scanned: infrastructure, hosts, containers, application dependencies, code, web applications.
- How often: for example continuous for dependencies and at least monthly for infrastructure, plus a scan after significant change. Choose numbers you will hit every time.
- Who reviews results and where findings are recorded.
- Severity ranking method, such as CVSS plus exploitability and exposure context.
- Target fix times per severity. Example targets are a policy choice, not a SOC 2 rule.
A short, achievable table beats an ambitious one. Missed targets become exceptions the auditor will find.
Evidence that works across a period
Scan history. Reports or exports with dates, scope and tool name for every scheduled scan, not only the latest. Gaps in the sequence stand out.
Finding lifecycle. For each finding above your threshold: detection date, severity, assignee, fix or exception, closing date, and a link to the pull request or change record. That ties vulnerability work to change management (CC8.1).
Population lists. Keep a complete list of high and critical findings during the period so the auditor can sample from it.
Exceptions. A risk acceptance with owner, reason, compensating control and expiry date. Accepted risks need reviewing when they expire.
Review records. Meeting notes or tickets showing someone reviewed the scan outputs on schedule (CC4.1 expects ongoing evaluations of controls).
Post-change scans. Evidence that a scan ran after significant change, such as a major release or infrastructure move.
Exploitability and noise
Raw counts invite arguments. Rank by whether the vulnerable code is reachable and whether an exploit exists, then record that reasoning in the ticket. Auditors accept a documented rationale for deferring a low-risk finding more easily than an unexplained backlog.
Common failure points
Scans that stop when the person who ran them leaves. New assets, such as a new cloud account or repository, never added to scanning. Findings closed without a link to a fix. Exceptions without an expiry. Policy that promises daily scans while the tool runs weekly.
What to do
- Agree the cadence and fix time table with engineering and the compliance owner.
- Make sure every in-scope repository, host and account is registered for scanning.
- Schedule scans so they do not depend on a person remembering.
- Route findings into your ticket system with severity and due date.
- Hold a recurring review and keep notes.
- Maintain an exception register with expiry dates.
- Export a monthly evidence bundle: scan list, open critical and high findings, closures, exceptions.
Quick check
How often must I scan for SOC 2?
The criteria say periodically and after significant changes without fixing a number. Your policy sets the cadence and the auditor tests that you followed it.
Do I have to fix every vulnerability?
No. You must handle findings according to your policy, which can include documented acceptance of low-risk items.
How Safeguard helps automate this
This is the control where automation changes the workload most. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so scan evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability, which help you rank what is actually exploitable. Autonomous remediation can open tested fix pull requests for vulnerable dependencies and other findings, which also creates the change record. It is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Safeguard does not replace your auditor. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): CC7.1, CC4.1, CC8.1 and the Type 2 description. Paraphrased.
Last reviewed: 18 October 2026.
