SOC 2 Penetration Testing Requirements: The Auditor Checklist

The short answer: SOC 2 penetration testing requirements are not spelled out word-for-word in the Trust Services Criteria, but auditors universally interpret CC4.1, CC7.1, and CC7.2 as requiring an annual independent penetration test of every system in your SOC 2 boundary, with documented scope, methodology, severity-ranked findings, remediation evidence, retesting, control mapping, and management acknowledgment. Miss any of these nine artifacts and you get a finding, even if the test itself was technically excellent.

This guide is the working auditor checklist we use on every SOC 2 engagement. It covers what SOC 2 actually requires of a pentest, the nine items auditors verify, the five gaps that most often cause Type 2 findings, Type 1 vs Type 2 expectations, what a passing report deliverable looks like, and how the hybrid AI plus human model compares to DIY internal testing and platform-only scanning. Use it before you scope your next pentest, or hand it to your auditor as a pre-fieldwork prep document.

What SOC 2 actually requires of a penetration test

SOC 2 itself does not mandate a penetration test in plain text. The framework is principles-based, organized around five Trust Services Categories (Security, Availability, Processing Integrity, Confidentiality, Privacy) and roughly 200 Points of Focus underneath the Common Criteria. Three of those criteria, in practice, force the pentest into existence:

• CC4.1 (Monitoring of Controls). The entity selects, develops, and performs ongoing and separate evaluations to ascertain whether the components of internal control are present and functioning. Auditors read "separate evaluations" as independent testing. A pentest performed by an outside party satisfies this.
• CC7.1 (Detection of Configuration Changes). The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities. A pentest is the canonical procedure auditors accept here.
• CC7.2 (Anomaly Detection). The entity monitors system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors. Pentest findings, severity ratings, and remediation tracking are direct evidence of CC7.2 in operation.

Across every SOC 2 Type 2 engagement we have seen in the last three years, the auditor required at least one annual penetration test plus quarterly or monthly automated vulnerability scanning as evidence for these three criteria. The pentest is not optional. The only question is whether the report you produce will pass on first review.

Why SOC 2 requires a penetration test

The SOC 2 framework does not explicitly mandate a pentest in the Trust Services Criteria text. But auditors universally interpret CC4.1, CC7.1, and CC7.2 as requiring periodic independent testing of the system. In practice, every SOC 2 Type 2 engagement we have seen in the last three years required at least one annual penetration test as evidence.

The 9-point SOC 2 pentest auditor checklist

1. Scope matches the system description

The pentest scope must cover every system listed in your SOC 2 system description. If the description lists three services and the pentest covers two, expect a finding. Auditors cross-reference the asset list against the system boundary diagram. Common gap: forgetting to include the customer-facing admin portal or internal management API. Fix it by asking your tester to read the SOC 2 system description before kickoff and produce an asset matrix that maps one-to-one to it.

2. Recognized methodology

OWASP Top 10, OWASP ASVS, PTES, OSSTMM, or NIST SP 800-115. The report must state which one was used. "Ad hoc testing" or "proprietary methodology" without a published reference triggers an inquiry. The strongest reports state the methodology by name on the cover page and list every test case category from the methodology that was executed.

3. Tester independence and qualifications

The tester cannot be on the engineering or operations team that built or runs the system. Auditors look for industry certifications (OSCP, OSWE, OSEP, CREST CRT, GPEN, GWAPT) and engagement letters showing the testing entity is independent. Internal red teams can qualify if they report into a different chain of command from the engineering org and the independence is documented in the engagement letter.

4. Findings ranked by severity

CVSS 3.1 or a documented internal scoring system. Every finding must include affected asset, evidence (screenshot, request/response, or video), and recommended remediation. "Possible XSS" with no proof of concept is not a finding. Auditors specifically look at the Critical and High findings: how many, how old, and what remediation status each one is in.

5. Remediation evidence

This is where most reports fail. The auditor needs to see that critical and high findings were either fixed, accepted (with management sign-off), or have a documented remediation plan with a target date inside the audit window. A pentest report with 12 critical findings and no remediation will fail CC7.2. The remediation tracker should sit on the same page as the original finding so the auditor does not have to ask for a second document.

6. Retesting

After remediation, a retest must validate the fix. The retest can be conducted by the same tester. Auditors accept a retest summary appended to the original report or a separate retest letter dated after remediation. Without a retest, the auditor cannot conclude that the control operated effectively, which is the bar for Type 2.

7. Control mapping

Each finding should map to the affected Trust Services Criterion. This is not strictly required by the framework, but it cuts audit fieldwork time roughly in half. Modern pentest vendors include this mapping by default. See our companion guide on compliance penetration testing for how mapping works across SOC 2, ISO 27001, PCI DSS, and HIPAA in a single engagement.

8. Timing within the audit window

The test must have been performed during the SOC 2 audit period (typically 6 or 12 months). A test conducted six months before the audit window opens does not count, even if no changes were made. If your Type 2 window starts January 1 and ends December 31, the pentest must have been completed in that window. The fastest fix when a test falls outside the window is to schedule a fresh test inside the window and treat the older one as historical context.

9. Management acknowledgment

Management must acknowledge the report, accept residual risk on any unremediated findings, and document the decision. This is usually a one-page memo signed by the CISO or CTO. Without it, auditors cannot demonstrate that the control environment was reviewed. The memo should reference the report by name, summarize the residual risks, and state the acceptance rationale.

The five gaps that cause SOC 2 audit findings

1. Scope creep after the test. A new microservice ships after the pentest and was not retested. Auditor flags it. Mitigate this with a delta-scope addendum that covers anything added after the original engagement.
2. Unfixed criticals with no risk acceptance. Findings linger in the backlog without management sign-off. Either remediate before the audit kickoff or produce a signed risk acceptance memo for each one.
3. Stale report. Report is over 12 months old at audit kickoff. SOC 2 expects annual testing; anything older than 12 months requires a fresh engagement.
4. Insufficient evidence. The report lists findings but not the request/response pairs or screenshots auditors need to verify exploitability. Insist on raw evidence in an appendix.
5. Tester independence not documented. Engagement letter missing, or tester is a contractor on the engineering team. Save a signed engagement letter alongside the report; auditors will ask for it.

SOC 2 Type 1 vs Type 2 penetration test requirements

SOC 2 Type 1 requires that a pentest has been performed and that the control exists at a point in time. Practically, this means one pentest report dated within the past 12 months, with scope matching the system description and a remediation plan for any criticals. There is no requirement to prove the control operated effectively over time, because Type 1 is a snapshot.

SOC 2 Type 2 requires evidence that pentesting operated effectively across the audit window, which is typically 6 to 12 months. The minimum is one full pentest inside the window plus continuous vulnerability scanning. Most mature programs run one annual pentest, quarterly automated scans, and a delta retest after any material architecture change. After you pass Type 1, the next decision is when to start the Type 2 window. We cover that in detail in what to do after SOC 2 Type 1.

How to scope a SOC 2 pentest correctly

Start with your SOC 2 system description. List every system, environment, and integration. Mark anything customer-facing or storing customer data as in-scope. Your pentest scope should match this list one-for-one. The fastest way to fail SOC 2 is to scope your pentest narrower than your system description. The second fastest is to scope it broader than your engineering team can remediate inside the audit window.

A typical SaaS scope: production web app, all authenticated user roles, public and authenticated REST/GraphQL APIs, customer-facing admin console, OAuth and SSO flows, file upload and storage paths, third-party integrations exposed to user data, and the cloud control plane that hosts the above. Skip anything that is genuinely out of the SOC 2 boundary, but document the exclusion in the scope letter so the auditor can see you made an intentional decision.

What a passing SOC 2 pentest report includes

Auditors are pattern-matchers. The faster your report fits the pattern they expect, the faster you finish fieldwork. A clean SOC 2 pentest report contains, in order:

• Cover page with engagement dates, tester name, methodology, and scope summary.
• Executive summary with finding counts by severity and an overall risk statement.
• Scope statement mapping in-scope assets to the SOC 2 system description.
• Methodology section naming the standard (OWASP ASVS, PTES, NIST SP 800-115) and the test cases executed.
• Findings with CVSS scores, affected assets, reproduction steps, evidence (screenshots or request/response captures), and recommended remediation.
• Control mapping from each finding to the affected Trust Services Criterion.
• Remediation tracker with status, owner, and target date for every Critical and High finding.
• Retest summary appended after remediation, dated after the fixes were applied.
• Independence attestation and tester qualifications appendix.

Hybrid AI plus human vs DIY internal vs platform-only

Three common ways teams produce the SOC 2 pentest deliverable. Auditor acceptance varies sharply.

Dimension	Hybrid AI + human	DIY internal team	Automated platform only
Independence documented	Yes, engagement letter	Often weak	Vendor attestation, but no human reviewer
Methodology named	OWASP ASVS, PTES	Varies, sometimes ad hoc	Tool-specific, rarely OWASP-aligned
Evidence depth	Screenshots + request/response	Strong if mature	Scanner output only
Exploitation validated	Yes	Usually	No
Retest included	Yes, 90-day window	Depends on capacity	Re-scan only
Auditor first-review pass rate	High	Medium	Low, often kicked back
Typical cost	$5K to $15K	$0 in cash, high in time	$3K to $10K per year

Platform-only scanners often fail SOC 2 because the report contains no exploitation evidence and no human attestation. Auditors flag these reports as vulnerability assessments, not penetration tests, and ask for a full pentest before signing off. The hybrid model produces the report auditors expect on the first pass.

How StealthNet AI handles SOC 2 pentests

Our SOC 2 penetration testing service ships a report that maps every finding to the relevant Trust Services Criterion, includes a remediation tracker, and provides a retest within 90 days. Reports are accepted on first review by every Big Four auditor we have worked with. Engagements typically complete in 5 to 10 business days for SaaS apps, with fixed pricing starting at $5,000. Hybrid AI plus human means the AI agents run broad coverage and our senior testers validate every Critical and High finding by hand, so the report you hand to your auditor matches the nine-point checklist on the first pass.

---

Related reading

• Is a SOC 2 pentest actually required? — what the AICPA actually says.
• What to do after SOC 2 Type 1 — the natural next step before your Type 2 window.
• SOC 2 penetration testing — our scope, deliverables, and auditor-ready report format.
• Compliance pentest hub — one engagement, evidence for SOC 2, ISO 27001, PCI DSS, HIPAA.