Compliance / SOC 2 / CC4.1

SOC 2 penetration testing: what auditors expect.

SOC 2 does not strictly require a penetration test. A point of focus under criterion CC4.1 names penetration testing among the separate evaluations a company can use to check that its controls work. This page shows where it sits in the criteria, what they leave to you, and what a useful report contains.

Updated: 2026-10-10
Sources: 07

Where a pentest sits in SOC 2.

FIG. 1 / SOC 2 AND THE PENTEST

Framework: AICPA Trust Services Criteria (TSP section 100), 2017, with points of focus revised in 2022Note 1
Path: TSC / CC4 MONITORING ACTIVITIES / CC4.1 / POINT OF FOCUS
Point of focus: Considers different types of ongoing and separate evaluations
Names: Penetration testing, beside other evaluations such as independent certification and internal auditNote 2
Required: No. Using the criteria does not require that each point of focus is addressedNote 3
Also used for: ISO/IEC 27001:2022 controls A.8.8 and A.8.29, see section 4

Does SOC 2 require a penetration test?

No. A SOC 2 report tests controls against the AICPA Trust Services Criteria, and the criteria come with points of focus: examples of what a control may address. The criteria state that using them does not require an assessment of whether each point of focus is addressed.Note 4

Penetration testing appears in one of those points of focus, under CC4.1, among the ongoing and separate evaluations an organisation can use to check that its controls are present and functioning.Note 5

So the test is optional on paper. In practice your SOC 2 report is read by your customers' security teams, and the controls it covers, from logical access to change management, are the ones a penetration test tries to get around. A recent test shows that the controls work, not only that they exist.

What scope fits a SOC 2 pentest?

The criteria leave scope to you, so tie it to the system your SOC 2 report describes. For most SaaS companies a useful test covers:

the production application and its APIs, with an account for each role a customer can have, because authorization between tenants is what your customers' data depends on;
the authentication and session handling behind your logical access controls;
the cloud account and its identity configuration, where the infrastructure is part of the system description;
any AI feature in the product, with what it can read and the tools it can call, since it is part of the system your customers use.

Leave out what the report leaves out, and say so. A test wider than the system description is fine; a test narrower than it leaves a gap someone will ask about.

What the report needs to show.

Scope and period: Systems, accounts and dates, matched to your system description and audit period.
Method: The standard each test maps to, such as the OWASP Web Security Testing Guide and the OWASP API Security Top 10 (2023).Note 6
Findings: Evidence for each issue and a severity in CVSS v4.0.Note 7
Remediation and retest: Which findings were fixed and confirmed fixed, with dates: the follow-up evidence for each one.
Tester: Who tested, and their qualifications.
Attestation letter: One page with scope, dates and outcome, to share with customers without the findings.

Does the same report work for ISO 27001?

Usually, yes. If you hold or pursue ISO/IEC 27001:2022, a pentest report is common evidence for two controls in its Annex A: 8.8, management of technical vulnerabilities, and 8.29, security testing in development and acceptance.Note 8

As those reproductions read, neither control names a penetration test; a test report is one way to evidence both.Note 9 Check with your certification body which evidence it expects for your scope.

Test what your system description covers.

For most SaaS companies that is the platform; for a growing number, also the AI feature on it.

01 / Model layer

AI Pentest

The AI feature your customers use: what it reads, what it reveals and which tools it can call on someone else's say-so.

02 / Stack layer

Stack Pentest

The application, its APIs and the cloud account behind them: authorization between tenants, authentication, sessions and configuration.

03 / Clearance

Launch Clearance

The SaaS platform and its AI feature in one scope and one report, including the paths that run from the conversation into the stack.

SOC 2 questions we hear before a test.

How often should a SaaS company pentest for SOC 2?

Once in each audit period, timed so the report and the retest both land inside it, and again after a major change to the system, such as a new product area, a new cloud account or an AI feature. That is our advice, not a rule from the criteria.

Does a pentest replace our vulnerability scanning?

No. Scanning is a recurring control that finds known weaknesses; a pentest is a separate evaluation that shows what an attacker can do with them, including business logic and authorization flaws a scanner does not model. The CC4.1 point of focus names both kinds of evaluation.

What if the pentest finds something just before the audit?

Fix it and have it retested. A finding that was found, fixed and confirmed fixed inside the period is evidence that your monitoring works. Hiding it is the only outcome that looks bad, and the report is the record that shows you did not.

Can you test our AI feature in the same engagement?

Yes, when it is part of the system your report describes. Launch Clearance tests the SaaS platform and its AI feature together, in one scope with one report, including the paths that run from the conversation into the stack, so your auditor reads one document.