Does SOC 2 require penetration testing?

SOC 2 does not require a penetration test. The AICPA Trust Services Criteria (TSC) set objectives for a service organization. They do not list mandatory technical tests. A pentest is one way to produce evidence for some of those objectives.

Many companies still buy a pentest for their audit. This page gives the criteria text, what auditors commonly ask for, and what to settle before you scope a test.

What does the SOC 2 text say about penetration testing?#

The word appears once in the 2017 criteria, in an example. In the 2017 TSC (March 2020 update of TSP section 100), the additional point of focus "Considers Different Types of Ongoing and Separate Evaluations" under CC4.1 reads:

"Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments."

Two other passages limit how you read that sentence:

• The criteria state that "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." Points of focus are examples. They are not a checklist.
• CC7.1 says 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 point of focus "Conducts Vulnerability Scans" names scans "on a periodic basis and after any significant change in the environment". It does not name pentests.

AICPA published a revision of the points of focus in 2022. As of November 2026 we quote the 2017 text above and name the edition. Read the 2022 file (free AICPA account) for the current wording.

Why do auditors and customers still ask for a pentest?#

Auditors choose their own evidence standard. A pentest report is easy to read and shows independent testing of a real system, so many auditors and many customers ask for one.

A CPA firm, Linford & Co, states that a pentest "is not required" because the AICPA criteria do not provide the specific controls. Compliance platforms still collect pentest evidence. Vanta describes findings with severity, steps to reproduce and remediation advice, and says a retest can confirm a fix. These are vendor practices, not AICPA rules.

The accurate wording is "many auditors expect it". "SOC 2 requires it" is wrong.

Which criteria do teams map a pentest to?#

Teams map a pentest to the criteria below. The mapping is a working assumption until your auditor agrees to it.

Confirm each row with your auditor. Do not copy this table into your control narrative without that step.

What should you agree with your auditor before the test?#

Ask five questions before you scope. The answers decide what the report must show.

1. Is a pentest in scope as evidence for our controls? Get the answer for your report type (Type I or Type II).
2. What must the scope cover? Production, staging, the web app, the API, internal systems? Auditors often care about the systems in your system description.
3. Who may perform the test? Some auditors want an independent third party. Some accept an internal team. Ask.
4. What timing do they want? For a Type II period, a test early in the period lets the fix and retest fall inside it. Confirm the dates.
5. What report form do they accept? Full report, executive summary, or a letter. See what a pentest attestation letter contains and its limits.

Put the answers in an email thread and keep it with your audit evidence.

What should the report show?#

No SOC 2 text defines a pentest report format. Auditors and platforms usually look for the same basic items:

• Dates of testing and the tested environment.
• Scope: hosts, apps, APIs, roles tested.
• Method and tester independence.
• Findings with severity, evidence and fix guidance.
• Fix status, and a retest result if you fixed findings.

Our guide on how to read a penetration testing report explains each section. Audit evidence usually also includes the fix tickets and the retest, as covered in after the pentest: remediation and retest.

How often should you test for SOC 2?#

The criteria set no interval. PCI DSS sets one (at least every 12 months), and some SOC 2 programs copy it. Customers may also set their own rule in a contract or questionnaire. See how often should you pentest for the trigger list.

Many teams test once per audit period and again after large changes to authentication, authorization or data handling. Check this against what your auditor and customers ask.

How do Type I and Type II reports change the plan?#

A Type I report looks at the design of controls on one date. A Type II report tests how the controls operated over a period, often six to twelve months. The criteria are the same, but the evidence differs.

For a Type I report, a recent pentest report is a point-in-time proof that you test. For a Type II report, the auditor looks for proof across the period. That can mean one test plus its fixes and retest, or several tests after major releases. Ask which your auditor expects.

A simple plan for a first Type II period:

1. Test early, so findings and fixes fall inside the period.
2. Track each finding as a ticket with an owner and a date.
3. Retest the fixed findings and keep the result.
4. Test again after a large change, such as a new login system or a new tenant model.

What are the common mistakes?#

These mistakes come up often:

• Buying a scan and calling it a pentest. Scans and pentests are different activities. Name them correctly in your evidence.
• Testing the wrong environment. A test of a staging copy with different settings may not match the system in your description.
• Skipping the retest. A report with open high findings and no fix record leaves the auditor with questions.
• Late timing. A test in the last week of the period leaves no time to fix and verify.
• Over-claiming. Writing "SOC 2 compliant pentest" on a report. No such label exists in the criteria.

Where can I read about your SOC 2 testing service?#

See SOC 2 penetration testing for our service. Excession Labs does not promise that any auditor will accept a report, so ask your auditor first.

Questions to take to your auditor#

• Does our system description name penetration testing as a control?
• Which criteria will this report support?
• Do you accept a summary or letter, or do you need the full report?
• Must all high findings be fixed and retested before the period ends?
• Does a vulnerability scan alone meet your evidence need for CC7.1?