SOC 2 for SaaS companies in Canada

SOC 2 was written for service organisations, and a multi-tenant SaaS product is the shape it fits best. The parts that go wrong are almost always scope boundaries, subprocessors, and change management evidence out of your deployment pipeline.

Last reviewed 2026-08-27Written by Jacob Masse, TrazTech Inc.

For a Canadian SaaS company, a first SOC 2 Type 2 takes six to twelve months and costs $35,000 to $90,000 CAD all in. The audit itself is the easy part. What decides whether the engagement runs smoothly is three decisions made before the auditor is hired: what the system boundary is, which vendors are subservice organisations, and whether your deployment pipeline produces evidence somebody can sample.

The general picture is on the SOC 2 guide. If you are still working out whether you need a report at all, the startup page is the better starting point.

Drawing the system boundary

A SOC 2 report covers a described system, not a company. You write the description, and where you draw the line decides how much gets audited. Most SaaS companies scope one production application and the infrastructure it runs on. What sits outside is anything that does not process customer data: your marketing site, an internal analytics warehouse a customer never touches, a beta product nobody has bought.

Two mistakes are common. Scoping too wide is expensive and slows every subsequent audit, because you have committed to testing things nobody asked about. Scoping too narrowly is worse, because a buyer who reads the system description and finds the product they use is not in it will say so, and you will pay for a second audit.

The test is whether a reasonable reviewer at your customer would consider the excluded thing part of what they bought. If your acquired second product runs on separate infrastructure and is sold separately, carving it out is defensible. If it shares a database with the audited product, it is in scope whether you like it or not.

Multi-tenancy and logical separation

The control auditors probe hardest in a multi-tenant product is tenant isolation. They want to know how one customer's data is prevented from reaching another, and they want more than an assurance that a query includes a tenant identifier.

What tends to satisfy an auditor is a written description of the isolation mechanism, evidence that it is enforced at a layer developers cannot easily bypass, and test results showing it holds. Row-level security in the database, enforced tenant scoping in a data access layer, or separate schemas all work. Application code that filters by tenant in each individual query is the weakest version, because a single missed clause becomes a cross-tenant leak.

Your penetration test is the usual place this gets exercised. Ask the testing firm to include an authenticated multi-tenant test where a user of one tenant tries to reach another tenant's records. That finding, or the absence of it, is the evidence. Testing scoped for a SOC 2 audit covers what auditors expect from the report.

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.

Subservice organisations, the SaaS-specific trap

Every SaaS company depends on vendors that operate controls on its behalf. Your cloud provider runs physical security. Your identity provider runs authentication. Your email service holds customer contact data. In SOC 2 these are subservice organisations and you have to deal with each one explicitly, in the report, using either the carve-out method or the inclusive method.

Carving out is not the end of it. You still have to monitor those vendors, which in practice means collecting each one's own SOC 2 report annually, reading it, and recording that somebody read it. Auditors ask for the review record, not the vendor's report. A vendor register with a review date and a named reviewer against each entry closes this item in minutes rather than weeks.

Change management out of your pipeline

CC8 asks whether changes to the system are authorized, tested and approved before release. For a SaaS company shipping continuously, this is the criterion where evidence either falls out of your existing tooling or becomes a nightmare of screenshots.

The version that works: every change goes through a pull request, every pull request needs an approving review from somebody other than the author, the main branch is protected so this cannot be skipped, and deployments are triggered by merges rather than by a person with production credentials. An auditor samples twenty merges and checks each had an approval. That takes an afternoon if the branch protection is real, and takes weeks if a quarter of the sample turns out to be direct pushes during an incident.

Emergency changes are allowed. What is not allowed is emergency changes with no record. Keep a short break-glass procedure that says who can bypass, what they have to log, and that it gets reviewed afterwards, and use it.

What it costs a SaaS company and how long it takes

The audit fee page breaks the examination line down further, and the cost calculator will estimate all of it against your own headcount, cloud footprint and criteria.

What is different for a Canadian SaaS company

Your buyers are usually American and your obligations are usually Canadian. That produces two things worth planning for.

First, data residency questions arrive through contracts rather than through the audit. American buyers rarely care where your data lives. Canadian public sector buyers and some regulated customers do, and a SOC 2 report describes where data is processed without making a foreign region acceptable to a buyer who has ruled one out. Decide your region strategy before a public sector deal forces it, and read who genuinely requires Canadian residency before you price a migration, because the list is shorter than the objection suggests.

Second, PIPEDA applies to you already, and Quebec's Law 25 applies on top if you hold personal information about people in Quebec. Neither is discharged by a SOC 2 report. Law 25 in particular requires a named privacy officer and privacy impact assessments for certain projects, and those are cheap to do early and awkward to retrofit during a deal. How the two fit together is worth ten minutes before you scope anything, and the Law 25 page is the detail if any part of your user base is in Quebec. If your product runs on a model API, SOC 2 for AI companies covers the four scope decisions a generic SaaS scope will miss.

A sensible sequence for a SaaS team

1. Get the buyer to confirm report type, criteria and the date in writing.
2. Write the system description first. It forces the boundary decision before anyone is billing hours.
3. Fix access management: single sign-on, multi-factor authentication everywhere, offboarding that actually removes access the same day.
4. Turn on branch protection and required reviews, so change evidence exists from day one of the window.
5. Build the vendor register and record a review against each subservice organisation.
6. Choose a platform, or decide honestly that a spreadsheet is enough for now. The platform comparison takes a position on where that line sits.
7. Engage the audit firm two to three months before you want the window to open, because assurance practices book fieldwork well ahead.

Common questions