Does SOC 2 require a penetration test?

The short answer

No trust services criterion requires a penetration test. There is no clause number to cite, no annual cadence written down anywhere, and no AICPA statement that makes one mandatory. A service organization can complete a clean SOC 2 type 2 examination without ever commissioning one.

Almost none of them do. The reason is not a hidden rule; it is that three separate parties independently arrive at the same place, and two of them can stop your deal. Understanding which of the three is driving your particular request is what lets you scope the test properly instead of buying a generic one.

What the trust services criteria actually say

A SOC 2 examination is performed against the trust services criteria, a control framework published by the AICPA's Assurance Services Executive Committee. The current edition is the 2017 criteria with revised points of focus issued in 2022, and the AICPA describes them as criteria "for use in attestation or consulting engagements to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems used to provide products or services".

Read that description again, because the whole answer is inside it. The criteria are statements about controls and the outcomes those controls have to achieve. They are deliberately not a list of procedures. A criterion can say that an entity must identify and evaluate vulnerabilities; it cannot say that the only acceptable way to do so is a manual penetration test by an external firm, because for a payroll bureau running on a mainframe and a multi-tenant SaaS running on Kubernetes the right procedure is not the same.

That design choice is what makes the framework portable across every kind of service organization, and it is also why the question "which criterion requires the pentest?" has no answer. The word the standards use is not procedure. It is evidence.

Where the expectation really comes from

One: your customer

Almost nobody buys a SOC 2 report because they want one. They buy it because an enterprise or US customer's vendor security review will not close without it, and that same review has a line asking for a current third-party penetration test report. The SOC 2 and the test arrive in the same email, from the same procurement team, for the same reason.

In Europe that demand now has a legal source behind it. Directive (EU) 2022/2555 (NIS2) requires in-scope entities to manage "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" under Article 21(2)(d), and Article 21(3) requires them to take into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures".

The implementing rules turn that into contract text. Commission Implementing Regulation (EU) 2024/2690, Annex point 5.1.4, requires relevant entities to ensure their supplier contracts specify, among other things, "cybersecurity requirements for the suppliers or service providers", "the right to audit or right to receive audit reports", and "an obligation on suppliers and service providers to handle vulnerabilities that present a risk to the security of the network and information systems of the relevant entities".

Your customer is not being difficult. It is passing down an obligation it cannot delegate, and a report it can file is cheaper for both of you than an inspection it has to send people to.

Two: your auditor

The service auditor has to reach a conclusion about controls, and the sufficiency of the evidence supporting that conclusion is a matter of professional judgment, not a checklist. The AICPA has been notably direct about this recently. Its Professional Ethics Division warned in 2026 that arrangements which shift "control, professional judgment, financial dependency, promotional efforts, or access to evidence away from the member and toward the tool provider" create ethics threats, and that the service auditor must obtain sufficient, appropriate evidence in all circumstances. A separate peer review alert told reviewers that some firms "are leaning too heavily on third-party SOC platforms without applying the professional judgment required by our standards".

Put yourself in that auditor's position. You are examining an internet-facing multi-tenant application. You can ask the engineering team whether access controls between tenants hold, and write down what they tell you. Or you can read a report from an independent firm that tried to break them and documented what happened. Under peer review scrutiny, only one of those looks like evidence.

Three: your own risk assessment

This is the origin most companies miss, and it is the one that bites hardest. The criteria expect the entity to identify its risks and respond to them. If your own risk register names the production platform as the crown-jewel asset and your evidence pack contains no independent test of it, the inconsistency is in your file before the auditor opens it.

The EU rules that come closest to prescribing testing work the same way. Point 6.5 of the Annex to Implementing Regulation (EU) 2024/2690 requires entities to "establish, implement and apply a policy and procedures for security testing", and then to "establish, based on the risk assessment carried out pursuant to point 2.1 of this Annex, the need, scope, frequency and type of security tests", to "carry out security tests according to a documented test methodology", to "document the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding", and to "apply mitigating actions in case of critical findings".

Note what that instrument does not say. It never says "penetration test". It describes risk-based testing with a documented methodology, recorded results and remediated critical findings, and leaves the choice of technique to the entity. That is exactly the shape of the trust services criteria, arrived at independently by a European regulator. When two frameworks written on different continents both refuse to name the procedure, the lesson is that the procedure was never the point: the risk-based reasoning behind it is.

What a test actually evidences

A penetration test is not a general-purpose compliance artifact. It answers a narrow set of questions extremely well and says nothing at all about the rest of the framework. Being precise about which is which keeps the scope honest and stops you paying for a test that proves things you already had covered.

Control questions a test answers, and questions it does not

Control area	What a penetration test contributes	What it does not
Logical access	Whether authentication, session handling and tenant isolation hold up against a motivated attacker with a real account	Whether accounts were provisioned and revoked correctly over the period. That needs joiner and leaver records.
Vulnerability management	Proof that specific weaknesses exist, ranked by exploitability rather than by scanner score, and evidence they were fixed	That the process runs continuously. A scan schedule and a remediation SLA cover that.
Change management	Evidence that a change introduced or removed a weakness, when the test brackets a release	The approval trail. Only tickets show that.
Monitoring and detection	Whether your logging and alerting noticed the testing at all, if the engagement is scoped to check	Whether alerts were triaged consistently over the observation period.
Risk assessment	A dated, external opinion on where the real exposure sits, which feeds the next risk assessment	The risk assessment itself. That remains management's document.
Vendor management	Nothing directly, unless the test covers an integration you own	Your suppliers' own controls. Their assurance reports cover those.

How recent does it have to be?

There is no rule, which in practice means twelve months. Enterprise security reviewers routinely reject a report dated more than a year ago, and once a habit like that is universal it functions as a requirement even though nobody wrote it down.

For a type 2 examination there is a sharper constraint. The report covers a defined observation period and opines on whether controls operated effectively throughout it. A test dated before the period opened is evidence about a system that no longer exists in the form examined. Schedule testing so that the engagement, the remediation and the retest all land inside the window.

The other trigger is change, not the calendar. A significant architectural change – a new tenant model, a new authentication provider, a migration between cloud accounts – invalidates the parts of a report that describe the old system. Retesting the changed surface is cheaper than explaining to a reviewer why the report predates the thing they are worried about.

What happens if you decide not to test

Nothing automatic. There is no rule to breach. What happens is a sequence of small frictions that add up to more than the test cost.

• The auditor asks how you satisfied yourself about the security of the production platform, and your answer is internal review. That is acceptable, and it makes the engagement more expensive because more inquiry has to be corroborated some other way.
• The report lands with your customer's security reviewer, who reads it alongside a questionnaire that asks for a penetration test report. The answer "we do not commission one" gets escalated, and escalation costs sales-engineering weeks.
• A finding surfaces later through a bug report, a customer's own testing, or an incident. The absence of testing then becomes a governance question rather than a technical one, and it is asked by people who are already unhappy.
• Your next contract renewal includes the audit right your customer's own regulator obliges it to insert. Hosting an inspection costs more than sharing a report.

None of this is a rule. All of it is the reason the honest answer to "is it required?" is "no, and you are going to buy one anyway".

Test before remediation, or after?

After, with one exception. Testing an environment you already know is unfinished produces a report full of findings you had on your own list, and every one of them then has to be tracked, remediated and retested at report-writing prices. Fix the known baseline first: multi-factor authentication on privileged paths, centralized logging, patching, and whatever the last scan reported.

The exception is the first engagement of a program with no internal security function at all. There, an early scoping test is worth buying purely as a map, on the explicit understanding that it will be repeated once remediation is done and only the second report goes anywhere near an auditor or a customer.

A cheap SOC 2 report may fulfill the requirements of a contract, but it may come with obvious deficiencies that leave clients at risk.Journal of Accountancy, February 2026

The same is true of a cheap penetration test. A report that lists scanner output, contains no proof of exploitation and has no retest section will be recognized for what it is by any reviewer who has read a real one, and the reviewer is precisely the person you bought it for.

What a report has to contain to be usable

A test report becomes evidence only if a third party can read it and understand what was and was not examined. The minimum set is short and almost never complete in practice.

• A scope statement that names the systems, environments and account types tested, traceable to the system description in the SOC 2 report
• The dates the testing ran, not only the date the report was issued
• The methodology and the severity scale, stated well enough that a reader can tell whether "high" means the same thing it means elsewhere in your evidence
• Reproduction detail for each finding, so remediation can be verified rather than asserted
• Remediation status and, critically, retest evidence with its own date
• A summary a non-technical procurement reader can act on without misreading it

The retest section is the one enterprise reviewers check first and the one most reports omit. A finding marked "remediated" by the client, with no independent confirmation, is a claim. A retested finding is evidence. The difference is a few hours of work and it is the difference between a report that closes a review and one that starts a conversation.

What this means for a European vendor

If your buyers are American, you will need the SOC 2 and you will need the test, and the reasoning above is all you need to scope both. If your buyers are European regulated entities, look closely before committing: the testing obligation reaches you directly through Article 32(1)(d) of the GDPR, which requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing" from processors as well as controllers, and the certificate those customers usually name is ISO/IEC 27001 rather than SOC 2.

The test is the constant in both worlds. The report wrapped around it is the variable, and it is worth choosing on the basis of who is actually asking. That comparison is set out in SOC 2 or ISO/IEC 27001 for an EU vendor, and the question of who is permitted to sign each document is in who can issue a SOC 2 report in the EU.