Controls5 May 2026 7 min read

SOC 2 Vulnerability Management: Scan, Patch, Evidence

Build a SOC 2-compliant vulnerability management program. Covers scan frequency, patch SLAs, Snyk and AWS Inspector configuration, and how to evidence remediation.

Key Takeaways

Vulnerability management addresses CC4.1 (monitoring), CC7.1 (baseline), and CC4.2 (deficiency remediation).
Run vulnerability scans at least monthly — weekly or continuous scanning is better.
Define patch SLAs by severity: Critical within 24-72 hours, High within 30 days, Medium within 90 days.
Snyk for application dependencies, AWS Inspector for infrastructure, Qualys/Tenable for comprehensive coverage.
Track vulnerabilities in a ticketing system (Jira) with SLA compliance reports as evidence.

In this guide

Vulnerability Management and SOC 2
Scanning Tools: Snyk, Inspector, Qualys
Defining Patch SLAs by Severity
Tracking and Remediation Workflow
Container Image Scanning
Vulnerability Management Evidence

Vulnerability Management and SOC 2

Vulnerability management is the process of identifying, evaluating, prioritizing, and remediating security vulnerabilities across your systems. For SOC 2, it addresses CC4.1 (ongoing monitoring — scanning is a continuous monitoring activity), CC4.2 (communicating deficiencies — vulnerability findings must be reported and remediated), and CC7.1 (identifying deviations from baseline).

A vulnerability management program has four phases: scan (identify vulnerabilities), assess (evaluate severity and risk), remediate (fix or mitigate), and verify (confirm the fix). All four phases must be evidenced for a Type II audit.

Scanning Tools: Snyk, Inspector, Qualys

Snyk: developer-focused tool that scans application dependencies (package.json, requirements.txt, pom.xml), container images, and Infrastructure as Code for known vulnerabilities. Integrates with GitHub PRs and CI/CD pipelines to shift scanning left. Best for application-layer vulnerability management.

AWS Inspector v2: Amazon's managed vulnerability assessment service for EC2 instances, ECR container images, and Lambda functions. Uses the CVSS scoring system. Aggregates findings in AWS Security Hub. Zero configuration required — enable Inspector for an account and it automatically discovers and scans resources.

Qualys VMDR or Tenable Nessus: enterprise-grade vulnerability scanners that cover a broader surface including network devices, databases, and web applications. Suitable for larger organizations or those required to demonstrate comprehensive vulnerability management by enterprise customers.

For most SaaS companies, Snyk + AWS Inspector provides good coverage: Snyk for application code and dependencies, Inspector for the infrastructure and container layers.

Defining Patch SLAs by Severity

Your vulnerability management policy must define remediation timeframes by severity. Use CVSS scoring (or your scanner's severity classification) as the basis: Critical (CVSS 9.0-10.0): remediate within 24-72 hours. High (CVSS 7.0-8.9): remediate within 30 days. Medium (CVSS 4.0-6.9): remediate within 90 days. Low (CVSS 0.1-3.9): remediate within 180 days or accept with justification.

For vulnerabilities that cannot be patched within SLA (no patch available, or patching causes breakage), document an exception with: the vulnerability details, the reason it cannot be remediated, compensating controls in place, and a target date for resolution.

Auditors will pull vulnerability findings and check that each finding was remediated within your documented SLA. SLA breaches without documented exceptions are CC4.2 findings.

Tracking and Remediation Workflow

Integrate your vulnerability scanner with your ticketing system to automatically create tickets for new findings. Snyk integrates with Jira — configure it to create a Jira ticket for every new Critical or High finding, assigned to the relevant engineering team.

Set up a weekly vulnerability triage meeting: review new Critical and High findings, assign owners, confirm remediation is in progress for findings approaching SLA. Document the meeting in minutes — this is CC4.2 evidence that deficiencies are being reviewed and actioned.

Generate a monthly vulnerability metrics report: total open vulnerabilities by severity, findings opened vs closed in the month, SLA compliance rate (percentage closed within SLA). This report goes to your security leadership review and serves as ongoing monitoring evidence.

Container Image Scanning

If you deploy containerized workloads (ECS, EKS, Kubernetes), container image scanning is essential. Vulnerabilities in the base image or application dependencies are packaged into the image and run in production until the image is rebuilt.

Enable ECR image scanning: in ECR repository settings, enable "Scan on push" and enable enhanced scanning with AWS Inspector. This automatically scans images on push and on a schedule. Configure your CI/CD pipeline to fail on Critical vulnerabilities in images before they are pushed to ECR.

Snyk Container scans Docker images and can be integrated in the Dockerfile build step: snyk container test your-image:tag --severity-threshold=high. Block the build if high or critical vulnerabilities are found.

Vulnerability Management Evidence

(1) Vulnerability management policy with patch SLAs by severity. (2) Snyk project list showing active scanning. (3) AWS Inspector finding summary from the audit period. (4) Jira (or ticketing system) export showing vulnerability tickets, assigned owners, and closure dates. (5) SLA compliance report showing percentage of findings closed within SLA. (6) Exception log for findings not remediated within SLA with justifications. (7) Monthly vulnerability triage meeting minutes.

Frequently Asked Questions

How often do we need to scan for vulnerabilities for SOC 2?

The AICPA criteria don't specify a frequency, but most auditors expect at minimum monthly scanning. Continuous scanning tools (Snyk on every PR, AWS Inspector on push and scheduled) provide better coverage. For a Type II audit, you need to show the scanning process operated throughout the audit period — a single scan at the start is insufficient.

We have 500+ open Medium vulnerabilities — do we need to fix all of them for SOC 2?

You need to demonstrate a program, not zero vulnerabilities. Show that: (1) you know what you have, (2) Critical and High are being remediated within SLA, (3) Medium has a plan, and (4) you accept Lows with justification. An auditor who sees 500 open Mediums with a tracking system and a remediation roadmap is much less concerned than one who sees 5 open Mediums with no tracking at all.

Does penetration testing overlap with vulnerability scanning for SOC 2?

They are complementary. Vulnerability scanning is automated and identifies known vulnerabilities against a database of CVEs. Penetration testing is manual and identifies how an attacker could chain vulnerabilities to achieve a specific objective (like data exfiltration). Both are expected for SOC 2 — scanning satisfies CC4.1 ongoing monitoring, penetration testing satisfies CC4.2 separate evaluation.

How do we handle zero-day vulnerabilities in our patch SLA?

Zero-days require an expedited response outside of normal SLA. Your vulnerability management policy should include an emergency patching procedure for zero-days and actively exploited vulnerabilities (CISA KEV list). Document when you learned of the vulnerability, what compensating controls were applied immediately, and when the patch was applied.

Do we need to scan third-party vendor code for SOC 2?

You are responsible for your system, which includes third-party dependencies you have incorporated. Snyk open source scanning covers this — it scans your package-lock.json or requirements.txt to identify vulnerable dependencies, even if the code is third-party. You cannot patch third-party code directly, but you can upgrade the dependency version or apply a workaround.