Do You Need a Penetration Test for SOC 2?

Direct answer: SOC 2 does not explicitly require a penetration test. The Trust Services Criteria ask you to identify and address vulnerabilities in a defensible, ongoing way, and a penetration test is simply the most common and most credible way to satisfy that expectation. In practice, nearly every organization pursuing SOC 2, especially Type II, ends up commissioning an annual pen test because auditors expect to see one and enterprise buyers ask for one directly in security questionnaires. If you are budgeting for SOC 2 in Canada, plan for a penetration test as a recurring line item, not an optional extra.

What SOC 2 actually says about testing

SOC 2 is built on the AICPA Trust Services Criteria, most commonly Security plus one or more of Availability, Confidentiality, Processing Integrity, and Privacy. Under the Security criterion, CC7.1 expects you to have a process for identifying vulnerabilities in your environment, and CC4.1 expects ongoing monitoring of the control environment. Neither point names penetration testing by title. In principle, you could satisfy the letter of the criteria with vulnerability scanning, code review, and a mature patching cadence.

In practice almost nobody stops there, for two reasons that matter more than the text of the framework.

Why auditors expect one anyway

A penetration test is the cleanest, most auditor-friendly evidence that someone actively tried to break into your systems the way a real attacker would, rather than relying only on automated scanning output. Auditors see thousands of SOC 2 packages a year, and a recent, well-scoped pen test report is a fast way to demonstrate that CC7.1 is not just a policy on paper. Show up without one and you will likely spend more time explaining your alternative evidence than the test itself would have cost.

This is especially true for a Type II report, which is not a snapshot but an attestation that your controls operated effectively over an observation window, usually three to twelve months. A pen test from three years ago, or one run against a staging environment that no longer resembles production, will not hold up. The common expectation is an annual test, plus a fresh test after any material change to your architecture, such as a new production region, a major refactor, or the launch of a new customer-facing API.

Why your buyers demand it, harder than your auditor does

The bigger driver is usually not the auditor at all. It is the enterprise customer on the other side of your deal. The same buyers who ask for your SOC 2 report also run their own vendor security review, and that review almost always asks a version of: when was your last penetration test, who performed it, and can we see the executive summary. Canadian SaaS companies selling into the United States feel this acutely, since US enterprise procurement teams tend to be more prescriptive about third-party testing than the SOC 2 criteria alone require. A dated or missing pen test report is a common reason a deal stalls in security review even after the SOC 2 report itself has been accepted.

The Canadian compliance layer on top

If you handle personal information, a penetration test also supports obligations that sit alongside SOC 2 rather than inside it. PIPEDA expects organizations to protect personal information with safeguards appropriate to its sensitivity, and being able to show a recent, independent test of the systems that hold that data is one of the more concrete ways to demonstrate that. If you have Quebec customers or employees, Law 25 raises the bar further, with explicit expectations around security safeguards and breach notification that a documented testing program helps you meet. We see this combination constantly with clients in Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal who are building a SOC 2 report for US buyers while also needing their Canadian privacy posture to hold up to scrutiny at home. One well-scoped penetration test, repeated annually, tends to serve both needs at once.

Scoping it so the same engagement does double duty

The efficient move is not to buy testing three separate times for three separate audiences. Scope one engagement so the report can serve as SOC 2 evidence, as the artifact you attach to enterprise security questionnaires, and as something your engineering team actually acts on. That generally means:

• Testing the production application and any environment that processes or stores customer data, not a stale staging copy.
• Including the cloud infrastructure and network boundary around that data, not just the web front end.
• Getting a report written in two layers: a plain-language executive summary an auditor or a procurement reviewer can read in five minutes, and a technical section with reproducible findings your developers can actually fix.
• Timing the test to land inside your Type II observation window, and repeating it on the same schedule every year so you are never scrambling before a renewal.

What it costs and when to start

Cost is the question we get asked most, and it depends entirely on scope. A single web application with a modest attack surface is a different engagement than a multi-tenant SaaS platform with several APIs and cloud infrastructure to cover. As a general reference, traztech penetration testing starts from $1,000 CAD, scoped to the real risk in your environment rather than sold as a fixed package. If you are heading into a SOC 2 Type II audit, start the conversation about scope at least two to three months before your observation window opens, so the test lands cleanly inside the period your auditor will be reviewing rather than outside it.

How we handle it at traztech

We run penetration tests built to serve as SOC 2 and enterprise-review evidence from day one, not retrofitted after the fact. Testing is delivered with our partner Lorikeet Security and led by Jacob Masse, a published security researcher with five CVEs to his name, including CVE-2024-45163, a CVSS 9.1 finding that functions as a kill-switch against Mirai-family botnet malware. Because we also run the underlying SOC 2 readiness work, we make sure the test lines up with the rest of your controls instead of arriving as a disconnected purchase that your auditor has to reconcile after the fact.

See our penetration testing services for how we scope engagements, or review the full pricing overview to see where a test fits alongside a SOC 2 program. If a deal or an audit deadline is already on the calendar, book a call and we will help you scope the fastest path to evidence that actually holds up.

What the auditor actually opens the report to check

Auditors do not read your penetration test findings the way your engineers do. They are checking a short list of attributes, and a report that misses any of them creates follow-up work no matter how good the testing was.

They check the date on the cover, and whether it falls inside the observation window. They check the scope statement, and whether the systems named there match the systems named in your own system description. They check that the testing party is independent of the people who built the thing. They check that there is a methodology section describing what was done, because a report with findings but no method is indistinguishable from scanner output with a logo on it. And they check for evidence that the findings went somewhere: tickets, fix dates, and ideally a retest.

That last one is where most packages fall apart. A company hands over a report with four high-severity findings and nothing else. The auditor now has an open question about whether the vulnerability management control operated, and you spend two weeks assembling ticket exports under time pressure. The cheap fix is to open a ticket for every finding on the day you receive the report, even the ones you intend to accept as risk, and to record the acceptance decision and its approver in the ticket. Risk acceptance is a legitimate outcome. Silence is not.

Scope decisions that change what the test is worth

Credentialed versus uncredentialed. An unauthenticated test of a SaaS application tells you about your login page and very little else. The interesting attack surface in a multi-tenant product sits behind authentication, in the code that decides whether user A can read user B's records. If your engagement letter does not include test accounts, you have bought a test of the front door of a building whose rooms are all unlocked.

Number of roles. Give the tester an account at every privilege level you sell: viewer, editor, admin, and whatever your reseller or support impersonation role is called. Broken object level authorization, where an ID in a URL or an API body lets one tenant reach another tenant's data, is the finding class that actually ends deals, and you cannot find it with one account.

Production or a faithful replica. Testing a staging environment is acceptable only when staging is a real mirror of production configuration. In most startups it is not: staging has debug endpoints enabled, different WAF rules, a permissive CORS policy and stale IAM roles. A report against that environment tells your auditor nothing about the system your customers use, and an experienced reviewer will say so.

Protective tooling. Decide deliberately whether the WAF and rate limiting stay on. Leaving them on tests your deployed posture, which is what a buyer cares about. Turning them off for the tester's source IP tests the application itself, which is what your engineers can actually fix. The useful answer is usually both, run in that order, with the report saying which findings were reachable through the WAF and which were not.

What a serious finding mid-window does to your audit

Founders assume a critical finding discovered during the observation window damages the report. Usually it does the opposite. A test that found a critical flaw, a ticket opened the same day, a fix deployed in nine days and a retest confirming closure is a working control cycle, documented end to end. That is stronger evidence than a clean report, because a clean report mostly demonstrates that nobody looked hard.

What does cause trouble is a critical finding that turns out to have been exploited, or that exposed customer data during the window. At that point you are no longer in vulnerability management, you are in incident response, and the criteria that govern incident handling and communication come into play. The auditor will want the incident record, the timeline, the containment steps, the impact determination and the notification decision. If you have Canadian personal information involved, PIPEDA's real risk of significant harm test and Quebec's Law 25 notification duties run on their own clocks regardless of what your auditor thinks.

The practical instruction is to have the decision path written down before the test starts. Who decides whether a finding is a vulnerability or an incident. Who is allowed to declare one. Who talks to customers. Writing that at eleven at night while a tester is on the phone is how companies make notification decisions they later regret. If you do not have that path, it is worth building as part of an incident response retainer before you buy testing, not after.

What a pen test does not cover, and what fills the gap

A once-a-year test is a point-in-time exercise, and CC7.1 expects an ongoing process. Auditors reviewing a Type II window want to see something happening in the other eleven months. In practice the credible package looks like this: continuous dependency scanning in CI with a documented triage rule, cloud configuration monitoring against a benchmark, an operating system patch cadence with an actual number attached to it, and the annual test sitting on top as the manual, adversarial layer.

A cloud configuration review is a separate exercise from a network penetration test and frequently returns more real risk per dollar for a small SaaS company. Overly broad IAM roles, public storage buckets, unrotated long-lived access keys, security groups open to the world on a management port. Those are configuration findings, not exploitation findings, and a black-box network test may never surface them. If your infrastructure has grown organically for three years without anyone reviewing IAM, book the configuration review first.

Social engineering and phishing simulation are a third category. They are useful, buyers occasionally ask, and they belong in a separate scope with separate legal sign-off. Bundling them silently into an application test tends to produce a rushed campaign that satisfies nobody.

Cost drivers, in plain terms

Testing is priced in tester days, so everything that changes the days changes the price. The number of distinct applications. The number of API endpoints and whether you can hand over an OpenAPI specification, which shortens reconnaissance considerably. The number of user roles. Whether cloud infrastructure is in scope. Whether the environment is stable during the window or being deployed to hourly. Whether a retest is included in the fee or billed separately, which is the line item most often quietly missing from a cheap quote.

Things that reduce cost are almost all preparation. Working test accounts provisioned before day one rather than on day three. A network diagram. A contact who can answer a question inside an hour. A fixed code freeze during testing. Teams that supply these get more of the engagement spent on testing and less on waiting, and the report is better for it.

Our own testing starts from $1,000, and the honest framing is that the low end of that range buys a focused test of a small application, not a full platform assessment. Published starting prices for the wider program sit on the pricing page so you can see where testing lands next to readiness work rather than being quoted in isolation.

When you should not buy a penetration test yet

There are three situations where we will tell you to spend the money elsewhere.

You already know what is broken. If your team can list six things they are embarrassed about, you do not need someone to find a seventh. Paying an external tester to hand you a list you already have is the most common waste we see. Fix the known items, then test to find what you could not see yourself. That order also produces a better report, which matters when a buyer reads it.

Your buyer will accept less. Some mid-market security reviews ask whether you perform regular vulnerability scanning and whether findings are remediated on a defined timeline. If that is genuinely the question, a documented scanning program with evidence answers it. Ask the buyer's security contact directly what they need. It is a two-line email and it occasionally saves several thousand dollars.

Your architecture is about to change. If you are three weeks from a rewrite of the authentication layer or a migration to a new cloud account, testing the current shape buys you a report that describes a system you are about to delete. Wait, then test the thing your customers will actually be using.

There is also the case where you should buy testing but not from us. If you need a specialist discipline that is not our practice, hardware and embedded testing, or a full red team exercise measured against a mature detection function, hire a firm that does that work daily. A generalist doing a red team badly is worse than no red team, because it tells you that your detection works when it does not.

Questions to ask any testing vendor before you sign

Ask who performs the testing and whether you get their name. Ask how much of the engagement is manual and what tooling is used for the rest, and treat any vendor unwilling to answer as a scanner reseller. Ask for a redacted sample report, then check whether the findings include reproduction steps you could hand to an engineer. Ask whether a retest of remediated findings is included and for how long after delivery. Ask what happens if they find something critical on day one, and who they call.

Ask, finally, whether the vendor understands how the report will be consumed. A test written purely for engineers gets bounced by procurement. A test written purely for procurement gets ignored by engineers. Testing that is scoped alongside your control environment, rather than bought as a disconnected artifact, is the version that lands in both places, and that is why we run it as part of the wider compliance program rather than as a product sold on its own.