SOC 2 Compliance: What Security Scanning Do You Actually Need?

If you're a SaaS company, you've probably received this email from a prospective enterprise customer: "Can you share your SOC 2 report?"

83% of enterprise buyers now require SOC 2 certification from their SaaS vendors before signing contracts. That number has been climbing steadily, and it's the single most common reason mid-market companies start taking security scanning seriously.

But SOC 2 requirements around vulnerability scanning are surprisingly vague. This creates confusion about what you actually need — and vendors are happy to sell you more than necessary. Here's what the standard actually requires and how to build a scanning program that satisfies auditors without over-engineering it.

What SOC 2 Says About Vulnerability Scanning

SOC 2 is built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most companies pursue Security + Availability at minimum.

The relevant criteria for vulnerability scanning fall primarily under CC7 (System Operations) and CC8 (Change Management):

CC7.1 — The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities.

CC7.2 — The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives.

CC8.1 — The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

Notice what's not there: no specific requirement for a particular tool, scanning frequency, or vulnerability classification system. SOC 2 is principle-based, not prescriptive.

What Auditors Actually Look For

In practice, auditors evaluating your vulnerability scanning program want to see four things:

1. Regular, Documented Scanning

Auditors want evidence that you scan your systems on a regular schedule — not just when you remember to. What "regular" means varies:

• Minimum viable: Monthly vulnerability scans of production systems
• Good practice: Weekly automated scans with on-demand scans after significant changes
• Best practice: Continuous scanning integrated into CI/CD, plus periodic comprehensive assessments

The key word is documented. Your scanning tool needs to produce reports with timestamps showing what was scanned and when.

2. Remediation Tracking

It's not enough to find vulnerabilities. Auditors want to see that you track them through to resolution:

• When was it found?
• What's the severity?
• Who owns the remediation?
• What's the timeline for resolution?
• When was it verified as fixed?

This is where many teams fail their first audit — they run scans but don't have a systematic process for tracking findings through resolution.

3. Coverage of Critical Systems

Auditors will ask what systems are in scope and verify that your scanning covers them. For a typical SaaS company, this means:

• Web applications (your product)
• APIs (public and internal)
• Infrastructure (cloud configuration, network)
• Dependencies (third-party libraries, SCA)

You don't need a single tool that covers everything. But you need to demonstrate coverage across the categories and explain how.

4. Appropriate Response to Findings

Auditors look at your severity classification and response timelines:

These aren't SOC 2 requirements — they're industry norms that auditors reference. Your timelines should be documented in a vulnerability management policy.

Building a Scanning Program That Passes Audit

Here's a practical approach for a mid-market SaaS company going through SOC 2 for the first time:

Layer 1: Automated Web Application Scanning (DAST)

This is your primary defense for finding vulnerabilities in your running web application. Run it:

• Weekly against production (or staging that mirrors production)
• On every significant deployment (new features, major changes)
• Quarterly with comprehensive/deep scan settings

What the scan should cover:

• OWASP Top 10 vulnerabilities (SQL injection, XSS, CSRF, etc.)
• Server misconfigurations
• TLS/SSL configuration
• Known CVEs in detected technologies
• Authentication and session management issues

Layer 2: Dependency Scanning (SCA)

Separate from DAST — this checks your code dependencies for known vulnerable versions:

• Run on every build in CI/CD
• Tools: Dependabot, Snyk, Trivy, or language-specific alternatives
• Auditors want to see that you know what third-party code you're running and that you update vulnerable packages

Layer 3: Infrastructure Scanning

For cloud-hosted applications:

• Cloud configuration scanning (AWS Config, ScoutSuite, Prowler)
• Container image scanning if using Docker/Kubernetes
• Network configuration review

Layer 4: Periodic Penetration Testing

Some auditors expect annual third-party penetration testing in addition to automated scanning. This is typically an external engagement — hire a firm to do a thorough manual assessment once a year.

Automated DAST doesn't replace this. Manual pentesters find business logic issues, complex attack chains, and context-dependent vulnerabilities that automated tools miss. But automated DAST covers the continuous monitoring between annual pentests.

Common Mistakes

Mistake 1: Running scans but not tracking results

Scanning without a remediation workflow is compliance theater. Set up a process: findings → ticket → assignee → fix → verify → close.

Mistake 2: Scanning only before the audit

Auditors review evidence across the entire audit period (typically 6-12 months). A burst of scanning activity right before the audit looks suspicious. Start your regular scanning schedule at least 6 months before your audit window.

Mistake 3: Using a tool that only produces "pass/fail" reports

Auditors want detail. "Scan passed" isn't sufficient. They want to see: what was tested, what was found, what severity, and how it was resolved. Choose tools that produce detailed, timestamped reports with specific findings.

Mistake 4: Ignoring the "evidence" part

Your scanning tool should produce reports you can hand to an auditor. This means:

• PDF or HTML reports with timestamps
• Scan configuration details (what was tested, how)
• Finding details with severity, description, and evidence
• Historical records (showing consistent scanning over time)

Mistake 5: Over-engineering for the first audit

SOC 2 Type I (point-in-time) is simpler than Type II (period of time). For your first audit, focus on demonstrating that controls exist and are operating. You can mature your program over subsequent audit cycles.

What This Means for Tool Selection

When choosing a DAST tool with SOC 2 compliance in mind, prioritize:

1. Automated scheduling: Can it run on a regular schedule without manual intervention?
2. Detailed reporting: Does it produce reports with enough detail for auditors?
3. Severity classification: Does it categorize findings by severity (Critical/High/Medium/Low)?
4. Scan history: Can you demonstrate a pattern of regular scanning over months?
5. Remediation tracking: Does it integrate with your issue tracker, or at least export findings in a structured format?
6. Coverage documentation: Can you explain to an auditor what the scan covers and what it doesn't?

The last point is underrated. Auditors appreciate transparency about coverage gaps more than inflated coverage claims. If your DAST tool covers web application vulnerabilities but not infrastructure configuration, say so — and explain what covers the infrastructure layer.

The Bottom Line

SOC 2 compliance doesn't require a $50,000/year enterprise scanning platform. It requires:

• Regular, automated vulnerability scanning of your applications
• Documented evidence of what was scanned and when
• A remediation process that tracks findings through resolution
• Severity-based response timelines
• Honest coverage documentation

A mid-market DAST tool running weekly scans with detailed reporting, combined with dependency scanning in CI/CD and annual penetration testing, satisfies the vast majority of SOC 2 auditors.

The goal isn't to scan the most. It's to scan consistently, track everything, and fix what you find.