Short answer: No. The AICPA Trust Services Criteria don't require a penetration test. CC4.1 names penetration testing as one example of an evaluation, and CC7.1 asks you to find new vulnerabilities. In practice most auditors expect one, and enterprise customers ask for the report, usually from a test in the last 12 months.
SOC 2 is a report, not a checklist. An independent CPA firm examines your controls against the AICPA's Trust Services Criteria and writes an opinion. The criteria say what a control should achieve, and leave it to you to decide how. That's why "is a pentest required?" has two answers: what the text says, and what happens in the audit.
What do the Trust Services Criteria actually say?
The current version is the 2017 Trust Services Criteria with revised points of focus from 2022. Two criteria come up when people talk about penetration testing.
| Criterion | What it says | Where a pentest fits |
|---|---|---|
| CC4.1 (monitoring activities) | "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning." | A point of focus names it directly: management uses different types of evaluations, "including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments." |
| CC7.1 (system operations) | "To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." | Its points of focus mention vulnerability scans, run periodically and after significant changes. A pentest isn't named, but it's one way to find the vulnerabilities CC7.1 describes, and auditors often look at pentest results here too |
Points of focus are examples of what a control might include. They aren't requirements, and the AICPA says so in the criteria document. So the literal answer is no: nothing in SOC 2 says "perform an annual penetration test".
Why do most SOC 2 companies get a pentest anyway?
Because two groups of people expect one, even though the criteria don't.
Auditors. A pentest is a common way to show the "separate evaluation" CC4.1 describes, and many auditors ask for one for a SaaS product. Without one, you have to show another way that someone independent checked your controls work. That's possible, and harder.
Enterprise customers. A SOC 2 report is often the first thing a customer's security team asks for, and the pentest report is often the second. Security questionnaires ask for the date of your last test, its scope and whether the critical and high findings were fixed. A SOC 2 report without a recent pentest tends to prompt the follow-up question anyway. What to send when a customer asks for a pentest report covers that part.
Ask your auditor early. They decide what counts as evidence in your audit, and they'd rather tell you before the window than after it.
What do auditors look for in a pentest?
Not a long list of findings. Auditors look at whether the test was a real control that ran and was acted on.
| What they check | What answers it |
|---|---|
| The test ran inside the audit period | Test dates in the report, falling within the Type II window |
| The scope matches the system in your SOC 2 description | The app, API and environment named in the report are the ones in scope for the audit |
| Someone independent did it | A third-party provider, or an internal team separate from the one that built the system |
| A known method was used | A named standard, such as OWASP WSTG, and a coverage summary |
| Findings were triaged | Severity per finding and an owner |
| Findings were fixed or accepted | Fix status and dates, retest results, or a documented risk acceptance |
| It happens again | A stated cadence and evidence that the next test is planned |
How often should you pentest for SOC 2?
The criteria don't set an interval. Most companies test at least once a year, which is also what customers and other frameworks expect: PCI DSS v4.0.1 Requirement 11.4 asks for a pentest at least every 12 months and after significant changes. The CC7.1 points of focus use the same logic for vulnerability scans, periodically and after significant changes.
A yearly test is a floor, not a target. If you ship weekly, a test from ten months ago describes an app you no longer run. Many teams keep an annual test for the audit and add more frequent testing on the live app between those. How often to pentest goes through cadence by app type.
Type I vs Type II: when should the pentest happen?
The two report types test different things, so the timing differs.
| Type I | Type II | |
|---|---|---|
| What the auditor examines | Whether controls are suitably designed, at a point in time | Whether controls are suitably designed and operated effectively, over a period |
| Period | One date | An audit window, commonly 3 to 12 months |
| When to pentest | Before the Type I date, with time to fix what it finds | At least once inside the window, with fixes and retests also inside it |
| What the pentest shows | The control exists and is designed sensibly | The control ran during the period and findings were handled |
A common mistake is a pentest just before the Type II window opens. It shows the test happened, but not inside the period the auditor is looking at. Another is a test so late in the window that there's no time to fix and retest before it closes.
What should a SOC 2 pentest report contain?
Enough for an auditor to check the control and for a customer to judge the risk.
| Section | Why it matters for SOC 2 |
|---|---|
| Scope and system description | Shows the tested system is the one in your SOC 2 scope |
| Test dates | Places the test inside the audit period |
| Methodology and coverage | Shows it was a structured test, such as OWASP WSTG test cases |
| Findings with severity and evidence | The request and response behind each confirmed finding |
| Remediation and retest status | Shows findings were acted on |
| Provider and reviewer | Shows who tested and who stands behind the result |
| Limits | What wasn't tested, such as internal networks or mobile apps |
How continuous pentesting gives evidence across the audit window
A Type II report is about controls operating over time. A single pentest gives you one dated data point in that period. A pentest that runs on a schedule gives you a series.
- Dated runs across the window. Each run is a timestamped test of the app as it was that week or month. That's evidence the evaluation in CC4.1 happened repeatedly, not once.
- Proof that fixes held. Run-over-run labels show a finding going from new to fixed, and staying fixed. If one comes back, it's labelled regressed and you can show when it was caught and fixed again. Security regression testing explains the labels.
- Coverage of significant changes. A run after each major release lines up with the "after significant changes" expectation in the CC7.1 points of focus and in PCI DSS.
It doesn't replace your auditor's judgement, and it isn't a SOC 2 control by itself. It's evidence that supports the controls you describe.
What a pentest doesn't do for SOC 2
A pentest report isn't a SOC 2 report, and a clean one isn't a SOC 2 opinion. It says nothing about access reviews, HR onboarding, vendor management or your incident response plan. Those are for your GRC process and your auditor. A web and API pentest also doesn't cover your internal network or employee laptops, if those are in your SOC 2 scope.
For continuous monitoring of the configuration side (TLS, headers, exposed services) and audit exports, see SOC 2 compliance monitoring. This page is about the pentest question.
How Barrion does it
Barrion's AI agents test your web apps and APIs the way an attacker would, across 8 testing areas, covering all 97 OWASP WSTG v4.2 test cases and the OWASP API Security Top 10.
- A pentest can run again on a schedule or on demand, so there's a dated run across your audit window. Each run labels findings new, still open, fixed or regressed. Runs can also start from your CI/CD pipeline via the Barrion API, which gives you a dated test close to each significant release.
- Findings are checked against the live app before they're reported. Confirmed ones come with the request and response behind them. Anything we couldn't confirm is clearly marked and capped in severity.
- Retests of found issues are free, which gives you the fix-and-retest evidence auditors look for.
- From Standard up, a security engineer reviews the findings, and deeper tests come with a report signed off by that engineer.
- Reports come as PDF, XLSX and JSON with an OWASP WSTG coverage matrix. The sample report shows the layout.
- Data is stored and hosted in Sweden, and AI processing runs in the EU.
We test web apps and APIs only. Continuous programs are scoped to your apps, cadence and depth. Talk to us and we'll price it for your setup, or start with a single run from pricing. The wider model is covered in what continuous pentesting is.
Sources
All sources checked 2026-09-26.
2017 Trust Services Criteria (With Revised Points of Focus, 2022), AICPA, CC4.1 and CC7.1
SOC for Service Organizations Engagements, Overview, AICPA (type 1 and type 2 reports)
SOC 2 Reporting on an Examination of Controls at a Service Organization, AICPA guide
PCI DSS v4.0.1, PCI Security Standards Council, Requirement 11.4
Barrion product facts, facts page