SOC 2 Compliance: What Your Vulnerability Scans Need to Cover

SOC 2 Type II certification has become the de facto trust signal for SaaS companies selling to enterprise customers. But while most organizations understand they need vulnerability scanning as part of their SOC 2 program, far fewer understand what those scans need to cover, how frequently they must run, and what evidence auditors actually expect to see. This guide breaks down the specific vulnerability scanning requirements mapped to the Trust Services Criteria, so you can build a program that passes audits without scrambling at the last minute.

Understanding SOC 2 and Vulnerability Scanning

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA that evaluates how organizations manage customer data. Unlike prescriptive standards like PCI DSS, SOC 2 is criteria-based — it defines goals your controls must achieve without mandating specific technologies or scanning frequencies. This flexibility is both a strength and a source of confusion.

The framework is built around five Trust Services Criteria (TSC):

• Security (CC) — Protection against unauthorized access (required for all SOC 2 reports)
• Availability (A) — System uptime and operational resilience
• Processing Integrity (PI) — Accuracy and completeness of data processing
• Confidentiality (C) — Protection of confidential information
• Privacy (P) — Collection, use, retention, and disposal of personal information

Vulnerability scanning touches primarily the Security criteria but also intersects with Availability (ensuring scans don't reveal DoS vectors), Confidentiality (verifying encryption and access controls), and Processing Integrity (confirming data validation controls are in place).

"SOC 2 doesn't prescribe a specific scanner or cadence — but your auditor will absolutely question whether your vulnerability management program is 'suitably designed and operating effectively.' That's where the details matter."

Trust Services Criteria That Require Scanning

Let's map the specific Common Criteria (CC) controls to vulnerability scanning activities. Understanding this mapping is critical because auditors evaluate your controls against these exact criteria.

CC7.1 — Monitoring for New Vulnerabilities

This criterion requires that you have processes to identify and evaluate new vulnerabilities. For most organizations, this translates to:

• Automated vulnerability scanning on a defined schedule (weekly or more frequent for production systems)
• Subscription to vulnerability intelligence feeds (NVD, vendor advisories, CISA KEV)
• A documented process for triaging new vulnerability disclosures against your asset inventory

CC6.1 — Logical Access Controls

Your scans must verify that logical access controls are properly configured. This includes:

• Testing authentication mechanisms for weaknesses (default credentials, brute-force susceptibility)
• Validating role-based access control (RBAC) enforcement across application tiers
• Checking for privilege escalation paths in your infrastructure

CC6.6 — Security Measures Against External Threats

This criterion explicitly addresses external-facing threats. Your scanning program should demonstrate:

• Regular external vulnerability scans of all internet-facing assets
• Web application scanning covering the OWASP Top 10
• SSL/TLS configuration analysis for all public endpoints
• DNS and infrastructure configuration review

CC6.8 — Malware and Unauthorized Software

While primarily about endpoint protection, this criterion also covers:

• Software composition analysis (SCA) for known-vulnerable dependencies
• Container image scanning in CI/CD pipelines
• Detection of unauthorized or shadow IT services

CC8.1 — Change Management

Auditors want to see that vulnerability scans are integrated into your change management process:

• Pre-deployment scanning in staging environments
• Post-deployment validation scans after infrastructure changes
• Automated scanning in CI/CD pipelines that blocks deployments on critical findings

What Your Scans Must Cover

One of the most common audit findings is incomplete scanning scope. Your vulnerability scanning program must cover every component that processes, stores, or transmits customer data within the SOC 2 boundary.

Infrastructure Layer

Every server, container, load balancer, and network device within your trust boundary needs to be scanned. This includes:

• Cloud infrastructure — EC2 instances, Azure VMs, GCP Compute Engine, and their associated security groups, NACLs, and firewall rules
• Container orchestration — Kubernetes nodes, pod security policies, and container runtime configurations
• Databases — Configuration audits for RDS, Cloud SQL, DocumentDB, and self-managed databases
• Network devices — VPN gateways, load balancers, WAF configurations, and CDN settings

Application Layer

Your web applications and APIs are where most customer data interaction occurs. Comprehensive application scanning includes:

• DAST (Dynamic Application Security Testing) — crawling and testing running applications for runtime vulnerabilities
• API security testing — testing all REST, GraphQL, and gRPC endpoints for common API vulnerabilities
• Authentication testing — validating login flows, session management, OAuth implementations, and MFA enforcement
• Authorization testing — confirming RBAC enforcement and testing for horizontal/vertical privilege escalation

Third-Party Integrations

Your SOC 2 boundary extends to how you connect with third-party services. Auditors expect to see:

• Validation that API keys and credentials for third-party services are securely stored (not in source code)
• TLS verification on all outbound connections to third-party APIs
• Regular review of third-party access permissions and OAuth scopes

# Example: Automated SOC 2 scope validation with Find The Breach
$ curl -X POST https://api.findthebreach.com/v1/scans \
    -H "Authorization: Bearer $FTB_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "target": "app.yourcompany.com",
      "scan_type": "full",
      "compliance_mapping": "soc2",
      "notify": ["security@yourcompany.com"],
      "tags": ["soc2-quarterly", "production"]
    }'

# Results include SOC 2 criterion mapping for each finding:
# {
#   "finding": "TLS 1.0 enabled on port 443",
#   "severity": "high",
#   "soc2_criteria": ["CC6.1", "CC6.6"],
#   "remediation": "Disable TLS 1.0 and 1.1; enforce TLS 1.2+"
# }

Building Audit-Ready Evidence

Passing a SOC 2 Type II audit isn't just about running scans — it's about demonstrating a consistent, well-documented process that operated effectively throughout the entire audit period (typically 6-12 months). Here's what auditors want to see:

Documentation Requirements

1. Vulnerability Management Policy — A formal document defining scan frequency, scope, severity thresholds, remediation SLAs, and escalation procedures
2. Asset Inventory — A current, complete list of all systems within the SOC 2 boundary, with evidence that each is included in the scanning program
3. Scan Schedule — Documented cadence showing when scans run and confirmation they're actually executing on schedule
4. Remediation Tracking — Ticketing records showing each finding was assigned, prioritized, remediated within SLA, and verified via rescan
5. Exception Documentation — For any accepted risks or deferred remediation, documented justification with management sign-off

Evidence Artifacts

For each audit period, prepare these artifacts:

• Scan reports — Full reports from every scan executed during the audit period, including date, scope, tool used, and findings
• Trending data — Graphs showing vulnerability counts over time, mean time to remediation (MTTR), and SLA compliance rates
• Remediation evidence — Before/after scan comparisons showing findings were resolved
• False positive documentation — Records showing how false positives were identified, validated, and suppressed with justification

"The single biggest mistake companies make in SOC 2 audits is treating vulnerability scanning as a quarterly event. Auditors evaluate controls across the entire observation period — gaps in your scanning timeline are findings."

Scanning Frequency and Remediation SLAs

While SOC 2 doesn't mandate specific frequencies, auditor expectations have converged around industry best practices. Here are the thresholds that consistently pass audit scrutiny:

Remediation SLAs

Your vulnerability management policy must define remediation timelines based on severity. These SLAs should be realistic and consistently met — an SLA you routinely miss is worse than a longer SLA you always hit.

• Critical (CVSS 9.0+) — 24-72 hours. Immediate containment measures if remediation takes longer.
• High (CVSS 7.0-8.9) — 7-14 days. Prioritize over feature work.
• Medium (CVSS 4.0-6.9) — 30 days. Include in regular sprint planning.
• Low (CVSS 0.1-3.9) — 90 days. Address during routine maintenance cycles.

Track your SLA compliance rate as a key metric. A rate below 90% will raise auditor concerns. Most mature programs target 95%+ compliance on Critical and High findings.

Continuous Monitoring vs Point-in-Time Scans

SOC 2 Type II evaluates your controls over a period, not at a single point in time. This is the fundamental difference between Type I and Type II — and it's why continuous monitoring is so valuable for SOC 2 programs.

Why Point-in-Time Scans Fall Short

Running quarterly scans creates three-month gaps where new vulnerabilities can appear undetected. In 2025, the average time from CVE publication to active exploitation was 15 days. A quarterly scanning cadence means you could be exposed for up to 75 days before detection.

Building a Continuous Monitoring Program

A mature SOC 2 vulnerability management program layers multiple scanning approaches:

1. Continuous automated scanning — Weekly (or more frequent) infrastructure and application scans that run automatically
2. CI/CD pipeline scanning — SCA and container scanning on every build; DAST on every deployment to staging
3. Cloud Security Posture Management (CSPM) — Real-time monitoring of cloud configuration drift
4. Periodic deep assessments — Quarterly or semi-annual comprehensive penetration tests with manual testing

# Example: Scheduled weekly scan via cron + Find The Breach API
# Add to crontab: 0 2 * * 1 /opt/scripts/ftb-soc2-scan.sh

#!/bin/bash
# ftb-soc2-scan.sh — Weekly SOC 2 compliance scan

TARGETS=("app.yourcompany.com" "api.yourcompany.com" "admin.yourcompany.com")
SCAN_TAG="soc2-weekly-$(date +%Y-%m-%d)"

for target in "${TARGETS[@]}"; do
  curl -s -X POST https://api.findthebreach.com/v1/scans \
    -H "Authorization: Bearer $FTB_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"target\": \"$target\",
      \"scan_type\": \"full\",
      \"compliance_mapping\": \"soc2\",
      \"tags\": [\"$SCAN_TAG\"],
      \"notify\": [\"security@yourcompany.com\"]
    }"
done

Common SOC 2 Audit Findings Related to Scanning

Based on our work with hundreds of organizations preparing for SOC 2 audits, these are the vulnerability scanning deficiencies auditors flag most frequently:

1. Incomplete Asset Coverage

Your scan scope doesn't match your asset inventory. Shadow IT, forgotten staging environments, and newly provisioned cloud resources are common culprits. Fix: Integrate your asset discovery process with your scanning program. Use cloud provider APIs to automatically enumerate resources and confirm scanning coverage.

2. Missing Scan Windows

Gaps in your scanning timeline — weeks or months where no scans ran — are immediate red flags. Fix: Automate scan scheduling and set up alerting for missed scans. If a scan fails, have a documented procedure for re-running it within a defined window.

3. No Remediation Tracking

Scans were run, but there's no evidence that findings were triaged, assigned, or remediated. Fix: Integrate your scanning platform with your issue tracker (Jira, Linear, GitHub Issues). Every finding should create a trackable ticket with SLA metadata.

4. Undefined Risk Acceptance

Low-severity findings that were never addressed but lack formal risk acceptance documentation. Fix: Implement a formal risk acceptance process with management sign-off, business justification, and periodic review (at least quarterly) of all accepted risks.

5. No Evidence of Rescan

Findings were marked as "remediated" but there's no verification scan confirming the fix was effective. Fix: Require a passing rescan before closing any vulnerability ticket. Automate this where possible.

Getting Audit-Ready with Find The Breach

Find The Breach provides everything you need to build a SOC 2-compliant vulnerability scanning program. Our platform maps each finding to the relevant Trust Services Criteria, generates compliance-ready reports, and maintains a complete audit trail of every scan and remediation action.

SOC 2 Compliance Features

• Automated compliance mapping — Every finding is tagged with relevant SOC 2 criteria (CC6.1, CC6.6, CC7.1, etc.)
• Scheduled scanning — Configure weekly, bi-weekly, or custom scan cadences with automatic execution and alerting on failures
• Audit-ready reports — Generate PDF and HTML reports formatted for auditor review, with executive summaries and technical detail
• Remediation tracking — Built-in SLA tracking, ticket integration, and rescan verification workflows
• Historical data — Full scan history with trending dashboards showing vulnerability counts, MTTR, and SLA compliance over time