SOC 2 Penetration Testing Requirements: What Auditors Actually Expect
If you are preparing for a SOC 2 audit, someone has probably told you that you "need a pentest." That is mostly true, but the details matter, because the wrong kind of test wastes money and the right kind makes the audit much smoother.
This guide explains what SOC 2 actually says about penetration testing, what auditors look for in the report, and how startups can meet the expectation without a six-week consulting engagement.
Does SOC 2 require a penetration test?
Strictly speaking, no. The AICPA Trust Services Criteria do not contain a line that says "perform an annual penetration test." SOC 2 is principles-based: you define controls, and the auditor checks that they are designed well and operating effectively.
In practice, though, penetration testing is the standard way to satisfy several criteria, especially:
- CC4.1 - the organization performs ongoing and separate evaluations to check that controls are present and functioning.
- CC7.1 - the organization uses detection and monitoring procedures to identify vulnerabilities and configuration changes that introduce new weaknesses.
- CC3.2 and CC3.4 - risk assessment, including identifying threats to the system and changes that could affect it.
Most auditors expect to see a recent, independent security test of your production application. If you do not have one, you will need a strong alternative explanation, and many auditors will note it as an exception or a weakness. Enterprise customers reading your SOC 2 report will also look for it.
What auditors look for in a pentest report
A pentest report used as SOC 2 evidence should answer five questions clearly.
- What was tested? The scope: domains, applications, APIs and cloud environments, ideally matching the system description in your SOC 2 report.
- When was it tested? The test date should fall within, or shortly before, your audit period. For a Type 2 audit, a test from more than twelve months ago is usually stale.
- How was it tested? The methodology, such as OWASP Top 10, OWASP API Security Top 10, authenticated vs unauthenticated testing.
- What was found? Each finding with severity, evidence and impact.
- What did you do about it? Remediation status, and ideally a retest showing critical and high issues were fixed.
The fifth point is the one teams most often miss. Auditors care less that you had vulnerabilities and more that you have a process to find and fix them. A report with ten findings and a clean retest is better evidence than a report nobody acted on.
Type 1 vs Type 2: does timing change?
For a Type 1 report, the auditor evaluates control design at a point in time. A pentest completed before the audit date shows that your vulnerability management control exists.
For a Type 2 report, the auditor evaluates whether controls operated over a period, usually three to twelve months. Here it helps to show testing happened during the period and that findings were tracked to closure. Continuous or quarterly testing makes this much easier than a single annual test.
Common mistakes that cause audit friction
- Scanning only the marketing site. Your SOC 2 system is usually the product: the app, its APIs and the cloud it runs on. Test that.
- Unauthenticated testing only. Most serious bugs in SaaS products, such as broken access control and IDOR, are only visible after login. Provide test accounts for at least two roles.
- No remediation evidence. Keep tickets or a retest report showing fixes.
- Scope that does not match the system description. If your report describes three services and the pentest covered one, expect questions.
- Treating the test as a one-off. Code changes every week. Auditors increasingly ask how you catch new vulnerabilities between annual tests.
How much testing is enough?
For an early-stage SaaS company, a reasonable baseline that satisfies most auditors looks like this:
| Area | Minimum | Better |
|---|---|---|
| Web application | Annual authenticated test | Continuous testing on every release |
| APIs | Included in the app test | Dedicated API testing with OWASP API Top 10 |
| Cloud | Configuration review | Automated cloud misconfiguration checks |
| External attack surface | Port and service scan | Continuous attack surface monitoring |
| Remediation | Tickets for critical and high | Retest report showing fixes verified |
Getting a SOC 2 pentest report quickly
Traditional pentests require scoping calls, statements of work and a scheduling queue, which can take weeks before testing even starts. If your audit window is close, that delay hurts.
An AI-driven approach changes the timeline. SecurityInfinity runs autonomous recon, web, API, network and secrets agents in parallel against your application, verifies each finding, and produces a report with evidence and an exact fix for every issue. The first report arrives in about ten minutes, and you can rerun the test after fixing to produce clean retest evidence. You can get a pentest report or start free with 100 credits.
Frequently asked questions
Is a vulnerability scan enough for SOC 2?
Sometimes, for a Type 1 report with a lenient auditor, but most auditors and enterprise customers expect a penetration test that goes beyond automated scanning, including authenticated testing and verified exploitation of findings.
How often should we pentest for SOC 2?
At least once every twelve months, and after major changes to the application or infrastructure. Many companies now test continuously or quarterly, which makes Type 2 evidence much easier to produce.
Does the pentest need to be done by a third party?
Auditors generally expect independence, meaning the testing is not performed by the same engineers who built the system. An external provider or platform satisfies this.
What severity of findings must be fixed before the audit?
There is no fixed rule, but you should be able to show that critical and high findings were remediated or have a documented risk acceptance and remediation plan.