SOC 2 does not explicitly require a penetration test — the Trust Services Criteria never use the phrase. In practice, though, nearly every auditor expects to see one as evidence for the vulnerability management and monitoring criteria, and the enterprise customers who read your SOC 2 report will look for it too. Here is what the framework actually says, how Type I and Type II differ, and exactly what auditors ask for.
What SOC 2 actually says about penetration testing
SOC 2 audits assess your controls against the Trust Services Criteria. Two criteria do most of the work here:
- CC4.1 expects the organisation to evaluate whether its controls are present and functioning, through ongoing or separate evaluations — and an independent penetration test is a textbook separate evaluation.
- CC7.1 expects you to monitor for and detect new vulnerabilities in your systems.
The criteria are outcome-based: they describe what your control environment must achieve, not which products or services to buy. An independent penetration test has simply become the accepted way to demonstrate both — it shows that a qualified third party attempted to defeat your controls and that you acted on what they found. Turning up to an audit without one means arguing that your alternative evidence is equivalent, which few auditors or customers accept.
Type I vs Type II — and why it changes your testing
- A Type I report assesses the design of your controls at a single point in time. For a first audit, a recent penetration test report demonstrates that your vulnerability management control exists and is designed sensibly.
- A Type II report assesses whether controls operated effectively over an observation window, typically three to twelve months. Here the pentest needs to sit inside (or reasonably near) that window, and — crucially — the auditor will want evidence that you triaged and remediated the findings, because remediation is the control operating.
Most companies start with Type I to unblock early enterprise deals, then move to an annual Type II cycle. Once you are on Type II, an annual penetration test aligned to the audit window becomes the rhythm.
What auditors actually ask for
Expect requests along these lines:
- The report itself, from a qualified, independent tester, with a described methodology — not just raw scanner output. A vulnerability scan is not a penetration test; the difference matters to auditors, and we break it down in penetration test vs vulnerability scan.
- Scope that matches your system description. If your SOC 2 report covers your SaaS platform and its API, the test should cover the web application and API, plus the cloud infrastructure that hosts them.
- A date inside the audit period, or close enough to be clearly relevant.
- Evidence of remediation — tickets, fix confirmation, or best of all a retest report confirming issues were closed.
- Cadence — annual testing, plus testing after significant changes, is the expected norm.
Scoping and timing a SOC 2 pentest
Scope the test to the system your report describes: the production platform, its APIs, and the cloud environment underneath it. Time it early enough in the observation window that you can remediate and retest before fieldwork begins — a critical finding surfacing two weeks before the audit is avoidable stress.
On cost: our web application and API tests run AU$8,000–18,000 (5–10 days) and cloud reviews AU$6,000–14,000 (4–8 days), with a fixed quote within one business day of a free scoping call. We retest fixed issues free within 90 days, and the retest letter slots neatly into your auditor's evidence request.
Common pitfalls to avoid
A few mistakes come up repeatedly in SOC 2 preparation:
- Testing the wrong thing. A pentest of your marketing website does not support a report about your SaaS platform. Match the scope to the system description, or the evidence will not hold.
- Submitting scanner output as a pentest. Auditors have seen enough real reports to spot the difference immediately, and it undermines confidence in your other answers.
- Skipping remediation evidence. An unremediated critical sitting in a six-month-old report is worse than no report — it shows the vulnerability management control found something and then failed to operate.
- Leaving the test until the last minute. Testers book out weeks ahead, and remediation takes longer than teams expect. Build the schedule backwards from your audit fieldwork date.
Handled early, none of these are hard problems — they are calendar problems.
FAQ
Does SOC 2 require a penetration test every year?
Not in writing — but for Type II, auditors expect vulnerability management to operate throughout each annual period, and an annual pentest is the accepted evidence. Treat it as effectively required.
Can we substitute a vulnerability scan?
Usually not on its own. Scans are automated and shallow; auditors and enterprise customers distinguish clearly between scanning and manual penetration testing, and many security reviews explicitly ask for both.
When should the pentest happen relative to the audit?
Inside the observation window, with enough runway to remediate and retest before the auditor's fieldwork — for most companies, two to four months before the period ends works well.
Preparing for a SOC 2 audit? Get in touch and we will scope a test that matches your system description and audit timeline, with a fixed quote within one business day.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.