Compliance

SOC 2 Penetration Testing

SOC 2 doesn't name a mandatory pentest, but most auditors expect one. We give you a report built to be read as evidence.

Get a quote Request a sample report

In plain English

What SOC 2 expects from security testing

SOC 2 is an attestation report, not a checklist. Your auditor tests whether your controls meet the AICPA’s Trust Services Criteria, and the criteria describe outcomes rather than prescribing specific activities. That is why SOC 2 doesn’t strictly require a penetration test.

In practice, a pentest is one of the clearest ways to show two things auditors look for. First, that you evaluate whether your controls actually work (criterion CC4.1, whose points of focus name penetration testing as one option). Second, that you identify and respond to vulnerabilities (criterion CC7.1). Enterprise customers reviewing your SOC 2 report often ask for a recent pentest summary too.

What matters to an auditor is that the test is relevant, recent and documented: a defined scope that matches your system boundary, a credible methodology, dated findings, and proof that you fixed what was found. That is what our reports are built to show. Confirm any specific expectations with your audit firm.

Evidence

How our report supports it

A clearly defined scope that maps to the systems in your SOC 2 boundary
The methodology and standards used, so the auditor can judge the test's depth
Dated findings with severity, evidence and remediation guidance
Retest results showing which findings are fixed and when
An attestation letter you can share with customers and your auditor

Scope

Recommended scope

Every environment is different. This is where we usually start, and we'll confirm it on a scoping call.

Web Application Penetration Testing

The customer-facing product in your SOC 2 boundary is usually the core of the test.

API Penetration Testing

Public and internal APIs that handle customer data.

Cloud Security Testing (AWS, Azure, GCP)

The AWS, Azure or GCP accounts that host the in-scope system.

External Network Penetration Testing

Internet-facing infrastructure and admin interfaces.

Timing

When to test

Test early in your observation period, so you have time to fix findings and retest before it ends.
For a Type II report, plan the test so the report and retest both fall inside the review window.
Confirm scope with your auditor before testing starts. It saves arguments later.
Repeat the test at least annually and after major changes, so each audit cycle has current evidence.

FAQ

SOC 2 testing questions

Does SOC 2 require a penetration test?

Not explicitly. The Trust Services Criteria don't mandate a pentest, but the points of focus for CC4.1 name penetration testing as one kind of evaluation, and many auditors and enterprise customers expect to see one. In practice, most SOC 2 programmes include an annual test.

Is a vulnerability scan enough for SOC 2?

Scans help with ongoing monitoring under CC7.1, but they don't show how controls hold up against a skilled attacker. Many auditors and customers treat a manual pentest as stronger evidence than scan output alone.

What should be in scope?

Usually the systems inside your SOC 2 boundary, starting with the product customers use, its APIs and the cloud environment it runs in. We help you agree the scope with your auditor during scoping.

Is a penetration test report a SOC 2 report?

No. A SOC 2 report is issued by a licensed CPA firm after its examination. Our penetration test report is evidence your auditor can review alongside your other controls.

Can you retest before our audit window closes?

Yes. Every engagement includes one retest of reported findings. Plan the retest into your timeline so the updated report is ready when your auditor needs it.

Sources

AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)

Guide8 min read