SOC 2 Penetration Testing: Where It Fits, What Auditors Expect, and How Often to Run It

What SOC 2 penetration testing actually is

SOC 2 is usually the first serious audit a SaaS company faces, and it usually arrives the same way: a customer refuses to sign until you hand over the report.

SOC 2 penetration testing is the testing you do to satisfy that audit. It is a normal penetration test — reconnaissance, exploitation, chaining, a written result — aimed at the questions a SOC 2 auditor will ask. The framework is built on the Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. Your report describes how well you meet the ones in your scope.

Here is the confusion at the heart of it. Nowhere in the criteria does the phrase “penetration test” appear. So a lot of founders conclude SOC 2 penetration testing is optional and skip it. Then the auditor asks how they identify vulnerabilities in their environment, and “we run a scanner sometimes” turns out not to be a convincing answer.

The truth is, SOC 2 penetration testing is expected in practice even though it is not named in the text. It is the cleanest evidence that you actively look for weaknesses, which several criteria require you to do. Skipping it does not make the requirement go away; it just makes the audit harder.

Where SOC 2 actually asks for a test

To defend a scope, it helps to know which criteria a test supports. The common criteria are where SOC 2 penetration testing earns its place.

The monitoring criteria expect you to detect and evaluate security weaknesses. A pentest is direct evidence you did. The risk-assessment criteria expect you to identify and analyse risks to your objectives; findings from a test feed that process with real, ranked risks rather than theoretical ones. The change-management criteria expect that changes do not quietly introduce weaknesses; testing after significant change demonstrates that.

None of these say “you must run SOC 2 penetration testing”. All of them are far easier to satisfy when you have. An auditor who sees a recent test, a remediation log and a retest has little left to question on those criteria. An auditor who sees a scanner report and a shrug has a lot.

Type I vs Type II, and why it changes the cadence

The distinction between the two report types is where SOC 2 penetration testing stops being a single event.

A Type I report describes your controls at a single point in time — design, on a date. A Type II report describes whether those controls operated effectively across a period, usually six to twelve months. Customers almost always want Type II, because Type I only proves you drew the diagram, not that the controls worked.

That period is the catch. If your report covers a year of operation, evidence that you test for vulnerabilities has to span that year too. A single test on day one does not describe how you operated in month nine. This is why SOC 2 penetration testing is a recurring commitment for anyone chasing Type II, and why the cadence question below matters so much.

What a SOC 2 penetration test should cover

Scope is where SOC 2 penetration testing quietly goes wrong, usually by shrinking to fit a budget.

Start from the systems behind your security promises. The application customers log into. The APIs behind it. The cloud infrastructure it runs on. The admin surfaces and internal tools that can reach customer data. If a system touches the data you promise to protect, or can reach something that does, it belongs in scope.

A solid test covers the web application and its authentication, the APIs and their authorisation logic (cross-tenant access is a classic SOC 2 failing), the cloud configuration, and the paths an attacker would chain between them. The point is not to test the flagship app in isolation; it is to test the way an attacker actually moves. Before you draw the boundary, our free security checks guide helps you enumerate what you actually expose.

What auditors actually look for in the report

An auditor never watches the test. They read what it produced, so the report is the deliverable that matters.

They look for a defined scope, so they know what was and was not covered. A methodology, so they know it was more than a scan. Findings with severity, so they can judge risk. Evidence of remediation, so they know you acted. And a retest, so they know the fix held. That last loop — finding, fix, retest — is what separates SOC 2 penetration testing that clears an audit from a test that just documents problems.

This is also why a scanner report alone rarely satisfies. It lists possibilities without proof, and it has no remediation loop attached. A finding that reads “exploited, here is the impact, here is the fix, retested clean” carries the weight an auditor is looking for.

Common findings a SOC 2 penetration test surfaces

It helps to know what SOC 2 penetration testing tends to turn up, because the pattern is remarkably consistent across SaaS companies.

Broken authorisation between tenants is the classic. A multi-tenant SaaS gets the login right and the per-object permission wrong, so user A can read user B’s data by changing an identifier. Auditors care about this one deeply, because confidentiality is a criterion most SOC 2 scopes include, and cross-tenant access is a direct violation of it.

Over-privileged cloud roles come next. A service account with far more access than it needs, a storage bucket readable more widely than intended, a key that unlocks more than one system. SOC 2 penetration testing that reaches the cloud layer surfaces these; a test scoped only to the web application never sees them.

Then there are the unglamorous ones that still fail audits: forgotten subdomains serving old code, admin interfaces reachable from the internet, secrets left in a public artifact. None are exotic. All are the kind of thing an attacker finds in an afternoon, and all are the kind of thing a narrow annual test misses because the forgotten surface was, by definition, forgotten when the scope was drawn.

The value of SOC 2 penetration testing is not just the finding. It is following the finding to its consequence — showing that the cross-tenant bug actually exposes real records, not just that it theoretically could. That impact is what makes a remediation ticket get prioritised instead of parked.

There is a subtler benefit too. A test that chains findings teaches your engineers how an attacker thinks, and that lesson outlasts the audit. The team that watches a low-severity information leak get chained into a full account takeover stops dismissing low-severity findings. Good SOC 2 penetration testing changes how people build, not just what gets fixed this quarter.

How to prepare for a SOC 2 penetration test

A little preparation makes SOC 2 penetration testing faster, cheaper and more useful. Most of it is unglamorous.

First, get your asset inventory straight. You cannot scope a test around systems you have forgotten you run, and the forgotten ones are where the findings hide. Enumerate your real external surface before the test, not during it.

Second, agree the scope against the criteria, not the calendar. Decide which Trust Services Criteria are in your report, then make sure the test covers the systems those criteria depend on. A test scoped to please a deadline rather than the criteria produces evidence that does not quite fit the report.

Third, decide the remediation path in advance. The finding is only half the work; the fix and the retest are what the auditor wants. Know who fixes what and how quickly, so SOC 2 penetration testing does not stall at a list of problems nobody owns.

Fourth, fix the easy things first. There is no point paying for depth on a system that still exposes the basics. Run our free security checks beforehand, close the obvious doors, and let the real test spend its time on the findings that actually need a skilled adversary to reach.

How often to run SOC 2 penetration testing

The common baseline is annual, plus a test after any significant change. For many teams that is the floor an auditor will accept.

But annual is a paperwork cadence, not a security one. If you ship weekly, a once-a-year test describes a system that changed fifty times since. The auditor may accept it; the gap is still real. This is why SOC 2 penetration testing is drifting toward continuous for teams that deploy often — the report should describe the system you run now, not the one you ran last winter.

The pragmatic answer: annual as the documented minimum, a test tied to every significant change, and continuous testing underneath so nothing waits a year to be looked at. The more often you ship, the more the annual-only model undersells your actual security work.

There is a business angle here too. Customers increasingly ask not just for the SOC 2 report but for how recent the testing behind it is. Being able to say your SOC 2 penetration testing is continuous, not annual, is becoming a genuine differentiator in security questionnaires — the kind of answer that shortens a sales cycle instead of stalling it.

The evidence gap the annual model leaves

Picture the SOC 2 penetration testing timeline most companies run. Test in January. Fix through February. File the report. Then eleven months of shipping with no further testing until next January.

For the Type II period, those eleven months are exactly what the report is supposed to cover, and they are undocumented. A new API shipped in April is untested. A subdomain spun up in June is untested. A dependency that picked up a vulnerability in September is untested. The report describes a system that stopped existing weeks after the test.

The truth is, this gap is not a testing-quality problem. The January test may have been excellent. It is a cadence problem, and you cannot fix a cadence problem by testing harder once. You fix it by testing continuously.

What SOC 2 penetration testing does not do for you

Being honest about the limits is what makes the rest credible, so here is the boundary.

SOC 2 penetration testing does not make you compliant on its own. It is one piece of evidence among many — policies, access reviews, monitoring, vendor management and the rest of your control set all sit alongside it. A perfect test with weak policies still fails the audit. Treat the test as the technical proof, not the whole programme.

It also does not certify you as unbreakable. A test describes what was found in a defined scope during a defined effort. Something outside that scope, or something introduced the day after, is not covered. This is precisely why cadence matters more than any single test’s depth: SOC 2 penetration testing that runs once describes one moment, and moments pass.

And it does not fix anything. The finding is a diagnosis. The remediation is the cure, and the retest is the proof the cure worked. Teams that expect the test to improve their security by existing are disappointed; teams that treat it as the start of a fix-and-verify loop get the value. An auditor can tell the difference in about thirty seconds of reading.

None of this is a reason to skip SOC 2 penetration testing. It is a reason to place it correctly: the sharpest technical evidence in a broader compliance programme, most useful when it runs continuously and feeds a remediation loop that actually closes.

How SelfHack AI produces standing SOC 2 evidence

SelfHack AI is an autonomous penetration testing platform, and for SOC 2 penetration testing it changes the cadence problem directly.

Instead of one test in January, it runs the test continuously against your estate — reconnaissance, exploitation, chaining — and keeps a standing record of what was tested, what was found, what was fixed and when. For a Type II period, that record is the evidence the report needs, spanning the whole window rather than a single day inside it.

It also closes the significant-change gap without anyone scheduling anything. A new API or subdomain gets tested because everything does. When the auditor asks how you know a control worked across the period, the answer is a live history, not a nine-month-old PDF.

We are not saying this replaces your auditor or the judgement of a skilled human tester — keep the human engagement for deep, creative work. It replaces the eleven-month gap the annual model leaves. See how the platform stacks up in our AI pentest tools overview, and how the wider picture fits in the compliance penetration testing hub.

Related compliance testing

SOC 2 rarely arrives alone. The same testing capability feeds the other frameworks, because underneath they ask the same question. Most companies that need SOC 2 penetration testing this year will need one or two of the others next year, and building the testing programme once — rather than re-procuring per audit — is what keeps the cost sane.

If you take card payments, PCI DSS penetration testing is stricter and names the test outright. If you handle health data, HIPAA penetration testing ties the test to a risk analysis. If you sell internationally, ISO 27001 penetration testing covers the same ground for a global audience. A single well-run programme can evidence several at once.

FAQ

Is penetration testing required for SOC 2?

Not by name. The Trust Services Criteria never say “penetration test”. But they require you to identify and manage vulnerabilities, and SOC 2 penetration testing is the standard, expected way to evidence that. Most auditors look for one, especially for a Type II report. Confirm the specifics with your auditor.

How much does SOC 2 penetration testing cost?

It varies with scope and depth, and a single annual manual engagement is priced very differently from continuous testing. The more useful question is cost per unit of assurance: a once-a-year test that leaves eleven months undocumented is not cheaper if it leaves you exposed between audits. Scope drives price more than anything else.

Does SOC 2 penetration testing need to be done by a third party?

SOC 2 does not mandate an external tester the way some frameworks lean toward, but independence strengthens the evidence. What matters most to the auditor is a defined methodology, real findings, remediation and retest — produced by something credible and documented, whether that is an external team, an internal one, or a platform.

How long does a SOC 2 penetration test take?

A traditional manual engagement is often one to three weeks depending on scope, plus remediation and retest time. Continuous testing changes the shape of the question: rather than a fixed window, testing runs against the estate on an ongoing basis, so there is no single block to wait out before the evidence exists.

Can one test cover SOC 2 and ISO 27001 together?

Often yes. Both frameworks want evidence that you find, fix and re-verify vulnerabilities. A test scoped to cover both can supply evidence to each, with the report framed for both audiences. The testing is shared; the framing differs. See the compliance hub for how the frameworks overlap.

The verdict

SOC 2 penetration testing is not optional just because the criteria never name it. It is the evidence that you do what the criteria require: look for weaknesses, act on them, and prove it.

The mistake is treating it as a single event before the audit. For a Type II report covering a year, the test has to describe a year, and one January engagement cannot. Continuous testing closes that gap and turns the audit into an export of evidence you already have.

The teams that dread the audit are the ones who left SOC 2 penetration testing to the last month. The teams that treat it as a continuous property of how they build barely notice the audit arrive. That difference is a choice about cadence, not budget.

If you would rather walk into your next SOC 2 audit with standing evidence than a nine-month-old PDF, talk to us.

Sources & methodology: testing methodology references the OWASP Web Security Testing Guide and NIST SP 800-115. SOC 2 requirements are summarised from the AICPA Trust Services Criteria; the authoritative source is the current criteria text and your auditor’s interpretation. General guidance, not legal or audit advice. Only test systems you own or are authorised to test.