Do you need a penetration test for SOC 2?

Is a penetration test required for SOC 2?

No, not strictly. The criteria behind a SOC 2 report do not say “perform a penetration test”. In practice, most auditors expect one, because it is the usual evidence for two of the criteria, CC4.1 and CC7.1.

The difference matters when you plan. If you treat the pentest as optional, you may find out during fieldwork that your auditor wants it. If you treat it as a box to tick, you may buy a test that does not answer what the auditor asks.

What do the SOC 2 criteria actually say?

SOC 2 reports are written against the AICPA’s Trust Services Criteria (the 2017 criteria, with points of focus revised in 2022). Each criterion comes with points of focus: examples of what a control could address. The criteria are what your auditor tests; the points of focus are illustrations, not requirements.

Two criteria are relevant here.

CC4.1 asks that the organisation selects, develops and performs ongoing or separate evaluations to check that its internal controls are present and functioning. One of its points of focus says management uses different types of evaluation, and names penetration testing as one of them, alongside independent certifications such as ISO and internal audit assessments.

CC7.1 asks that the organisation uses detection and monitoring to find configuration changes that introduce vulnerabilities, and newly discovered vulnerabilities. Its points of focus include conducting vulnerability scans.

Penetration testing appears as an example under CC4.1. CC7.1 points to vulnerability scanning, not pentesting.

Why do auditors ask for a pentest anyway?

Because it is the clearest independent evidence that your controls hold up against someone trying to break them. A policy shows what you intend; a pentest shows what an outsider could actually do. For a SaaS company, where the product is the system in scope, auditors commonly treat an annual pentest as the expected evidence for CC4.1, and your enterprise customers will often ask for the same report in their security reviews.

You can meet CC4.1 with other evaluations in principle. In practice, a pentest is the evidence auditors and customers recognise most easily.

Does a vulnerability scan count instead?

Not for the same purpose. Regular vulnerability scanning is how you answer CC7.1, and auditors may ask for scanner output separately from a pentest report. A scan finds known weaknesses; a pentest shows which of them can be exploited and what an attacker could reach. Plan for both.

When should the pentest happen for a Type 2 report?

Inside the observation period. A Type 2 report covers how your controls operated over a period, often several months. A test dated before the period started is weaker evidence that the controls operated during it. Plan the test, and the retest of what it finds, so both fall inside the window.

What should a SOC 2 pentest report include?

A report is useful to an auditor when it can be matched to your SOC 2 scope. Make sure it has:

1. A scope that matches the systems in your SOC 2 system description
2. The dates of testing
3. The method, including what was tested manually
4. Each finding with its severity, evidence and a fix
5. The status of each finding after your fixes, from a retest

An executive summary that an auditor or customer can file, separate from the technical detail, saves a round of questions.

How Cyphlon runs a pentest for SOC 2

Our compliance pentest is scoped to the systems your auditor will look at. AI agents cover the breadth, our engineers exploit and chain the findings that matter, and you receive a technical report, an executive summary written for auditors and buyers, and a retest of what you fix. If your customers want evidence through the year, not once, recurring pentesting keeps the report current.

This guide explains the criteria; it is not audit advice. Your auditor decides what evidence they accept.