SOC 2 has become the default security attestation for software companies selling into the United States and, increasingly, to enterprise customers in Australia. It is not a certification but an auditor's report on whether your controls meet the AICPA Trust Services Criteria, either at a point in time (Type I) or over a period (Type II). Somewhere in the first conversation with an auditor or a compliance platform, the question arrives: do we need a penetration test?
The short answer is that the criteria do not use the words, your auditor will expect one anyway, and getting the timing wrong is the most common way to pay for a test that does not count. This guide covers which criteria a pentest supports, how to time it for Type I and Type II reports, what scope auditors expect from a SaaS business, and exactly what to hand over as evidence.
Is a penetration test required for SOC 2?
The Trust Services Criteria are written as outcomes, not procedures. Two of the Common Criteria are where penetration testing lives:
- CC4.1 requires ongoing and separate evaluations to determine whether controls are present and functioning. An independent pentest is the archetypal separate evaluation of technical controls.
- CC7.1 requires detection and monitoring procedures to identify new vulnerabilities, including changes to configurations that introduce them. Vulnerability scanning covers the continuous side; penetration testing covers the depth that scanning cannot reach.
Because the criteria are outcome-based, an auditor can in theory accept other evidence. In practice, nearly every SOC 2 auditor expects an annual third-party penetration test for any company with internet-facing software, and most compliance automation platforms list it as a standard control. Treat it as required, and treat the question as when and how rather than whether.
Type I versus Type II: timing is everything
A Type I report describes your controls as of a single date. The pentest needs to be completed before that date, with the report available to the auditor. Simple.
A Type II report covers an observation period, usually three to twelve months, during which the auditor samples evidence to confirm controls operated throughout. The pentest, and the remediation that follows, need to happen inside that window. A test dated two months before the period starts is a historical document; it shows the control operated last year, not during the period under examination. This is the single most expensive timing mistake we see.
The practical rule: schedule the test in the first half of the observation period, leave six to eight weeks for remediation, and make sure the retest also lands inside the window. Then the auditor sees the full cycle operate: test, fix, verify.
What scope auditors expect from a SaaS company
The scope should match the system described in your SOC 2 report. For most Australian SaaS businesses that means:
- The customer-facing web application, tested authenticated across every user role, because broken access control is the finding that actually exposes customer data.
- The API behind it, including any public or partner endpoints, tested against the OWASP API Security Top 10.
- The production cloud environment, through a configuration review of identity, network exposure, storage and logging, since the cloud account is where most real SaaS breaches happen.
- Mobile apps, if they are part of the in-scope system.
Testing the marketing site instead of the platform is a common and useless substitution. Auditors notice when the scope of the pentest does not match the system boundary in the report.
Evidence to hand your auditor
Auditors want to see the control operate end to end, not just that a test happened. The evidence pack that satisfies them contains:
- The penetration test report, with scope, dates, methodology and the tester's independence stated clearly.
- Findings rated by severity, so they can trace them to your vulnerability management process.
- Tickets or a tracker showing each finding assigned, remediated or formally risk-accepted, with dates inside the observation period.
- The retest report or attestation letter confirming the fixes.
- Evidence of the continuous side of CC7.1: regular vulnerability scanning between tests.
That last item is why the pentest and the scanner are complementary rather than competing. Our post on penetration testing versus vulnerability scanning explains what each covers; for SOC 2 you want both, on different clocks.
Questions we get asked about SOC 2 pentesting
Can we use our compliance platform's scanner instead of a pentest?
Usually not on its own. Vulnerability scanning is good evidence for the continuous monitoring side of CC7.1, and most auditors want to see it running. But a scanner cannot evaluate business logic, authorisation between user roles, or chained attacks, which is exactly what a SOC 2 auditor means when they ask whether your controls have been independently tested. Keep the scanner for coverage between tests and use a manual pentest for the annual evaluation.
Does the tester have to be independent?
The criteria talk about separate evaluations, and auditors interpret that as testing by someone outside the team that built and operates the system. An internal security team can test, but a third-party report carries more weight with auditors and with the enterprise customers who will read your SOC 2 report later. If you do test internally, document the independence of the people involved.
Do we need a new test for every report?
For Type II, yes in practice: each observation period needs evidence that the control operated during that period, so a test from the previous year does not carry over. For a bridge letter covering a short gap between reports, a recent test is usually acceptable. Ask your auditor early, because the answer affects when you book.
What if findings are still open when the period ends?
Open findings are not automatically an exception. What matters is that your vulnerability management process handled them: each finding tracked, prioritised by severity, either fixed or formally risk-accepted with a documented reason and an owner. An unresolved high-severity finding with no ticket and no decision is what produces an exception. A retest inside the window showing the serious ones closed is the cleanest outcome.
Will one test cover SOC 2 and ISO 27001?
If the scope matches both system boundaries, yes. Most Australian SaaS companies pursue both within a year or two of each other, and a single properly scoped engagement, with a report mapped to both frameworks, is far cheaper than two. Tell your provider both audits are coming so the report is written for both readers.
A note for Australian businesses
SOC 2 is often the first of several frameworks a growing Australian SaaS company meets. The same annual test, scoped properly, also produces evidence for ISO 27001 (see our ISO 27001 pentest guide) and for customer security questionnaires, which saves a second engagement. If you handle personal information, the test also supports your "reasonable steps" obligation under the Privacy Act. Scope once, test once, reuse the evidence everywhere.
Data handling is worth asking about too. If your SOC 2 system boundary includes customer personal data, you want findings and evidence stored onshore and deleted on a schedule, and you want to be able to say so to your own customers.