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. Almost every SOC 2 report mentions one and almost every auditor asks for one, but the Trust Services Criteria require that you monitor for vulnerabilities, evaluate what you find, and remediate it. A penetration test is the evidence the market converged on. That is not the same as a rule.
Not required By the Trust Services Criteria, by name
$10,000 to $30,000 Typical SOC 2 scoped test, CAD
The ticket trail What the auditor asks for, more than the report
With no prescribed test, you have room to scope one worth doing rather than one that ticks a box. And because the criterion covers the whole cycle, 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 language is general because SOC 2 applies 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. 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 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.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
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, so 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, and the cost calculator prices a scope you describe. If you are unsure about the shape of the engagement, the test finder settles it in five questions.
| 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 |
Do not treat the test as an evidence item to procure near the end. Testing early is cheaper: findings are fixed before they become audit exceptions, and the remediation trail exists because it happened rather than because you assembled it.
Who runs this site
TrazTech operates GetPentest from Toronto and works on both halves of this page. It runs penetration tests, more than 20 delivered, with 5 CVEs credited to the practice principal. It also does SOC 2 readiness, and it keeps working relationships with CPA firms that issue SOC 2 opinions, so it can make an introduction and coordinate the engagement.
It cannot audit you, and the independence rule on this page is the reason. The CPA firm issuing the opinion has to be independent of whoever built and tested the controls, and an introduction guarantees nothing about the opinion. Some buyers also prefer the readiness firm and the testing firm to be different companies, which no auditor objects to and which is a reasonable thing to insist on. Compare at least two testing firms on the same written scope either way.
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 tested scope has to match each audited scope, 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, that decision comes before you scope any testing. The audit boundary determines the test boundary.
Most Canadian companies reading this are doing SOC 2 because a United States enterprise customer asked, in which case the contract clause matters more than the criteria do. That reading is on SaaS penetration testing in Canada.
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.