SOC 2 penetration test: what your auditor actually asks for.
SOC 2 never uses the words "penetration test" as a requirement. Your auditor will still expect one, and will flag its absence. This page explains exactly which criteria a test evidences, what the report has to contain to be accepted, and when it has to happen. New to the format first? See a real sample report.
No, SOC 2 does not require a penetration test.You should still get one.
Plenty of vendors will tell you SOC 2 mandates a pentest. It does not, and it is worth being precise about this, because the distinction changes how you scope and time the work.
SOC 2 is not a certification. It is an attestation report issued by a CPA firm against the AICPA Trust Services Criteria. Those criteria describe outcomes, not tools. Nowhere do they state that you must run a penetration test.
What they do require is evidence that your controls were evaluated and that they worked. And the criteria themselves name penetration testing as a way to produce it. The point of focus under CC4.1 lists the acceptable forms of separate evaluation and puts penetration testing first, alongside independent certifications and internal audit assessments.
So the accurate position is this:
- Not mandated by name
- Explicitly named in the criteria as expected evidence
- Absent from your evidence pack, it is commonly recorded as a gap
In practice, most organisations that pass a SOC 2 audit have run one.
A scan and a pentest evidence different criteria.
Two criteria carry most of the weight. Understanding which is which matters, because it determines whether your existing vulnerability scanning is enough. It is not.
| Criterion | What it asks | What satisfies it |
|---|---|---|
| CC4.1 — Monitoring Activities | The entity performs ongoing and/or separate evaluations to confirm internal controls are present and functioning (COSO Principle 16) | The penetration test itself, as the periodic separate evaluation |
| CC7.1 — System Operations | Detection and monitoring procedures identify configuration changes that introduce new vulnerabilities, and susceptibility to newly discovered ones | Ongoing vulnerability scanning |
| CC6.1 — Logical & Physical Access | Access controls cannot be bypassed | Authorisation and privilege-escalation findings from the test |
| CC7.2 / CC7.3 — Security Events | Anomalies are detected, evaluated and responded to | Optional. Relevant if detection response is in scope |
Automated scanning maps to CC7.1. Manual penetration testing maps to CC4.1. Both are expected. Neither one substitutes for the other. If your answer to the auditor is "we run weekly scans", you have evidenced CC7.1 and left CC4.1 open.
A scan tells you a port is open. A pentest tells you what an attacker does with it.
For Type II, the test must fall inside the observation window.
This is the detail that causes rescheduling and delayed reports, and it only applies to Type II.
Type I assesses whether controls are suitably designed at a single point in time. Timing is flexible.
Type II assesses whether controls operated effectively across an observation period, typically 6 or 12 months. Your penetration test must fall inside that window. A test completed the month before your period opens produces limited value for the report, and you may be asked to repeat it.
Practical consequences:
- Schedule the test early in the observation window, not at the end. You need time to remediate and retest before the period closes.
- If findings are still open when the period ends, that is what the auditor sees.
- Annual is the cadence the market has settled on. SOC 2 does not prescribe one. Organisations with a high rate of change often test more often.
Resync turnaround from intake to final report is typically 1 to 3 weeks, with a fixed date agreed before you commit.
Seven things an auditor looks for.
A pentest report is only useful to your audit if the auditor can tie it to your system boundary and see the loop close.
- A scope statement that matches your SOC 2 system boundary. A report scoped to a different perimeter does not evidence the controls under examination.
- Test dates inside the observation period for Type II.
- Methodology and named tester qualifications. Who tested, against what standard, with which credentials.
- Findings with severity ratings and business impact, not raw tool output.
- Reproduction steps your developers can act on.
- Remediation evidence and a retest confirmation. The closing artifact, in writing.
- Findings mapped to the criteria they evidence, so the auditor does not have to do the translation themselves.
Scanner-only and AI-only platforms sold as "penetration tests" are increasingly not accepted. What is expected is human-driven adversarial testing that finds the business logic flaws and chained exploits a tool cannot reach.
Every engagement produces all seven, as standard.
Two of them are usually charged separately elsewhere.
- Fully manual testing. No scanner output with a cover page. OSCP and eWPTxv2 certified, MSc Cyber Security.
- Retest included in the fixed price. After you patch, I verify the findings are genuinely resolved and issue a written retest declaration. That declaration is the artifact your auditor wants, and it is not a separate quote.
- Control-mapping appendix. For compliance-scoped engagements, each finding is mapped to the Trust Services Criterion it evidences, so the report drops straight into your audit file.
- Executive summary and technical detail in one document. Readable by the CISO, the board and the development team.
- Digitally signed report. Your auditor can verify authenticity independently at re-sync.nl/verify, in their own browser, with the file never uploaded.
- NDA standard. Rules of engagement agreed in writing before testing starts.
Fixed price based on scope, agreed before the work begins.
No hourly billing.
| Scope | Indicative price | Typical fit |
|---|---|---|
| Security Quick Scan | from €1,000 | One day, focused. Establishes whether a full test is needed. |
| Compact | from €2,500 | One web application or API with limited roles. |
| Standard | from €4,500 | SaaS product with multiple roles and tenants. |
| Extensive | from €7,500 | Complex platform, multiple applications or infrastructure. |
A SOC 2 engagement is scoped for audit evidence rather than coverage alone. It adds criterion mapping, a report structured to your system boundary, and a retest declaration your auditor can act on. In practice most SOC 2 work falls in the Extensive band, from €7,500, and rises from there for larger or multi-application environments.
For context on the international market, published 2026 figures put typical penetration testing engagements between roughly $10,000 and $30,000, with an all-types average near $18,300 (Synack, 2026 pricing report).
What you are not paying for at these rates, and should know before comparing: there is no PTaaS dashboard, no 24/7 support portal, and no bench of testers to scale onto a two-week deadline. There is one senior tester, working manually, at a fixed price, with the retest included.
SOC 2 questions, answered precisely.
Does SOC 2 require a penetration test?
Is a vulnerability scan enough for SOC 2?
When in my SOC 2 timeline should the test happen?
How often do I need to test?
Do you have SOC 2 experience?
Can you work with our auditor directly?
Where are you based, and does that matter?
Testing for a SOC 2 audit?
Tell me in a few sentences what is in scope and when your observation period opens. You will hear back within one business day, and you only receive a quote if you ask for one.
Book a free intake → Pursuing ISO 27001 too?Keep reading
- AICPA, 2017 Trust Services Criteria (with Revised Points of Focus, 2022), TSP Section 100. Criteria CC4.1, CC6.1 and CC7.1. aicpa-cima.com
- COSO, Internal Control, Integrated Framework (2013). Principle 16, Monitoring Activities. coso.org
- Synack, How Much Does a Pentest Cost? (2026 Pricing Guide). Cited for the international market pricing range. synack.com