Does SOC 2 Require Penetration Testing?

Video transcript

Does SOC 2 require a penetration test? No. But buyers ask for it, and your own controls may promise it.

Mike DeKock, a CPA, says no SOC 2 criterion explicitly requires a pentest. He still calls it highly advisable.

Pentest evidence usually maps to C C four point one, monitoring, and C C seven point one, detection, which are points of focus, not requirements.

It becomes required in practice when a control promises it. If your system description commits to an annual pentest, the auditor tests that commitment.

Auditors trace it end to end: a test window inside the observation period, targets matching your system boundary, findings fixed on time, an independent retest letter, and a matching findings register.

In crypto, scope follows every system that can move funds. Apps, APIs, wallet and signing services, cloud and pipelines, admin tools, and offchain automation.

One gap stays open. Neither a pentest nor a SOC 2 reviews contract logic. That takes a smart contract audit.

For a Type 2, test inside the observation period. With a thirty day fix window, start at least eight to ten weeks before it ends, then fix, retest, and test again after major changes.

Guardian does not issue SOC 2 reports, a licensed CPA firm does. Guardian runs the pentest, retests, and prepares the evidence. Read the full article, or book a pentest at guardian.security.

A SOC 2 is a CPA's report on the controls you put in scope. The criteria say what controls must achieve, not which tests prove it.

So the pentest question has two answers. The criteria do not require one. Your buyers, and your own control list, may.

For what a SOC 2 covers in crypto and what it misses, see SOC 2 for crypto companies. This post covers the pentest only.

The Short Answer

No criterion says "perform a penetration test". Mike DeKock, a CPA who founded MJD Advisors, puts it plainly in a 2024 piece republished by the Cloud Security Alliance.

He writes that "there are no explicit requirements for penetration testing (or any controls) within a SOC 2 report."

A pentest "isn't required to complete a SOC 2 report, but it is highly advisable," he adds. He calls it the most common last requirement his firm hears before an enterprise deal closes.

Drata's March 2026 cost guide makes the same point from the buyer side. It says many customers demand an annual pentest as part of their due diligence.

One thing makes it required in practice: a control that promises it. If your system description commits to an annual pentest, the auditor tests that commitment.

Where Pentests Fit in the Criteria

Pentest evidence usually maps to CC4.1 and CC7.1. TCSA adds CC8.1 where a significant change triggers the test.

We quote the AICPA's 2017 criteria in their March 2020 edition. The AICPA revised the points of focus in 2022; that edition sits behind a login.

CC4.1: monitoring activities

CC4.1 says the entity "selects, develops, and performs ongoing and/or separate evaluations" to confirm controls are present and functioning.

One of its points of focus names the test. Management uses evaluations "including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments."

CC7.1: detection and monitoring

CC7.1 asks for detection and monitoring procedures. They identify configuration changes that introduce new vulnerabilities, and "susceptibilities to newly discovered vulnerabilities."

Its points of focus name vulnerability scans, run "on a periodic basis and after any significant change in the environment." TCSA, a compliance firm, notes most control sets put the pentest beside scanning here.

Points of focus are not requirements

The AICPA is explicit: using the criteria "does not require an assessment of whether each point of focus is addressed."

So a firm may evidence CC4.1 with other evaluations the point lists, such as internal audit or an ISO certification. Whether that satisfies your auditor and buyers is a separate question.

What Auditors Check

Where a pentest is one of your controls, expect the auditor to trace it end to end. TCSA, reviewed August 2026, lists the evidence auditors ask for:

• A test window inside the observation period, or a documented reason it is not.
• Targets that match the system boundary in your description, line by line.
• Findings fixed within the remediation window you published.
• A retest letter from the testing firm, not self-attested closure.
• A findings register that matches the report and your ticket export.

An annual test is a population of one, TCSA adds, so the auditor examines it in full.

Scope for Crypto Platforms

The pentest scope should follow the system boundary. In crypto, that boundary runs through every system that can move funds.

Two crypto gaps need their own answer:

• Carved-out vendors. If your wallet or MPC provider is carved out, test your integration and collect its own report.
• Smart contracts. A pentest does not review contract logic, and neither does a SOC 2. That takes a smart contract audit.

For a fuller exchange scope, see what a crypto exchange pentest covers.

Timing in the Audit Window

A Type 1 reports on control design at one point in time. A Type 2 covers operation over a period, typically 3 to 12 months, per Drata.

For a Type 2, TCSA says a test before the period "evidences nothing about operation inside it." An auditor may accept one only in narrow cases, such as a short period with no material change.

So work back from the period's end:

1. Start early enough for the report, fixes and retest to close inside the period. With a 30-day fix window, TCSA says at least 8 to 10 weeks before the end.
2. Fix findings within the window your policy states.
3. Retest, and file the retest letter as evidence.
4. Test again after major changes, such as a new chain or wallet provider.

Licensed too? Your regulator may set its own cadence; see our pentest requirements by regulation.

How Guardian Helps

Guardian does not issue SOC 2 reports; a licensed CPA firm does. Guardian prepares the controls and the evidence the CPA tests.

Its pentests cover web apps, APIs, infrastructure, browser extensions, SDKs and offchain automation, each closed out with a retest.

For fintechs, Guardian assembles audit and pentest outputs and retest status into a trust center that banks, partners and auditors can read.

Regulatory & Compliance tags each artifact with the provisions it evidences, SOC 2 included.

Frequently Asked Questions

Is a penetration test required for a SOC 2 Type 2?

No criterion requires one. But if your controls include a periodic pentest, the auditor tests that control. For a Type 2, plan the test inside the observation period.

Is a vulnerability scan enough for SOC 2?

Scans appear in a CC7.1 point of focus and pentests in a CC4.1 point of focus; neither is mandatory. A scan finds known weaknesses, while a pentest shows what an attacker can reach. Customers often ask for the pentest too.

How often should you pentest for SOC 2?

The criteria set no frequency. Your auditor tests the cadence your controls state, and Drata says many customers demand an annual test. Retest after fixes, and test again after significant changes.

Can an internal team run the SOC 2 pentest?

The criteria do not say. CC4.1 points of focus describe knowledgeable evaluators and separate evaluations that provide objective feedback. An independent tester makes that objectivity easier to show.

Sources

• AICPA: TSP Section 100, 2017 Trust Services Criteria (March 2020 edition, copy hosted by Arpio)
• AICPA and CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• Cloud Security Alliance: SOC 2 Reports and Penetration Tests, by Mike DeKock, MJD Advisors (February 2, 2024)
• Drata: How Much Does a SOC 2 Audit Cost? (March 25, 2026)
• TCSA: SOC 2 and Penetration Testing, What Is Actually Required (last reviewed August 2026)
• Guardian: Penetration Testing
• Guardian: Fintechs
• Guardian: Regulatory & Compliance