SOC 2 is the compliance standard that every B2B SaaS company eventually faces. Your enterprise customers require it, your sales team needs it, and your engineering team dreads it. But SOC 2 security testing requirements are more straightforward than most teams realize — if you understand what auditors actually evaluate.
What SOC 2 Actually Requires
SOC 2 is organized around five Trust Service Criteria. For security testing, the relevant criteria fall under Common Criteria (CC) — specifically around risk assessment and monitoring:
SOC 2 Trust Service Criteria
Security (Common Criteria)
The foundation. Required for every SOC 2 report. Covers access control, system operations, change management, and risk mitigation. This is where security testing requirements live.
Availability
System uptime and disaster recovery. Relevant if your SLA promises specific uptime guarantees. Requires monitoring and incident response testing.
Processing Integrity
Data processing is complete, valid, accurate, and timely. Relevant for financial or data-critical systems.
Confidentiality
Data classified as confidential is protected. Requires encryption, access controls, and data handling procedures.
Privacy
Personal information is collected, used, retained, and disposed of properly. Overlaps with GDPR/CCPA requirements.
The Security Testing Requirements
SOC 2 doesn't prescribe specific tools or testing frequencies. Instead, it requires you to demonstrate that you have a risk-based security testing program. Here's what auditors evaluate:
Risk Assessment
You've identified your assets, threats, and vulnerabilities. You have a documented process for evaluating and prioritizing risks. This assessment drives your testing program.
Vulnerability Management
You regularly scan for vulnerabilities, track them, and remediate within defined SLAs. You can show evidence of scans, findings, and remediation timelines.
Penetration Testing
You conduct periodic penetration testing (typically annual) by qualified testers. You have reports showing findings, severity, and remediation status.
Monitoring and Response
You monitor for security events, have incident response procedures, and can demonstrate they work. Log retention, alerting, and response playbooks.
ℹ️Evidence Over Process
SOC 2 auditors care about evidence. They want to see scan reports, pentest findings, remediation tickets, and timeline proof. Having a beautiful security policy document means nothing if you can't show it's actually followed.
What Auditors Actually Look For
Will Raise Findings
- •No vulnerability scanning program
- •Pentest older than 12 months
- •Critical vulnerabilities open beyond SLA
- •No evidence of remediation tracking
Will Pass Cleanly
- •Regular automated scanning with documented results
- •Annual pentest with qualified tester and remediation evidence
- •Defined SLAs for each severity level with tracking
- •Ticketing system showing finding-to-fix workflow
Vulnerability Scanning
Auditors expect regular automated vulnerability scanning — typically weekly or monthly for external assets, and at least quarterly for internal systems:
Scanning Requirements
External scanning
All internet-facing assets scanned regularly. Web applications, APIs, cloud infrastructure. Our Security Auditor covers this — automated, continuous scanning with detailed reports that satisfy auditor evidence requirements.
Internal scanning
Network and system-level vulnerability assessment. Less frequent but still required. Can be combined with cloud security posture management (CSPM) tools.
Dependency scanning
Third-party libraries and components checked for known vulnerabilities. Integrates into CI/CD pipeline. As we covered in CI/CD Pipeline Security, this should be automated in your build process.
Penetration Testing
Most SOC 2 auditors expect annual penetration testing at minimum. Here's what makes a pentest report SOC 2-ready:
Scope Documentation
Clear definition of what was tested — applications, APIs, infrastructure, networks. Auditors want to see that the scope covers your critical assets.
Methodology
The tester followed a recognized methodology (OWASP, PTES, NIST). Not just "we ran a scanner" — evidence of manual testing and business logic assessment.
Findings with Severity
Each finding classified by severity with clear description, evidence, and remediation guidance. This maps directly to your vulnerability management SLAs.
Remediation Evidence
For each finding, evidence that it was remediated or accepted with documented risk acceptance. Auditors want to see the ticket, the fix, and the retest.
Our Web Security Auditor generates reports with methodology documentation, severity classification, and remediation guidance that map directly to SOC 2 evidence requirements. For deeper testing, our expert review provides the manual penetration testing that auditors expect for high-risk applications.
Building a SOC 2-Ready Security Program
The Practical Security Stack for SOC 2
Continuous scanning (automated)
Automated vulnerability scanning on a regular cadence. Catches known vulnerabilities, misconfigurations, and regression issues. This is your baseline — the minimum viable security testing.
Annual penetration testing
Deep manual testing by qualified security professionals. Covers business logic, authentication flows, authorization bypasses, and complex attack chains that scanners miss.
Vulnerability management process
Defined SLAs by severity (Critical: 24hrs, High: 7 days, Medium: 30 days, Low: 90 days). Tracking in a ticketing system. Regular reporting to stakeholders.
Incident response testing
Tabletop exercises or simulated incidents at least annually. Document the exercise, findings, and improvements. Auditors love seeing IR test reports.
💡Start Early
Don't wait until 3 months before your SOC 2 audit to start security testing. Auditors evaluate a period of time (typically 6-12 months for Type II). You need evidence of consistent testing throughout that period, not a last-minute sprint.
Common SOC 2 Mistakes
Confusing compliance with security
Passing SOC 2 means you have a documented, followed security program. It doesn't mean you're secure. Many SOC 2 compliant companies have been breached. Use compliance as a floor, not a ceiling.
Over-scoping the audit
Including every system in your SOC 2 scope increases cost and complexity. Scope to the systems that handle customer data. If a system is out of scope, document why.
Manual evidence collection
Manually collecting evidence for each control is unsustainable. Automate evidence collection where possible — automated scan reports, CI/CD logs, ticketing system exports.
Ignoring the observation period
SOC 2 Type II covers a time period. If you implement controls in month 10 of a 12-month period, auditors will note the gap. Start early and maintain consistently.
Web3 Companies and SOC 2
If you're a Web3 company handling customer funds or data, SOC 2 increasingly applies to you — especially for:
- Centralized exchanges and custodians
- DeFi protocols with off-chain components (APIs, frontends, admin dashboards)
- NFT platforms handling user data and payment information
- Infrastructure providers (RPC nodes, indexers, oracles)
For Web3 companies, security testing should cover both traditional web application security (covered by our Web Security Auditor) and smart contract security (covered by our Smart Contract Auditor). As we discussed in The State of Web3 Security in 2026, the convergence of Web2 and Web3 security requirements is accelerating.
Preparing for SOC 2? Our Web Security Auditor provides the automated scanning evidence auditors require, and our expert review delivers the annual penetration testing report. Start your security testing program.