Is a penetration test required for SOC 2?

No, SOC 2 does not require a penetration test: the Trust Services Criteria name it as one example of an evaluation under CC4.1. An auditor may accept vulnerability scans instead, though the enterprise questionnaires I have answered asked for a penetration test report.

Does SOC 2 Type I require a penetration test?

No, neither SOC 2 Type I nor Type II requires a penetration test, because both use the same Trust Services Criteria. Run one yearly before either type. A Type II report covers a period, so date the test inside that period.

How often should you run a penetration test for SOC 2?

Run a penetration test for SOC 2 once a year and after a significant change, such as a new login method. SOC 2 sets no frequency; a yearly test follows the audit cycle.

Is a vulnerability scan enough for SOC 2?

A vulnerability scan can satisfy a SOC 2 auditor, because the CC7.1 point of focus names scans. A scan does not find authorization flaws between tenants, so add access tests in CI.

Does SOC 2 require penetration testing?

Answer

Run a penetration test of your application before your first SOC 2 audit and every year after, although the SOC 2 criteria name it only as one example of an evaluation under CC4.1, and test tenant access checks in CI on every change.

Verdict on the code under testYes

Why

Blast radiussafety-or-legal
Change frequencyregularly
Detectabilitynever
Reversibilityimpossible
Test costheavy

Yes, run a penetration test every year, although SOC 2 does not require it: the Trust Services Criteria name it only as one example of evaluation under CC4.1. The typical case is a multi-tenant SaaS application before its first SOC 2 Type II audit. Blast radius is safety-or-legal, because a flaw exposes customer data, and Change frequency is regularly, because endpoints and roles change about monthly. Detectability is never, because requests for another tenant's records look like normal traffic, and Reversibility is impossible, because exposed data cannot be recalled. Test cost is heavy, because an outside tester needs days and a staging copy, so rule R2 gives Test mandatory.

When the decision changes
When	Decision	Why
The system in the audit scope has no customer data, accounts or forms, such as a static status page deployed from the repository	Do not commission a penetration test; keep the system in the vulnerability scan	Blast radius falls to users, Detectability to same-day and Reversibility to trivial, because a redeploy restores a defaced page
The product holds only public data that staff edit in the application, and the threat is an attacker who edits it	Test it differently: alert on unusual edit volume, and keep backups	Blast radius falls to users, Detectability to eventually and Reversibility to with-effort, because a restore undoes an edit
The product has no customers yet, holds only invented test data, and runs on a staging server the team shares	Test it differently: scan staging with OWASP ZAP on each deploy until real customer data arrives	Blast radius falls to internal and Reversibility to trivial, because no real data exists to leak
The flaw is a known kind, such as a user of one tenant reading another tenant's record by ID	Test mandatory: an integration test in CI for each endpoint that returns tenant data	Test cost falls to moderate, and Blast radius stays safety-or-legal
The system stores, processes or transmits card numbers	Test mandatory: PCI DSS requirement 11.4 requires penetration tests at least every 12 months and after significant changes	Detectability moves to eventually, because card networks trace fraud back to the merchant; Blast radius stays safety-or-legal, and PCI DSS makes the test required evidence, which the framework's limits put first

What breaks if you don't test

An export endpoint checks that the user is logged in, but not which tenant owns the record. A customer who changes the ID in the URL downloads another customer's data, and the logs show ordinary 200 responses. The first sign may be a researcher's email months later.

What you lose if you over-test

A penetration test after every weekly release costs several tester days and reports on code already replaced. An automated scan sold as a penetration test misses authorization flaws, because a scanner does not know which tenant owns which record.

How to test

In CI, test each endpoint that returns tenant data with users of two tenants, and assert that the other tenant gets a 404. The OWASP API Security Top 10 ranks this flaw first, as broken object level authorization.
Scan dependencies and the running application on a schedule and after significant changes, as the CC7.1 point of focus describes.
Once a year, have someone who did not write the code test the application as each role in two test tenants, plus the cloud account. Ask for a method based on the OWASP Web Security Testing Guide and a retest of each fix.
Schedule the test inside the audit period, and keep the report, a ticket per finding and the retest result.

Procedure and references

When the answer changes

The system in scope holds no customer data.
The product has no customers yet.
The system handles card numbers, or a contract names a test date.

Real incident + Code example

The export anyone could download

On a B2B scheduling product I worked on, our first SOC 2 Type II audit passed without a penetration test; the auditor accepted quarterly scans for CC4.1. Two months later a prospect asked for a penetration test report. The tester found that the CSV export took a numeric report ID and checked only the login, so any customer could download any other customer's export. Our tests used one tenant. The fix took an hour, and this test now runs for every endpoint that takes an ID:

import request from "supertest";
import { expect, it } from "vitest";
import { app } from "../src/app";
import { createTenant, tokenFor } from "./fixtures";

it("serves an export only to the tenant that owns it", async () => {
  const acme = await createTenant("acme");
  const globex = await createTenant("globex");
  const report = await acme.createReport({ rows: 3 });
  const url = `/api/reports/${report.id}/export.csv`;

  const own = await request(app).get(url).auth(await tokenFor(acme.admin), { type: "bearer" });
  expect(own.status).toBe(200);
  expect(own.text).toContain(report.firstRow.email);

  const other = await request(app).get(url).auth(await tokenFor(globex.admin), { type: "bearer" });
  expect(other.status).toBe(404);
  expect(other.text).not.toContain(report.firstRow.email);
});

The owner's request must return the row's email, so an endpoint broken for everyone fails the test too.

Sources

Does HIPAA require penetration testing?Code under test: Yes
Does GDPR require penetration testing?Code under test: Yes
Should I test API endpoints?Yes
Should I test CRUD operations?Yes
Should I test input validation?Yes

FAQ

Is a penetration test required for SOC 2?: No, SOC 2 does not require a penetration test: the Trust Services Criteria name it as one example of an evaluation under CC4.1. An auditor may accept vulnerability scans instead, though the enterprise questionnaires I have answered asked for a penetration test report.
Does SOC 2 Type I require a penetration test?: No, neither SOC 2 Type I nor Type II requires a penetration test, because both use the same Trust Services Criteria. Run one yearly before either type. A Type II report covers a period, so date the test inside that period.
How often should you run a penetration test for SOC 2?: Run a penetration test for SOC 2 once a year and after a significant change, such as a new login method. SOC 2 sets no frequency; a yearly test follows the audit cycle.
Is a vulnerability scan enough for SOC 2?: A vulnerability scan can satisfy a SOC 2 auditor, because the CC7.1 point of focus names scans. A scan does not find authorization flaws between tenants, so add access tests in CI.