Table of contents
20
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: SOC 2 penetration testing is not required by the AICPA’s criteria, but almost every auditor asks for one anyway, and timing and scope decide whether your pentest counts as evidence.
- SOC 2 does not require a penetration test, but its own criteria name one anyway. The AICPA’s Trust Services Criteria mention “penetration testing” in one place only, an optional point of focus under CC4.1, on page 32 of the 2017 criteria with points of focus revised in 2022.
- Audit firms disagree on the wording, not the practice. Linford & Co, a CPA firm, says “the simple answer is no.” A-LIGN, a CPA firm that also sells pentests, calls it “no longer optional.” Even Linford tells any company with a public-facing website to “strongly consider” one.
- Type I and Type II run on different clocks. Secureframe, a compliance-automation platform, says a Type I pentest can date back up to 12 months before the report date, while a Type II pentest has to fall inside the audit period. Neither window comes from the AICPA text.
- Published SOC 2 penetration testing prices start around $1,000 and have no fixed ceiling. Astra quotes “between $2,000 and $25,000,” and Axipro quotes “between $1,000 and $30,000 for most companies,” with a SaaS median around $12,000 to $15,000 and enterprise scopes higher. Both are pentest vendors, and neither number is your price until your scope is set.
- Continuous scanning strengthens your SOC 2 evidence but has not replaced the annual pentest. CC4.1 asks for “ongoing and/or separate” evaluations, which I read as room for both, but I have not seen an auditor or AICPA statement that treats continuous testing as a replacement for the pentest.
SOC 2 penetration testing sits in an odd spot. The standard’s own text barely mentions it, and yet almost nobody preparing for an audit gets to skip it. That gap is where most of the confusion lives.
I have read the actual AICPA criteria so you do not have to. The phrase “penetration testing” shows up in one place, a list of example evaluations under a single criterion, and the AICPA says points of focus like that one do not all have to be addressed. But your auditor is a person, not a copy of the standard, and nearly every auditor treats SOC 2 penetration testing as the cleanest proof your controls got tested.
So here is what this guide to SOC 2 penetration testing answers directly: whether you need one, when to run it for a Type I versus Type II report, how to scope it so it survives review, what it actually costs from named vendors, and whether the continuous scanning you already run does the job instead.
No. People mix the two up a lot, so here is the plain version: SOC 2 is an audit, and a penetration test is one piece of evidence that goes into it.
Two things people often get wrong:
No. SOC 2’s Trust Services Criteria do not require a penetration test anywhere in their text. But they do name one, and most guides quote a fragment of CC4.1 without showing where that mention sits or why it is optional.
The criterion in question is CC4.1: “The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.” Nothing about penetration testing there. Underneath it, on page 32 of the AICPA’s Trust Services Criteria, a point of focus lists the evaluations management might use: “first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments.”
That point of focus is the only place the words appear, and the AICPA says plainly: “Use of the trust services criteria does not require an assessment of whether each point of focus is addressed.” Penetration testing is an example, not a box you have to tick.
The same list names “vulnerability scans” and “penetration testing” as separate items, and CC7.1, the criterion covering new vulnerabilities, has its own point of focus for scanning. The AICPA’s own text treats them as two different activities, so a scan report is not a stand-in for the pentest your auditor asked for.
Named firms land differently on it, and who is talking matters:
Put together, SOC 2 penetration testing is not required by the text, yet auditors expect it almost everywhere. The one firm calling it a necessity, A-LIGN, also sells the test, which does not make it wrong, but it is a sales recommendation rather than a reading of the standard.
SOC 2 is not alone here. PCI DSS explicitly requires a penetration test under Requirement 11.4, the opposite situation.
HIPAA sits closer to SOC 2: a proposed HIPAA rule would add pentesting, but nothing is locked in yet. For SOC 2, the pentest expectation comes from auditors and customers, not from the rule text.
Your auditor is not grading SOC 2 penetration testing against an AICPA checklist, because the AICPA has not published one. They use it as evidence for specific criteria, mainly CC4.1 (the evaluation happened) and CC7.1 (you are watching for new vulnerabilities), and they check it against what you told them in your system description.
If a critical or high finding sits unresolved with no retest, that is a real problem. Astra, a pentest vendor, warns that unresolved critical findings “may result in qualified opinions or exceptions noted in your SOC 2 report,” the auditor’s way of saying your controls did not fully hold up.
Practitioners who write about SOC 2 penetration testing keep naming the same items auditors check:
| What auditors check | Why it matters |
|---|---|
| In-scope systems match your system description | A skipped system is not evidence of anything |
| Test dates fall inside the right window | A common rejection point, covered below |
| Methodology is named | NIST SP 800-115, PTES or OWASP WSTG shows a real process, not an ad hoc scan |
| Tester firm and qualifications are stated | Independence and competence both matter |
| Findings carry severity ratings | Lets the auditor judge risk, not just count bugs |
| Remediation status is tracked | Shows the control loop actually closed |
| Retest evidence for critical and high findings | Without it, a serious finding sits unresolved on paper |
For how a full engagement runs, from scoping through the final report, see my penetration testing checklist from scoping to reporting.
Your SOC 2 auditor generally should not also be your pentester. AICPA independence rules limit a CPA firm’s non-attest work for a client it also audits, and an auditor cannot credibly grade evidence its own firm produced. Several audit firms also sell pentests, so if yours does, ask how it keeps the two apart.
For SOC 2 penetration testing, Type I and Type II do not run on the same clock, and mixing them up is an easy way to hand your auditor evidence from the wrong dates.
For a Type I report, Secureframe, a compliance-automation platform, puts it simply: “a pentest can have occurred anytime within 12 months prior to the report date.” Type I is a snapshot, so an earlier pentest still counts as long as it is recent enough to be credible.
For a Type II report, Secureframe is stricter: “the pentest must occur during the actual audit period.” Type II covers a window of months, and your evidence has to fall inside it. Neither window appears in the AICPA criteria, so treat both as auditor practice rather than a standard.
My advice, and this is my own read rather than a rule from any standards body: run the test early enough inside the window to fix what it finds and get the retest done before the window closes. A pentest run in the last week of a Type II period leaves no time to fix and retest inside the window, so its findings reach your auditor still open.
The mistake practitioners flag most often in SOC 2 penetration testing has nothing to do with the findings: the scope does not match the system description.
SoftwareSecured, a pentest vendor, gives the classic example: a company tests its web application, hands over the report, and the SOC 2 system description also covers a mobile app nobody scoped in. The pentest itself might be fine. It just does not cover what the audit claims it covers.
If something genuinely sits outside scope, say so on purpose. As SoftwareSecured puts it, “document every exclusion explicitly in your pentest report. Your auditor needs to see that the decision was deliberate, not an oversight.”
Before you scope SOC 2 penetration testing, check your current system description line by line against what the pentest will actually cover. It sounds obvious, but SoftwareSecured calls reusing last year’s scope without that check “one of the most common sources of SOC 2 coverage gaps.”
Annual SOC 2 penetration testing is the convention, not an AICPA rule, since SOC 2 sets no testing calendar. BARR recommends an annual external pentest, while Linford argues frequency and scope should follow a real risk assessment rather than a fixed date.
Our own sample report prints the cadence we recommend: “annually, or on major change.” The second half matters because a big change can make last year’s report describe a system you no longer run.
Compliance and pentest vendors commonly name the same out-of-cycle triggers, though no standards body lists them: a major new feature, a cloud migration, a new authentication system, or a security incident. Any of them is a good reason to test again.
CC4.1’s own words are “ongoing and/or separate evaluations.” My reading of that wording, and it is only my reading, is that continuous testing is an ongoing evaluation and an annual pentest is a separate one, so the criterion leaves room for both.
No auditor or AICPA statement I have seen says continuous testing replaces annual SOC 2 penetration testing. Practitioners broadly treat automated scanning as a complement to a human-led pentest, because scanner output does not show exploitation, chained attack paths, or business-logic abuse. I compared what AI and human testers each catch separately.
Vendors selling AI-led testing disagree with each other. Cobalt, a pentest vendor, says its own Autonomous Pentest “does not produce compliance attestation reports,” while Aikido markets an “audit-grade SOC2 or ISO27001 PDF report” and Strix sells a SOC 2 pentest that pairs AI agents with human reviewers. Each is selling its own answer.
My practical recommendation for SOC 2 penetration testing: keep one human-verified pentest inside the audit window, run continuous scanning between engagements, and retest after anything major changes. That strengthens the “ongoing” half of CC4.1, but for most auditors it has not replaced the “separate” half.
Weighing AI-run SOC 2 penetration testing specifically? I wrote a full breakdown of which frameworks accept one and which still expect a named human on the report. For SOC 2, the AICPA has published nothing on AI-run tests either way, so ask your auditor directly and early.
There is no single price for SOC 2 penetration testing, and anyone who gives you one without asking about your scope first is guessing.
Published ranges are wide. Astra, a pentest vendor, quotes “between $2,000 and $25,000,” while Axipro, another pentest vendor, quotes “between $1,000 and $30,000 for most companies,” with a SaaS median “around $12,000 to $15,000” and enterprise scopes at “$20,000 to $50,000 or more.”
Cobalt sells an Autonomous Pentest at $3,500 per test as a limited-time offer, but Cobalt itself says that product “does not produce compliance attestation reports,” so it is not a like-for-like price for SOC 2 evidence.
None of these is the price. They are ranges from vendors who define scope differently, and your number depends on what you are actually testing.
| What drives the price | Why it moves the number |
|---|---|
| Number of apps and APIs in scope | More surface area, more testing hours |
| Authenticated vs. unauthenticated testing | Logging in as each user role takes longer than testing from the outside |
| Number of user roles | Each role needs its own authenticated pass |
| Internal network in scope | Adds testing from inside your network, not just the perimeter |
| Mobile apps included | iOS and Android are each tested on their own |
| Cloud configuration review | AWS, Azure or GCP review adds specialized hours |
| Retest included or billed separately | Auditors look for retest evidence, so check whether the quote covers it |
XHack’s published prices are fixed and include a retest in every tier: Essential from $2,500, Assurance from $5,000, Comprehensive from $12,000, and Enterprise quoted to scope. More on where Assurance fits a SOC 2 cycle below.
Choosing a provider for SOC 2 penetration testing for the first time? The questions worth asking before you sign anything save you from most of this list.
Vanta, Drata and Secureframe do not do SOC 2 penetration testing themselves. They take the finished report and treat it as a piece of evidence, mapped to a control such as CC4.1 or CC7.1, sitting alongside your policies and access logs.
All three also run partner networks that refer pentest providers, so their pentest guidance comes with a referral business attached.
What matters is the report itself. These platforms store it as evidence, but your auditor is the one who reads it, so the brand of test matters less than whether the report covers the checklist above.
So yeah, here’s where we talk about what XHack brings to the table.
XHack is three things in one place: human-led testing, an AI agent, and a security platform that keeps watching between tests. Here is exactly what that means for your SOC 2 audit.
What XHack gives you:
What XHack does not give you:
For SOC 2 penetration testing itself, start with the tier we built for this exact situation: Assurance, from $5,000. We describe it as “human-led testing built to stand up to an auditor,” best for “SOC 2, ISO 27001 and PCI DSS cycles, and annual testing obligations.”
Inside it: two OSCP-certified testers working alongside our AI agents (with your explicit permission, at no extra cost), covering internal and external targets across web, host, API and mobile. Scope covers up to 3 unauthenticated web apps, or 1 low-complexity authenticated web app tested across its user roles, or up to 100 host IPs.
Evidence maps to PCI DSS, SOC 2, ISO 27001, HIPAA and GDPR, and the tier includes a patch verification retest and a findings walkthrough call, in five days to two weeks, fixed at scoping.
For a smaller scope, such as one unauthenticated web app or up to 50 hosts for a pre-launch check or vendor questionnaire, Essential starts at $2,500. Comprehensive starts at $12,000 and adds attack-path chaining across targets and a cloud configuration review across AWS, Azure and GCP.
Enterprise is quoted per client and runs as a continuous, quarterly or release-cadence program, with red team and incident response layered in.
Every tier is fixed-price with a verification retest included, which our pricing FAQ calls “part of the price, not an upsell.” Whoever you hire, ask whether the retest is inside the quoted number.
Here is something I can show you rather than just claim: XHack’s 31-page sample pentest report, with a test window of 4 to 15 August 2026 (it opens after a short form). Hold it against the SOC 2 penetration testing checklist from earlier in this guide.
One honest caveat: that report maps SOC 2 at the framework level, citing CC7.1 and CC4.1 once, while PCI DSS, ISO 27001, GDPR and NIST CSF also get a finding-by-finding cross-map. If your auditor wants each finding tied to a specific SOC 2 criterion, raise it at scoping, with us or any other vendor.
Beyond the engagement, XHack’s compliance consulting covers a SOC 2 gap analysis, policy development, control implementation, and pre-audit work that organizes your evidence and readies your team for auditor interviews, quoted on request.
Between audit cycles, the company platform (from $560 a month) runs 2 to 12 vulnerability assessment scans a month by plan, with reports built for internal teams, clients or auditors, plus a security operations (SOC) dashboard mapped to MITRE ATT&CK. For hands-on testing of your own, the XHack AI agent starts at $20 a month, and your pentest chats and session data stay on your own machine, where you can delete them any time. Both come with a 7-day free trial, no credit card required.
Want a fixed-price quote scoped to your actual system? Request one on our services pricing page. If you would rather talk it through first, book a free consultation, even if it ends with you deciding we are not the right fit. Brutal honesty is kind of our thing.
No. SOC 2 is an audit report about your security controls, written by an independent CPA firm, and a penetration test is one piece of evidence that audit uses. A pentest company cannot make you “SOC 2 certified,” because SOC 2 is a report from your auditor, not a certificate.
No, not by the text of the standard. The AICPA’s Trust Services Criteria name penetration testing in one place, an optional point of focus under CC4.1, and the AICPA says not every point of focus has to be addressed. In practice, nearly every auditor asks for SOC 2 penetration testing anyway, as the clearest evidence your control evaluations are real.
Annual is the common default for SOC 2 penetration testing, recommended by BARR Advisory, and it is also the cadence we print in our own sample report (“annually, or on major change”). Linford & Co argues frequency should follow your own risk assessment instead. Either way, a major feature launch, a cloud migration, a new authentication system, or a security incident is a common reason to test again before the year is up.
Not by the AICPA’s criteria, but if your auditor asks for SOC 2 penetration testing, the timing is looser than for a Type II. Secureframe, a compliance-automation platform, says that for a Type I report “a pentest can have occurred anytime within 12 months prior to the report date,” because Type I is a snapshot. For a Type II report, it says the pentest “must occur during the actual audit period.”
Generally not. The AICPA lists vulnerability scans and penetration testing as separate items under CC4.1, and CC7.1 has its own point of focus for scanning, so the standard itself treats them as different activities. Most auditors read scanner output as a starting point, not a substitute for human-led SOC 2 penetration testing that shows real exploitation.
The AICPA names no tester credential for SOC 2 penetration testing, so what matters is independence and a report that shows its work. Your SOC 2 auditor should generally not also run your pentest, because AICPA independence rules limit a CPA firm’s non-attest work for an attest client. A qualified third party that documents its methodology, names its testers and provides retest evidence gives stronger evidence than an internal, self-run test.
Not fully. CC4.1 asks for “ongoing and/or separate evaluations,” and in my reading continuous testing fits the “ongoing” half, but I have not seen any auditor or AICPA statement saying it replaces the annual, separate pentest. Keep at least one round of human-verified SOC 2 penetration testing inside your audit window and treat continuous testing as the layer between engagements.
SOC 2 does not require a penetration test. It names one in a single optional point of focus under CC4.1, and the AICPA says not every point of focus has to be addressed.
Nearly every auditor wants one anyway. What decides whether SOC 2 penetration testing counts is not whether you bought a test, but whether the timing matches your report type, the scope matches your system description, and the retest evidence shows the findings actually got fixed.
Get those three right and the “is it required” argument stops mattering, because you will have the evidence either way. If you want a second opinion on your scope before the audit window opens, book a free consultation.
Categories
Related articles
