SOC 2 is the compliance requirement most US technology companies encounter first, usually because an enterprise customer asked for a report during procurement. It is also the one whose testing expectations are least clearly documented, because the framework does not state them.
No Trust Services Criterion says "penetration testing". Auditors expect it anyway, and understanding why makes the requirement considerably easier to satisfy.
Why an Unnamed Requirement Is Still a Requirement
SOC 2 is built on criteria rather than controls. The AICPA sets out what must be achieved; you decide how, describe the controls you implemented, and an auditor forms an opinion on whether they were suitably designed and, for Type II, whether they operated effectively across the period.
That structure means nothing is prescribed at the level of "run this test". What it does mean is that you must produce evidence for each criterion you are in scope for, and some criteria are hard to evidence any other way.
CC7.1 requires the entity to use detection and monitoring procedures to identify changes to configurations that introduce vulnerabilities, and to identify susceptibility to newly discovered vulnerabilities. Scanning addresses part of this. Establishing whether an identified weakness is actually exploitable in your environment is what testing adds.
CC4.1 requires ongoing evaluations to determine whether components of internal control are present and functioning. An independent technical assessment is among the strongest evidence available for this criterion, and it is the one auditors most often point at.
CC3.2 on risk identification, CC6.1 on logical access, and CC7.2 on monitoring for anomalies are all supported by a well-scoped test, particularly one that exercises access controls directly.
The practical position is that an auditor cannot require a penetration test, and will ask how you evidenced CC7.1 and CC4.1. Organizations that have a good answer without testing exist. They are uncommon.
What Auditors Actually Look For
Four things, in rough order of how often they cause problems.
Independence. Testing performed by people organizationally separate from those who build and run the systems. An internal team can satisfy this if the separation is real.
Scope that matches the system description. Your SOC 2 report contains a system description defining the boundary. Testing that covers substantially less than that boundary invites the obvious question. This is the most common scoping error and it is entirely avoidable.
Timing inside the observation period. For Type II, the auditor assesses a period. A test conducted before the period started evidences the previous year.
Evidence of what happened next. This is where organizations most often fall short. A report identifying findings, with no tracking, no owners and no remediation record, evidences a control environment that notices problems and does not respond. That is a worse position than having found nothing, because it is documented.
Timing It Properly
Test early in the observation period.
The reasoning is straightforward. A finding identified in month one, remediated in month two and verified in month three appears in your evidence as a control environment working exactly as intended: an issue was found, owned, fixed and confirmed. The same finding identified three weeks before the period closes appears as an open issue.
Organizations frequently schedule testing late because the audit deadline is what prompts the purchase. Reversing that sequence costs nothing and materially improves how the evidence reads.
Handling Findings
Every test produces findings. The expectation is not a clean report; it is a demonstrable process.
Track findings in whatever risk register or ticketing system your control narrative describes, with an owner, a severity and a target date. Remediate what warrants remediation and record the verification. Where you accept a risk instead, document the rationale and who accepted it, at an appropriate level of authority.
An accepted risk with a written justification is a defensible position and auditors see it regularly. An untracked high-severity finding is not.
Scoping Against the System Description
Scope the test to the system boundary in your description, then check whether that boundary is honest.
Two things commonly sit outside a system description and inside the actual risk: internal administrative tooling used by support staff, which frequently holds broader access to customer data than the product does, and the deployment pipeline, which typically carries more privilege than any human account. Both are worth testing whether or not the description mentions them, and if they materially affect the security of the described system, the description may need revisiting.
For a SaaS product specifically, application and API testing covering authorization across multiple tenants is the part that answers the question your enterprise customers are actually asking, which is whether their data is separated from another customer's.
Beyond the Audit
SOC 2 is a floor. It establishes that you have a control environment and that it operates, which is genuinely worth something and is not the same as being secure.
The organizations that get the most from this are the ones that scope testing to the risk rather than to the criteria, and then map the findings back for the auditor. That produces one engagement satisfying both purposes, and a report that tells you something you did not already know.
To discuss a penetration test that supports your SOC 2, get in touch.
Frequently asked questions
Does SOC 2 require a penetration test?
Not explicitly. No Trust Services Criterion names penetration testing, and an auditor cannot cite a clause requiring it. What CC7.1 does require is the detection and monitoring of configuration changes and vulnerabilities, and CC4.1 requires evaluation of whether controls operate effectively. Most auditors treat an annual penetration test as the clearest available evidence for both, and most SOC 2 reports include one.
Which Trust Services Criteria does penetration testing address?
Principally CC7.1, which covers vulnerability detection, and CC4.1, which covers ongoing evaluation of control effectiveness. It also supports CC3.2 on risk identification, CC6.1 on logical access controls and CC7.2 on monitoring for anomalies. A report that maps findings to these criteria saves considerable effort during the audit.
Type I or Type II, and does it change the testing?
Type I assesses whether controls are suitably designed at a point in time. Type II assesses whether they operated effectively across a period, usually three to twelve months. Type II is what customers actually want and is where testing evidence matters most, because the auditor is looking for controls that ran throughout the period rather than existed on one date.
When should we test relative to our audit window?
Early in the observation period, so there is time to remediate and retest before it closes. Testing in the final weeks leaves open findings visible to the auditor with no evidence of remediation, which reads considerably worse than a finding that was found, fixed and verified inside the window.
Will unresolved findings fail our SOC 2?
Findings themselves rarely cause a qualified opinion. What causes problems is findings with no documented risk decision, no owner and no remediation timeline, because that evidences a control environment that identifies issues and does not act on them. A tracked, prioritized finding with an accepted risk and a stated rationale is a normal and defensible position.