Is a penetration test required for SOC 2?

SOC 2 does not explicitly mandate a penetration test, but most auditors expect one as evidence for CC7.1 (threat detection) and CC7.2 (monitoring). If you show up without a pentest report, your auditor will likely flag it as a gap.

Can I use an automated vulnerability scan instead of a pentest for SOC 2?

Most auditors will not accept a vulnerability scan alone. Scanners miss business logic flaws, access control issues, and chained exploits. Auditors want evidence of manual testing by a qualified professional, not a tool-generated PDF.

How recent does the pentest report need to be for SOC 2?

Your pentest report should be from within the audit observation period, typically the last 12 months. For Type 2 audits, the pentest should fall within the observation window. Schedule your pentest at least 8 to 10 weeks before the audit so you have time to remediate findings.

What should a SOC 2 pentest report include?

Your auditor expects: scope definition, testing methodology reference (OWASP WSTG, PTES), tester qualifications, findings with severity ratings, remediation status, and evidence that critical and high findings were fixed. Compliance control mapping to SOC 2 Trust Service Criteria is a plus.

Penetration Testing for SOC 2 Audit: What Your Auditor Actually Expects

Your SOC 2 Type 2 observation window ends in 10 weeks. Your auditor sends a preliminary evidence request. Line 14: “Most recent penetration test report.”

You do not have one. Or you have a vulnerability scan from 8 months ago that your DevOps engineer ran. You are not sure if that counts.

It probably does not. Here is what your auditor actually expects, how to get a pentest that satisfies the requirement the first time, and the mistakes that cause startups to scramble at audit time.

Does SOC 2 Require a Penetration Test?

Technically, no. The SOC 2 Trust Service Criteria do not contain a line that says “conduct a penetration test.” But in practice, most auditors treat it as expected evidence for two criteria:

CC7.1: The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities and susceptibilities to newly discovered 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.

A penetration test is the most direct way to demonstrate that you are proactively identifying vulnerabilities in your systems. Without one, your auditor will ask how you know your controls work. “We do code reviews” is not a sufficient answer.

Some auditors are flexible about this. Most are not. If you are going through your first SOC 2 audit, assume you need a pentest report.

What Auditors Look For in the Report

Your auditor is not reading every finding in detail. They are checking whether the report demonstrates that security testing was done properly and that you acted on the results. Here is what they evaluate:

Scope

The pentest must cover the systems included in your SOC 2 scope. If your SOC 2 covers your SaaS platform and customer-facing API, the pentest needs to test those specifically, not your marketing website or an internal tool that is out of scope.

Common mistake: getting a pentest on one application when your SOC 2 scope includes three. Your auditor will flag the gap.

Methodology

The report should reference a recognized testing framework. OWASP WSTG v5.0 for web applications and PTES for broader engagements are the standards auditors expect. A report that says “we tested the application for vulnerabilities” without explaining the methodology looks like a scanner run.

Tester Qualifications

Auditors want to see that the testing was done by someone qualified. This means certifications (OSCP, CREST, CompTIA PenTest+) and evidence that the tester has relevant experience. A report from an unknown company with no credentials listed will get questioned.

Findings and Severity

Every finding should have a clear severity rating (Critical, High, Medium, Low). Auditors care most about Critical and High findings. They want to see:

What was found
What the business impact is
What the severity rating is and how it was determined

They do not need to understand every technical detail. They need to see that vulnerabilities were identified, categorized, and communicated clearly.

Remediation Evidence

This is where most startups fail. Finding vulnerabilities is half the job. Your auditor wants to see that you fixed them.

For Critical and High findings, you need evidence of remediation: a retest confirming the fix, a code commit addressing the issue, or a documented risk acceptance with justification.

If your pentest report has 3 Critical findings and no evidence that any were addressed, your auditor will flag it as a control deficiency. That is worse than not having a pentest at all.

Control Mapping

This is not required but significantly reduces back-and-forth with your auditor. If the pentest report maps findings to SOC 2 Trust Service Criteria (CC6.1 for access controls, CC6.6 for system boundaries, CC7.1 for threat detection), your auditor can cross-reference directly instead of interpreting technical findings.

Vulnerability Scan vs Penetration Test: What Auditors Accept

	Vulnerability Scan	Penetration Test
What it is	Automated tool checks for known issues	Human-led assessment simulating real attacks
What it finds	Outdated libraries, missing headers, weak configs	Business logic flaws, access control bypasses, chained exploits
Accepted by most SOC 2 auditors	As supplementary evidence only	Yes, as primary evidence
Tester required	No, any engineer can run it	Yes, certified professional expected
Report quality	Tool-generated, generic remediation	Custom findings with specific reproduction steps

Some auditors accept vulnerability scans for Type 1 (point-in-time). Almost none accept them as the sole evidence for Type 2 (observation period). If you are doing Type 2, get a manual pentest.

For a deeper comparison, read manual penetration testing vs automated scanning.

Timing: When to Schedule the Pentest

The most common mistake is scheduling the pentest too late. Here is the timeline that works:

8-10 weeks before your audit window closes: Schedule and complete the pentest. This gives you time to receive the report, remediate findings, and get a retest done before the auditor reviews evidence.

4-6 weeks before audit: Remediate Critical and High findings. Get retest confirmation.

2 weeks before audit: Compile evidence package: original report, remediation evidence, retest results. Hand it to your auditor as a single package.

What happens if you schedule it 2 weeks before the audit: You get the report, find 4 High-severity findings, and have no time to fix them before the auditor reviews. Now you have documented evidence of unfixed vulnerabilities sitting in your SOC 2 audit file. Your auditor flags it as a control deficiency.

Plan ahead. A pentest is not a checkbox you tick at the last minute.

Scope It Right the First Time

Before engaging a pentest company, align the scope with your SOC 2 boundary:

List every system in your SOC 2 scope. Your SaaS platform, APIs, customer-facing portals, admin panels, mobile apps if applicable.
Identify which systems handle customer data. These are the highest priority for testing.
Check with your auditor. Ask them what they expect covered before you scope the pentest, not after. A 5-minute email saves you from discovering a scope gap during the audit.
Include your cloud infrastructure if it is in scope. IAM misconfigurations and storage bucket permissions are common findings that auditors care about.

If your SOC 2 scope covers a web application and an API, you need both tested. A single-scope pentest covering only the web application leaves a gap your auditor will find.

What a SOC 2-Ready Pentest Report Looks Like

A report your auditor will accept without follow-up questions includes:

Scope definition: What was tested, what was excluded, and why
Methodology: OWASP WSTG, PTES, or equivalent framework referenced
Tester credentials: Names, certifications, and company
Executive summary: High-level findings for leadership and auditors
Detailed findings: Each finding with severity, reproduction steps, business impact, and recommended fix
SOC 2 control mapping: Findings mapped to relevant Trust Service Criteria
Remediation status: Which findings are fixed, which are in progress, which are accepted risks
Retest results: Confirmation that remediated findings are verified closed

See a sample report that includes this format.

How We Handle SOC 2 Pentests

Our Growth Pentest plan (INR 1,79,999) is built for startups going through SOC 2 or ISO 27001 audits. It includes:

2 scopes (web app + API, or web app + mobile) tested over 10 calendar days
SOC 2 + ISO 27001 compliance control mapping in the report
Executive summary formatted for auditor review
Free retest to verify remediation before your audit
Brand Protection Snapshot (typosquatting, leaked credentials, fake apps)

If you only need one scope tested, the Startup Pentest plan (INR 74,999) covers a single application in 7 days with a detailed report and free retest. Note: SOC 2 control mapping is included with the Growth plan only.

Both plans are founder-led. Rathnakara (OSCP, CompTIA PenTest+, M.Sc Cyber Security) leads all testing. Reports are delivered in a format your auditor can use directly as evidence.

Timing tip: If your SOC 2 audit is in 3 months, now is the right time to schedule the pentest.

View pricing | See a sample report | Read our SOC 2 readiness guide