SOC 2 vulnerability management: scanning, patching, and remediation SLAs
SOC 2 does not literally mandate a vulnerability scanner, but auditors treat scanning and timely remediation as a point of focus they expect to see. The gap that fails audits is almost always unremediated criticals sitting past their SLA.
How vulnerability management maps to the criteria
Vulnerability management lives primarily under CC7.1, which addresses detecting configuration changes and conditions that could introduce new vulnerabilities, with a recognized point of focus that the entity conducts infrastructure and software vulnerability scans on a periodic basis and after significant changes, then acts to remediate findings in a timely manner. It also connects to CC4 (Monitoring Activities), because scanning is one of the ongoing evaluations management uses to confirm controls remain effective, and to the risk assessment criteria in CC3, since remediation should be risk-based rather than treating every finding as equal. It is worth being precise that the AICPA criteria do not name a specific tool, scan frequency, or SLA; those are points of focus and implementation choices, not literal mandates. What auditors do expect is a defensible program: a documented policy, evidence that scanning happened across the period, and proof that findings were prioritized and closed. The absence of any explicit numeric requirement is exactly why your own documented SLAs become the standard you are measured against.
Scanning cadence and coverage
Common baselines are monthly authenticated scans of infrastructure with quarterly internal scans, though higher-risk or internet-facing systems are often scanned weekly, and scans should always run after significant changes such as major releases or infrastructure rebuilds. Coverage matters as much as frequency: a program that scans the network but ignores container images, dependencies, or cloud configuration leaves blind spots auditors will notice. Modern stacks typically combine several tools, such as a cloud or host scanner (for example Tenable, Qualys, or AWS Inspector), software composition analysis for open-source dependencies, container image scanning in the CI pipeline, and cloud security posture management for misconfigurations. Whatever combination you use, the policy should state the cadence, the scope, and the authority for each scan type so the cadence is auditable rather than ad hoc. A frequent gap is scanning only unauthenticated from the outside, which dramatically understates real exposure and produces evidence that looks thin to an experienced auditor.
Risk-based remediation SLAs
The mechanism auditors gravitate toward is the remediation SLA: a documented commitment, usually keyed to CVSS severity, for how quickly each class of finding must be fixed. Typical patterns put critical issues at a few days to two weeks and high-severity issues somewhere in the two-to-four-week range, with medium and low findings on longer cycles, and many teams anchor their thresholds to references like CISA's guidance of fifteen days for critical and thirty days for high. The specific numbers matter less than that they are written down, justified by risk, and consistently met, because the SLA you publish is the bar the auditor will hold you to. Severity should be risk-adjusted rather than taken raw from the scanner: an exploitable critical on an internet-facing system is not the same as the same CVE on an isolated internal host, and a documented risk-acceptance or exception process handles the cases you legitimately cannot fix on schedule. Auditors will look closely at exceptions, so each one should have a rationale, a compensating control, an owner, and an expiry date rather than being an open-ended waiver.
Patch management and the role of penetration testing
Patch management is the operational arm of remediation and should be documented as its own process: how patches are identified, tested, approved through change management, and deployed, including emergency patching for actively exploited vulnerabilities. Auditors appreciate seeing the link between a scan finding, the ticket it generated, the patch or fix, and the rescan confirming closure, because that chain demonstrates the loop actually closes. Penetration testing is related but distinct: it is typically an annual point-in-time assessment that validates whether your controls hold up against a skilled human, whereas scanning is the continuous, automated baseline. Auditors generally expect at least an annual pen test for SOC 2, want to see the report, and specifically want evidence that the findings were tracked to remediation just like scan results. Treating the pen test as a checkbox that produces a report nobody acts on is a recognizable weakness; the value to the audit is the remediation evidence that follows it.
What auditors request and where programs fail
Expect requests for the vulnerability management policy, scan results spanning the entire audit period rather than a single recent run, the remediation tracking system showing tickets with severity, owner, and dates, and proof of SLA adherence such as time-to-remediate metrics. They will also ask for the pen test report and its remediation tracking, the patch management records, and the documented exceptions with their justifications. The most common failure is straightforward: open critical or high findings sitting well past their stated SLA with no exception on file, which directly contradicts the CC7.1 point of focus about timely remediation. Other recurring gaps include scan evidence that only covers part of the period, no rescan to confirm fixes, severities accepted from the tool without risk adjustment, and a policy whose SLAs the actual data plainly does not meet. The cleanest programs make the auditor's job easy by producing a single tracker that ties scans, tickets, SLAs, and closures together over the full period.