The AICPA trust services criteria do not require a penetration test. The words do not appear as a mandate anywhere in the criteria themselves. Yet almost every SOC 2 report you will ever read includes a pen test control, and almost every auditor will ask for the report. Understanding why penetration testing for SOC 2 became a de facto expectation is the fastest way to work out what you actually need to buy.
The reason is that the criteria are written as outcomes, not as a shopping list of activities. They ask whether you identify vulnerabilities in your environment, whether you evaluate your controls periodically through ongoing and separate evaluations, and whether you act on what you find. A penetration test is the most common and most defensible way organisations answer those questions, so it becomes the expected evidence by convention rather than by rule. Your auditor is not enforcing a requirement to pen test. Your auditor is asking how you meet a criterion, and “we run a scanner and nothing else” is a thin answer for most service organisations.
What the criteria actually ask for
Two areas do most of the work here. One concerns monitoring — whether management performs evaluations to determine that controls are present and functioning, including evaluations separate from day-to-day operations. The other concerns risk identification and detection — whether you identify vulnerabilities and configuration changes that could result in a security incident, and whether you respond to what surfaces.
Neither names a tool or a technique. What that means practically is that your control language is yours to write. If your description says “an independent penetration test is performed annually and findings are remediated according to defined severity timelines”, the auditor will test exactly that: did the test happen, was it in the period, were findings tracked, were they closed within your own stated timelines. If you write a weaker control, you get tested against the weaker control — but your customers read the description too, and they will notice.
This is the part founders miss. The auditor tests you against your own commitment. Writing an ambitious testing control and missing it produces exceptions. Writing an honest one and hitting it produces a clean result.
What a vulnerability scan is good at
A vulnerability scan is automated. A tool compares what it can observe about your hosts, containers, dependencies and cloud configuration against a database of known issues and misconfigurations, then produces a ranked list.
Its strengths are coverage and cadence. It can look at every host in your estate, every week, or continuously in the case of agent-based and pipeline-integrated scanning. It catches the unglamorous majority of real-world risk: an unpatched library with a known exploit, a database port open to the internet, an object store made public, an ancient TLS configuration, a base image three years out of date.
Its limits follow from the same design. It knows what it has been told to look for. It reports individual findings without chaining them. It produces false positives, sometimes in volume, and it cannot tell you whether a medium-severity finding on one host happens to sit next to a credential that turns it into a full compromise. Authenticated scans see far more than unauthenticated ones, which is worth checking — plenty of teams believe they have scan coverage when they are scanning the outside of a locked door.
What a penetration test finds that a scanner cannot
A penetration test is a person with a goal and a time box. They are not enumerating known issues; they are trying to achieve something — reach another tenant’s data, escalate from a read-only API token to an admin action, get from the marketing site into the production VPC.
That framing surfaces a category of problem scanners structurally cannot find:
- Broken authorisation logic. An endpoint that checks you are logged in but not that the record belongs to you. No scanner has a signature for your object model.
- Tenant isolation failures. For multi-tenant SaaS this is the single most commercially damaging class of finding, and it is the one enterprise buyers ask about by name.
- Chained weaknesses. Three low-severity findings that individually merit a shrug and together produce remote code execution.
- Business logic abuse. Negative quantities, race conditions in a workflow, replayable tokens, a password reset flow that can be walked backwards.
- Assumptions nobody wrote down. An internal service that trusts any request from inside the network, on the basis that nothing untrusted is inside the network.
The trade-off is the mirror image of the scanner’s. A pen test is point-in-time, it covers what was in scope, and it depends on the skill of the tester and the quality of the scoping conversation. It tells you nothing about the state of your estate three months later.
Side by side
| Vulnerability scan | Penetration test | |
|---|---|---|
| Performed by | Automated tooling | Skilled humans, tool-assisted |
| Frequency | Continuous, weekly or monthly | Typically annually, or on major change |
| Breadth | Every asset in scope | A defined target set |
| Depth | Known issues, no chaining | Goal-directed, chains findings |
| Finds logic flaws | No | Yes |
| Output | Ranked finding list | Narrative report with attack paths and evidence |
| Answers | “What known weaknesses exist right now?” | “Can someone actually get in, and how far?” |
Neither substitutes for the other, and an auditor who sees only one will ask about the other.
What your auditor will actually ask for
Expect these requests, in roughly this order.
The pen test report itself, dated inside the observation period, with scope clearly stated. Scope matters: a test of your marketing website does not evidence testing of the platform holding customer data, and an auditor reading the scope section will say so.
Evidence of independence. Whether an internal team can perform it depends on the facts and on your auditor’s judgement, but a test performed by the same engineers who built the system is a harder argument. Many organisations use an external firm partly to remove the question.
Scan configuration and cadence evidence — not one screenshot, but proof the scans ran across the period, covering the systems in your description.
Remediation tracking. This is where exceptions come from, more often than from the testing itself. If your policy says criticals are remediated in fifteen days and your tracker shows a critical open for ninety with no documented risk acceptance, that is a finding regardless of how good your pen test was.
Retest or closure evidence for high-severity findings. “We fixed it” in an email is weaker than a retest note or a linked ticket with the change.
Scoping without overbuying
A few honest observations on scope. Test the system in your SOC 2 description, not your whole company. If the report covers your production platform, an external network test plus an authenticated application and API test usually addresses what buyers and auditors care about. Cloud configuration review is often better value than another network sweep, since misconfiguration is where a lot of real exposure sits.
Grey-box testing — where you give the tester credentials and some architecture context — generally produces more findings per day than black-box, because the tester spends their time on your logic rather than on reconnaissance. Social engineering and physical testing are legitimate exercises but are rarely what a SOC 2 reader is looking for, and they can be deferred without weakening the report.
Timing is worth planning. Run the test early enough in the observation window that you can remediate and, where needed, retest before the period closes. A high-severity finding discovered two weeks before period end and still open at issuance is an awkward conversation you can simply avoid.
What to do next
Pull your last pen test report and read only the scope section. Then read the system description you plan to put in your SOC 2. If the two do not describe the same environment, fix that before fieldwork rather than during it.
Then open your vulnerability tracker and filter for anything past your own stated remediation timeline. Whatever is on that list is what your auditor will sample, and closing it — or documenting a formal risk acceptance with an owner and a date — is the highest-value hour you will spend this month.
Assurion performs penetration testing as well as SOC examinations, and we can scope a test against the report you are actually trying to produce.