SOC 2 penetration testing requirements
There is no clause in the SOC 2 criteria that says you must buy a penetration test. There is a criterion that says you must identify vulnerabilities and act on them, and a test is how most companies prove it.
SOC 2 does not require a penetration test. This surprises people, because almost every SOC 2 report mentions one and almost every auditor asks for one. What the Trust Services Criteria actually require is that you monitor for vulnerabilities, evaluate what you find, and remediate it. A penetration test is the evidence the market has converged on for satisfying that, which is not the same as a rule.
The practical consequence is useful. Because there is no prescribed test, you have room to scope one that is genuinely worth doing rather than one that ticks a box. And because the criterion is about the whole cycle rather than the test, a report with unaddressed high findings is worse evidence than no report at all.
What the criteria actually say
The relevant common criteria sit in the monitoring and risk mitigation areas. Paraphrased, they ask you to detect and monitor for changes and vulnerabilities that could affect the system, to evaluate what you detect, and to act on it. The criteria language is deliberately general because SOC 2 is designed to be applied to very different kinds of company.
| Common assumption | What is actually true |
|---|---|
| SOC 2 requires an annual penetration test | It requires vulnerability identification and remediation. Annual testing is the convention auditors expect, not a written rule. |
| The test must be done by an external firm | Independence from those who built and run the system is what matters. External is the easiest way to demonstrate it and is what most auditors will want. |
| The auditor reads the full report | They typically want the scope, the dates, the summary of findings, and evidence that findings were tracked and closed. |
| A clean report is the goal | A report with no findings invites the question of whether the test was real. Findings plus a remediation trail is stronger evidence. |
| A vulnerability scan counts | Continuous scanning satisfies part of the monitoring criterion. Most auditors expect testing beyond it, and customers reading the report certainly do. |
| The auditor performs the test | They do not, and they cannot. The CPA firm issuing your report cannot also provide the testing without compromising independence. |
What auditors expect in practice
Auditor expectations are more consistent than the criteria are. Across most Canadian SOC 2 engagements the ask is the same four things.
- A test performed within the observation period, by a party independent of the system's builders and operators.
- A scope that covers the systems in the SOC 2 boundary, with any exclusion explained in writing.
- Findings tracked in whatever ticketing system you already use, with owners and dates, not in a spreadsheet created the week before fieldwork.
- Evidence that high and critical findings were closed, ideally verified by a retest.
The third item is where companies lose points. A penetration test is a control operating over time, and Type 2 tests whether the control operated throughout the period. Findings that appeared in a report in February and were closed in a rush in November tell the auditor the vulnerability management process is not really running. Put the findings into your normal backlog with your normal severities and let the trail form itself.
Type 1 and Type 2 differ here
A Type 1 report tests design at a point in time, so evidence that a test was commissioned and a process exists can be enough. A Type 2 tests operation over a period, usually three to twelve months, so the test has to fall inside that window and the remediation has to be visible across it. Companies that book the test for the last month of the observation period create a problem that no amount of scoping fixes.
Scoping a test that matches the audit
The scope of your penetration test should map onto the system description in your SOC 2 report. Mismatch is the most common finding-adjacent problem in this area: the report describes a platform with four services, and the test covered one application.
Work from the system description outward. Every service in the boundary is in scope for testing or has a written reason not to be. Corporate systems that support the service, such as your identity provider configuration and your laptop fleet, are usually in the audit boundary too, which is why an internal or cloud identity review often belongs in the engagement alongside the application test.
What is normally out: third-party SaaS you consume, which is covered by their own reports and by your vendor management control. Your integration with them is in.
Cost and timing
For a company doing a first SOC 2, the testing spend is typically $10,000 to $30,000 CAD, on top of the audit fee and any readiness support. An authenticated application test plus a cloud configuration review is the most common shape. Full ranges are on penetration testing cost in Canada.
| When | What to do |
|---|---|
| Before the observation period opens | Run the test early enough to fix structural findings before the clock starts |
| Early in the observation period | Book the test if you did not test beforehand, leaving room to remediate and retest inside the window |
| Mid period | Close high findings, retest, and let the ticket trail form naturally |
| Before fieldwork | Assemble scope statement, report, ticket history and retest evidence in one place |
The mistake to avoid is treating the test as an evidence item to be procured near the end. Testing early is cheaper in every way: findings are fixed before they become audit exceptions, and the remediation trail exists because it happened rather than because you assembled it.
If you are doing ISO 27001 as well
One engagement can serve both. ISO 27001 approaches the same ground through Annex A, which covers technical vulnerability management and security testing in development, and a certification auditor will ask similar questions about scope, findings and remediation. The requirement is that the tested scope matches each audited scope, which is usually satisfiable with one scope statement written with both in mind. The Annex A controls page covers what the certification side expects.
If you are still deciding which framework you need at all, that decision should come before you scope any testing, since the audit boundary determines the test boundary.
Scope a test your auditor will accept
Tell us your SOC 2 boundary and your observation period, and we will help you scope the testing before you collect quotes.
Get matchedCommon questions
Does SOC 2 require a penetration test?
Not by name. The Trust Services Criteria require you to identify, evaluate and remediate vulnerabilities. Auditors have settled on an annual independent penetration test as the standard evidence for that, so in practice you will be asked for one, and arguing the technical point with your auditor is rarely a good use of the relationship.
Can our compliance platform's scanner replace the test?
It covers the continuous monitoring half of the criterion and it is genuinely useful for that. It does not cover authorization flaws, tenant isolation or business logic, which are the failures customers care about most. Most auditors will accept the platform as evidence of monitoring and still expect a test.
What if the test finds critical vulnerabilities right before the audit?
Fix them, document the fix, and retest. A critical finding that was found and closed is evidence your process works. What creates an audit exception is a critical finding with no owner, no date and no resolution. Tell your auditor early rather than letting them discover it in the report, because the conversation is much easier before fieldwork than during it.
Can the same firm do our SOC 2 audit and our penetration test?
No. The CPA firm issuing the attestation cannot also provide the testing it relies on as evidence, because that compromises independence. Some firms have separate practices and will offer both, and you should still separate them. Buying the test from a different provider removes the question entirely.
How does the test appear in the final report?
Usually as a control description in the system description, with the auditor's test of that control noted in the testing matrix. The findings themselves do not appear. Your customers see that independent testing occurred and was tested by the auditor, not what was found, which is another reason the attestation letter matters for the conversations that happen outside the report.