# SOC 2 penetration testing requirements and scope

Source: https://penetrationtestservices.com/soc-2-penetration-testing/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

SOC 2 penetration testing requirements: the criteria do not name a pentest, yet auditors and customers ask for one. See the TSC wording and the scope to agree.

> **Short answer:** SOC 2 does not explicitly require a penetration test. The AICPA Trust Services Criteria mention penetration testing as one example of an evaluation, in a point of focus under CC4.1. In practice, customers and auditors often ask for one. Agree the scope with your auditor first. Excession Labs delivers the test and report. We cannot promise acceptance.

If you are preparing for a SOC 2 report, or a customer asked whether you have one, and someone says you need a pentest, start with what the criteria say. Then agree the scope with your auditor before testing.

## What does SOC 2 say about penetration testing?

SOC 2 does not explicitly require a penetration test. The AICPA Trust Services Criteria mention it once as an example. In the 2017 criteria (March 2020 update), the CC4.1 point of focus "Considers Different Types of Ongoing and Separate Evaluations" says: "Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments." ([AICPA TSP 100, copy hosted by Arpio](https://arpio.io/wp-content/uploads/2020/08/trust-services-criteria.pdf)).

CC7.1 is separate. It covers detection and monitoring, and its point of focus "Conducts Vulnerability Scans" names scans, not pentests (same source).

AICPA also publishes a 2022 revision of the points of focus. We could not read that file, because it needs an account. Check the wording in the edition your auditor uses ([AICPA](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022)). The guide [does SOC 2 require penetration testing](/guides/does-soc-2-require-penetration-testing/) discusses this in full.

## What do customers and auditors commonly ask for?

Requests come from your auditor, who looks at the controls you described; from customer questionnaires; and from your own policy, which may say you test every year. Before scoping, ask each of them whether they need any of these:

- A penetration test report from a third party, dated within the last 12 months.
- Scope that covers the systems in the SOC 2 boundary.
- Evidence that findings were triaged and fixed, with dates.
- Proof of a retest for serious findings.
- A statement of tester independence from your engineering team.

The criteria do not set these requests, so ask your auditor what they need. The guide on [security questionnaire pentest questions](/guides/security-questionnaire-pentest-questions/) lists typical wording.

## What should you agree in the scope?

Agree these points before testing, with your auditor and with us.

| Item | Why it matters |
|---|---|
| Systems in the SOC 2 boundary | The test should cover the production app and API that the report describes |
| Environment | Production, or staging that matches it |
| Roles and tenants | Access control testing needs several roles and at least two tenants |
| Dates | Match the audit period and your policy |
| Severity scale | Say how you will track Critical, High, Medium and Low findings |
| Retest | Decide how you will show that serious findings were fixed |
| Report handling | Who may see the full report, and whether a summary letter is needed |

We do not add CVSS vectors by default. If your auditor or customer wants them, say so at scoping.

## How do we prove findings?

A finding needs evidence of a real effect, such as a record read back through another session. We run controls beside each exploit request and list the controls that held. Evidence is saved with timestamps. Your auditor can follow each finding from the claim to the proof.

> **Sample finding:** This is a demonstration. It uses a fictional app, Harbor Notes, and no real customer system was tested.
> 
> **Finding C-01: Reset tokens stay valid after use (Medium).**
> 
> ```http
> POST /api/auth/reset HTTP/1.1
> Host: app.example.com
> Content-Type: application/json
> 
> {"token":"rst_demo_8841","password":"NewDemoPass-1"}
> ```
> 
> The first call returned `204 No Content`. Replaying the same token returned `204` again, and the second password worked at login (Observed). Control: a token with a changed last character returned 400. Fix: invalidate the token on first use.
## What do you get?

You get a report in HTML, PDF and Markdown, with proof-of-concept scripts, an executive summary and a remediation plan. We can retest fixed findings (see [retesting](/retesting/)). For a short summary for customers, read about [attestation letters](/guides/pentest-attestation-letter/) and the [customer security review](/customer-security-review/) page. We do not promise that any auditor or customer will accept a report.

## What do we need from you?

- Written authorization from the system owner.
- The SOC 2 system description or boundary, if you can share it.
- Auditor requirements, in writing if possible.
- Test accounts for each role, with two tenants if you are multi-tenant.
- API docs or a route list.
- A technical contact, and your audit dates.

## What changes the quote?

The size of the boundary, the number of roles and API routes, the environment and the retest set the quote. We publish no prices (see [pricing](/pricing/)).

Ready to scope? [Request a pentest](/contact/).

## Questions

### Does SOC 2 require a penetration test?

Not by an explicit rule. The criteria list penetration testing as one example of a separate evaluation. Whether you need one depends on your controls, your auditor and your customers. The guide [does SOC 2 require penetration testing](/guides/does-soc-2-require-penetration-testing/) goes into more depth.

### Will our auditor accept your report?

We cannot promise that. The auditor decides what evidence they need. Ask them for their requirements before scoping: scope, timing, tester independence and how they want open findings handled. We write the report to match what you tell us.

### Do we need a SOC 2 pentest before the audit window starts?

Ask your auditor. Timing depends on your audit period and your control descriptions. Some teams test before the period to fix issues, then test again during it. Plan the dates with the auditor.

### Is a vulnerability scan enough?

A scan and a pentest are different activities. The criteria name vulnerability scans in a separate point of focus under CC7.1. Your control description should say which you do. Ask your auditor what they want to see.

## Sources

- [AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022)
- [AICPA TSP 100, 2017 Trust Services Criteria (March 2020 update), copy hosted by Arpio](https://arpio.io/wp-content/uploads/2020/08/trust-services-criteria.pdf)