Does SOC 2 Require a Penetration Test? What Auditors Expect

No. SOC 2 does not require a penetration test. A penetration test is not required to meet the Trust Services Criteria (Linford & Co), and the criteria name penetration testing only as one example of the evaluations a company can use to monitor its controls (Linford & Co).

In practice, most teams run one anyway. Penetration testing is not explicitly required, but it is strongly recommended for SOC 2, and it should happen at least once a year and after significant changes (Baker Tilly). Enterprise buyers also ask for the summary of your latest test during security review, whether or not your auditor does.

So the useful question is not whether a test is required, but what it does for your audit and your deals, and how to get one worth paying for. This guide covers what the criteria say, why auditors and buyers ask, how to scope and schedule a test, how it differs from a vulnerability scan, and how to turn the findings into evidence.

The Trust Services Criteria describe outcomes, and each criterion comes with points of focus: examples of how a company might meet it, not requirements.

Penetration testing appears under CC4.1, the monitoring criterion, which asks the company to select, develop, and perform ongoing or separate evaluations to check that its controls are present and working. Its point of focus on different types of evaluations lists vulnerability scans, security assessments, penetration testing, and third-party assessments as examples, chosen to fit the company's objectives (Linford & Co).

Vulnerability scanning sits closer to an expectation. CC7.1 covers detecting new vulnerabilities and configuration changes, and scanning is one of its points of focus (Linford & Co). Expect your auditor to look for regular scans and a record of fixing what they find.

Risk assessment (CC3.2) ties the two together. If your risk assessment names attacks on your application as a significant risk, as it will for most software companies, the auditor will ask how you test your defenses against them. A penetration test is the clearest answer, though not the only acceptable one.

A penetration test answers a question no policy can: can an outsider actually get in? That makes it strong evidence for several controls at once, from access control to monitoring to change management, and it gives the auditor a view of your security that you did not write yourself.

Buyers ask for a different reason. Their security team has to decide whether to trust your product with their data, and the executive summary of a recent test, with the critical and high findings fixed, is quick to read and easy to compare across vendors. If you do not have one, expect a follow-up question in the security questionnaire.

Some auditors treat a missing test as a gap in how you monitor your controls, especially for a product exposed to the internet. Ask your auditor at the planning stage what they expect. It is far easier to schedule a test into your readiness work than to scramble for one at the end of your observation window.

Scope the test to the system your SOC 2 report covers: the customer-facing application, its APIs, and the cloud infrastructure behind them. Authenticated testing, where the tester logs in as a normal user, finds the problems that matter most for a product shared by many customers, such as one customer reaching another customer's data.

Run it at least once a year and after significant changes, such as a new product, a major change to your architecture, or a move to a new cloud provider (Baker Tilly). Time the annual test so it falls inside your observation window, where the auditor can use it.

Choose a tester who is independent of the people who built and run the system. That can be an outside firm or a testing service your auditor accepts. Ask for a written methodology. NIST Special Publication 800-115, the federal technical guide to information security testing and assessment, describes how to plan and run tests such as penetration testing and vulnerability scanning (NIST).

Costs vary widely with scope and with who runs the test. The SOC 2 cost guide compares traditional engagements with newer agentic tests.

The two are often confused, and auditors treat them differently.

A vulnerability scan is automated. A tool checks your systems against a database of known weaknesses, such as outdated software or a misconfigured server, and produces a list ranked by severity. Scans are cheap and fast, so you run them often, monthly or continuously. They find known problems, not new ones.

A penetration test is an attempt to break in. A tester, a person or an automated agent, chains weaknesses together the way an attacker would: a leaked credential, a missing permission check, an exposed admin page. It finds problems a scanner cannot see, especially flaws in your own application's logic, and it shows what an attacker could reach.

For SOC 2, the scan supports your vulnerability management controls under CC7.1, and the test supports your monitoring and risk controls. Most teams need both. For a developer tools company with a large API surface, the penetration test is where most of the useful findings come from.

A penetration test helps your audit only if you act on it. Auditors look at what you did with the findings, not just at whether a test happened.

Open a ticket for every finding, with a severity and an owner. Fix critical and high findings within the deadlines your vulnerability management policy sets, and record each fix. Ask the tester to retest the fixed findings and confirm they are closed. Accept a low finding only with a written reason that management signs off.

Keep four things together for the auditor: the full report, the executive summary, the remediation tickets, and the retest result. Share only the executive summary with buyers, under a non-disclosure agreement, and keep the full report internal, because it is a map of how to attack you.

Finally, feed the findings back into your risk assessment. A pattern, such as several access control flaws, is a sign that a control needs strengthening, and fixing the pattern is better evidence than fixing a single bug.