SOC 2 Pentest Requirements: What Your Auditor Actually Wants to See

The SOC 2 Pentest Question

You are a startup going through SOC 2 for the first time. Your auditor mentions penetration testing. Your compliance platform has a control for it. Your enterprise prospect's security questionnaire asks for the report. But when you read the actual SOC 2 standard, the word "penetration test" barely appears.

So does SOC 2 require a pentest? The short answer: not explicitly. The practical answer: yes, almost always. Here is what you need to know to get it right the first time.

What SOC 2 Actually Says

SOC 2 is built on the AICPA's Trust Services Criteria. The relevant criterion is CC7.1:

"To meet its objectives, 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."

The standard does not say "perform a penetration test." It says "detect vulnerabilities." Technically, a vulnerability scan could satisfy this requirement. In practice, auditors interpret this more strictly.

Here is why: SOC 2 auditors assess the design and operating effectiveness of your controls. A vulnerability scan shows you ran automated software. A penetration test shows that a qualified human attempted to break into your systems and documented what they found. The pentest is stronger evidence that your security controls are actually working.

What Auditors Actually Look For

We have worked with dozens of startups preparing for SOC 2 audits. Here is what auditors consistently want to see in the pentest report:

1. Scope Alignment

The pentest scope must match your SOC 2 trust service boundary. If your SOC 2 scope covers your SaaS application and its supporting infrastructure, the pentest needs to cover those same systems. A pentest that only tested your marketing website while your SaaS product was in scope will not satisfy the auditor.

What to include in scope:

• Production web application (all customer-facing features)
• API endpoints
• Authentication and authorization systems
• Customer-facing infrastructure (load balancers, CDN, DNS)
• Administrative interfaces
• Third-party integrations that process customer data
• Cloud infrastructure (AWS, GCP, Azure) within the trust boundary

Tip: Talk to your auditor before scoping the pentest. Ask them explicitly: "What do you need to see in the pentest report to satisfy CC7.1?" This avoids the expensive mistake of testing the wrong things. Sherlock Forensics offers free scoping consultations for SOC 2 engagements.

2. Recognized Methodology

The pentest report must reference a recognized testing methodology. Auditors want to see that testing followed a structured approach, not ad-hoc poking. Acceptable methodologies include:

• OWASP Testing Guide (for web application testing)
• PTES (Penetration Testing Execution Standard)
• NIST SP 800-115 (Technical Guide to Information Security Testing)
• OSSTMM (Open Source Security Testing Methodology Manual)

The report should name the methodology and describe how it was applied to your specific environment.

3. Qualified Tester

Auditors want to see that the pentest was performed by a qualified third party. "Qualified" typically means:

• An independent firm (not your own internal team)
• Testers with relevant certifications (OSCP, CISSP, CEH, GPEN or equivalent)
• A firm with documented experience in penetration testing (not a general IT consulting company that also offers pentests)

Some auditors will also check that the testing firm has professional liability insurance and follows responsible disclosure practices.

4. Findings with Severity Ratings

Every finding needs a severity rating, ideally using CVSS. The auditor needs to see that vulnerabilities are classified by risk level and that critical and high-severity findings have a documented remediation plan or have been fixed.

This is important: your auditor does not expect a clean report with zero findings. That would actually be suspicious. They expect to see findings at various severity levels with evidence that you have a process for prioritizing and remediating them.

5. Remediation Status

The auditor will ask: "What did you do about the findings?" Be prepared to show:

• Critical and high-severity findings have been remediated (or have a documented remediation plan with a timeline)
• Medium-severity findings have been triaged and prioritized
• You have a process for tracking remediation progress
• Optionally, a retest confirming that critical fixes were implemented correctly

This is why timing matters. If you run the pentest the week before your audit, you will not have time to remediate findings, and your auditor will flag the open vulnerabilities as control weaknesses.

6. Testing Date Within the Audit Period

For SOC 2 Type II, the pentest must have been conducted within your audit observation period (typically 12 months). Most auditors accept a pentest conducted up to 12 months before the audit report date. Some are stricter and want the test within the last 6 months.

Timing Your SOC 2 Pentest

Timing is the single biggest mistake startups make with SOC 2 pentests. Here is the recommended timeline:

3-4 months before audit window closes: Schedule and begin the penetration test. A standard engagement at Sherlock Forensics takes 8-12 business days.

2-3 months before audit window closes: Receive the report. Begin remediating critical and high-severity findings.

1-2 months before audit window closes: Complete remediation of critical findings. Schedule a retest if desired. Document remediation status for all findings.

Audit window closes: Provide the pentest report, remediation evidence and retest results (if applicable) to your auditor.

This timeline gives you enough room to find issues, fix them and demonstrate that your remediation process works. Running the pentest too close to the audit deadline means you either rush remediation or present a report full of open findings.

Type I vs. Type II: Does It Matter?

SOC 2 Type I evaluates the design of your controls at a point in time. A recent pentest report strengthens your Type I by showing that your vulnerability management controls are designed effectively.

SOC 2 Type II evaluates the operating effectiveness of your controls over a period (typically 6-12 months). The pentest needs to fall within this observation period. For Type II, the auditor may also want to see evidence of regular vulnerability scanning between annual pentests to demonstrate ongoing monitoring.

For most startups, the first SOC 2 is a Type I (to get the report quickly for sales), followed by a Type II 6-12 months later. Plan for a pentest before each.

How to Scope the Engagement

Here is a practical scoping checklist for a SOC 2 pentest:

• List your SOC 2 in-scope systems. These are the systems described in your system description. Every system that stores, processes or transmits customer data within the trust boundary should be in pentest scope.
• Include external and internal testing. At minimum, your external attack surface must be tested. If your SOC 2 scope includes internal infrastructure (cloud environments, internal networks), discuss internal testing with your vendor.
• Cover authentication and authorization. SOC 2 cares about access controls. The pentest should explicitly test user authentication mechanisms, role-based access controls and privilege escalation.
• Test your APIs. If your product is API-driven (most SaaS products are), the API must be included in testing scope.
• Confirm with your auditor. Before signing the pentest engagement, email your auditor the proposed scope and ask for confirmation. A 5-minute email saves thousands of dollars in retesting.

Common Mistakes

Testing too late. Running the pentest two weeks before the audit and having no time to remediate findings.

Wrong scope. Testing your marketing site instead of your production application. Or testing only the web interface while the API (where most vulnerabilities live) is excluded.

Using a vulnerability scan instead. Some vendors sell automated scans as "penetration tests." Your auditor can tell the difference. A Nessus report is not a pentest report. Read our guide on pentest vs. vulnerability scan for the full distinction.

Not remediating. Receiving the report and filing it away without fixing anything. Your auditor will ask about remediation status. "We have not started" is a control weakness.

Not documenting remediation. Fixing everything but having no documentation to show the auditor. Track remediation in your project management tool and maintain evidence (pull requests, deployment logs, retest results) for each fixed finding.

What It Costs

A SOC 2-scoped penetration test typically costs $5,000 to $15,000 CAD depending on the number of applications, API endpoints and infrastructure components in scope. At Sherlock Forensics:

• Single SaaS application + API: $5,000-$8,000 CAD
• Multiple applications or complex infrastructure: $8,000-$15,000 CAD
• Comprehensive assessment with internal testing: $12,000-$25,000 CAD

Every engagement includes a report that meets SOC 2 auditor expectations, a debrief call and optional retest pricing for post-remediation validation. See our full 2026 pentest pricing breakdown.

Getting Started

If you are preparing for SOC 2 and need a penetration test, start by reading what to expect during a penetration test, then order online or contact us for a free scoping consultation. We align the engagement to your SOC 2 trust service boundary so your auditor gets exactly what they need.

Frequently Asked Questions

Does SOC 2 require a penetration test?

Not explicitly, but Common Criteria CC7.1 requires vulnerability detection on system boundaries. Nearly every SOC 2 Type II auditor expects a recent penetration test report as evidence that this control is operating effectively. In practice, consider it a requirement. Sherlock Forensics SOC 2-ready pentests start at $5,000 CAD.

How do I scope a pentest for SOC 2?

Scope the pentest to match your SOC 2 trust service boundary. Include your production application, API endpoints, authentication systems, customer-facing infrastructure and any third-party integrations that handle customer data. Confirm the scope with your auditor before the engagement begins. Sherlock Forensics offers free scoping consultations for SOC 2 engagements.

How often do I need a pentest for SOC 2?

Annual penetration testing is the industry standard for SOC 2. The test should fall within your audit observation period. Schedule the pentest 2-3 months before your audit window closes to allow time for remediation. Some auditors accept tests up to 12 months old, while others expect them within the last 6 months.