SOC 2 Penetration Testing: What Your Auditor Actually Expects
The most common question we hear before a first audit is whether SOC 2 penetration testing is actually required. The honest answer is that the standard never says the words, but your auditor will still expect a test, and skipping it is one of the fastest ways to earn an exception on your report.
This guide explains why penetration testing sits at the center of a SOC 2 audit even though it is never named, when to run the test, and what a report needs to include. For the testing engagement itself, see the VAPT service page.
Does SOC 2 require a penetration test?
Strictly speaking, no. The AICPA Trust Services Criteria, the actual standard behind SOC 2, do not contain the phrase "penetration test." There is no line item that says you must hire someone to try to break in.
What the criteria do require is that you identify vulnerabilities, monitor your systems for security weaknesses, and remediate the issues you find. Common Criteria 7.1, for example, requires that you detect and act on vulnerabilities. Common Criteria 4.1 requires ongoing monitoring of your control environment. A penetration test is the most direct, widely accepted evidence that you are doing those things.
So the requirement is indirect but real. The standard requires an outcome (you find and fix your weaknesses), and a penetration test is the accepted way to prove you meet it. Auditors have converged on it as the expected artifact, which is why nearly every company that passes SOC 2 has one.
Why auditors expect one anyway
Auditors are looking for evidence that your security controls actually work, not just that they exist on paper. A written vulnerability management policy tells them you intend to find weaknesses. A penetration test report tells them you actually looked, and hard.
That distinction matters for the two criteria most tied to testing:
- Detecting vulnerabilities. A penetration test surfaces exploitable weaknesses that automated scans miss, because a human tester chains issues together the way a real attacker would.
- Validating remediation. The test proves your defenses hold up under active attack, not just that a scanner reported "no critical findings."
Without a test, an auditor has to take your vulnerability management program on faith. With one, they have independent evidence. That is why the absence of a recent penetration test so often turns into a noted exception, even though no rule was technically broken.
When to run it: timing and the observation window
Timing is where teams most often trip up, and it depends on which report you are pursuing.
For a SOC 2 Type I report, which attests to your controls at a single point in time, a recent penetration test dated before the report date is generally enough.
For a SOC 2 Type II report, which attests that your controls operated over a period (commonly 6 to 12 months), the test needs to fall inside that observation window. Type II is about demonstrating that controls ran during the period under review, so a penetration test dated before the window opened may not satisfy the auditor. The safe approach is to schedule the test early in the observation window, leaving time to remediate any findings and, if needed, retest before the window closes.
A test run three weeks before your audit, on a window that opened six months ago, is a common and avoidable mistake. Plan the test into the window, not up against the audit deadline.
Vulnerability scans versus penetration tests
Auditors generally expect to see both, and they are not interchangeable.
A vulnerability scan is automated and broad. Tools like the ones in a standard vulnerability management program crawl your systems and report known weaknesses. Scans are cheap, fast, and meant to run regularly, often weekly or monthly, giving you continuous coverage.
A penetration test is manual and deep. A skilled tester attempts to actually exploit weaknesses, chaining together issues that a scanner would report as separate low-severity items. Penetration tests are periodic, hands-on, and validate exploitability rather than just presence.
For SOC 2, the pattern that satisfies auditors is regular scans for breadth plus an annual penetration test for depth. If you want the fuller comparison, we break it down in VAPT vs penetration test.
Internal versus external, and scope
Two scoping questions come up in every SOC 2 penetration test.
Independence. The tester should be independent of the team that built the system. An internal engineer testing their own code lacks the objectivity auditors want, so most companies engage a qualified third-party firm and hand the resulting report to their auditor as evidence.
Scope. At minimum, the test should cover the systems in scope for your SOC 2, typically your production application and its external attack surface. Many programs test both the external perimeter (what an internet attacker sees) and the authenticated application (what a logged-in user or a malicious tenant could reach). For a multi-tenant SaaS platform, testing whether one tenant can reach another tenant's data is one of the highest-value checks you can run.
How often to test
The baseline auditors expect is at least annually, aligned to your audit cycle, plus after any significant change to your systems. A major architecture change, a new product surface, or a migration all warrant a fresh test, because they change your attack surface in ways last year's report did not cover.
High-change environments sometimes move to more frequent testing, and continuous or on-demand testing models are increasingly common. But annual-plus-major-change is the floor, and it is what keeps your SOC 2 evidence current from one audit to the next.
What a good report includes
The deliverable you hand your auditor should include the scope and dates of the test, the methodology used, a list of findings ranked by severity, and, crucially, evidence of remediation for anything significant. An auditor wants to see not just that you found issues, but that you closed them. A test report showing five criticals with no remediation trail is worse than no test at all, because it documents known, unaddressed risk.
For the surrounding program, see the SOC 2 service page and the SOC 2 compliance checklist. For how penetration testing relates to broader vulnerability testing, see VAPT vs penetration test, and for the testing engagement itself, the VAPT service page.
Frequently Asked Questions
Does SOC 2 require a penetration test? Not by name. The Trust Services Criteria never say "penetration test," but they require you to identify and remediate vulnerabilities, and an annual test is the evidence auditors expect for that. Skipping it commonly results in an exception.
How often do you need a penetration test for SOC 2? At least annually, aligned to your audit cycle, and again after any significant system change. For a Type II report the test should fall inside the observation window.
What is the difference between a vulnerability scan and a penetration test for SOC 2? A scan is automated and broad; a penetration test is manual and deep, actually attempting to exploit weaknesses. Auditors generally want both: regular scans plus an annual test.
Does the penetration test need to be inside the SOC 2 observation window? For Type II, effectively yes, since the report attests to controls operating over that period. For Type I, a recent test before the report date is usually enough.
Who can perform a SOC 2 penetration test? An independent, qualified third party. Auditors want testers with recognized credentials and independence from the team that built the systems, which is why most companies use a specialist firm.
Ready to Schedule Your SOC 2 Penetration Test?
ShieldKey Solutions runs SOC 2-ready penetration tests that give your auditor exactly the evidence they expect: independent, scoped to your audit, timed to your observation window, and delivered with a remediation trail. We test the perimeter and the multi-tenant application, then hand you an auditor-ready report.