Compliance

How to Get SOC 2 Compliance in Canada: Steps, Timeline, and Type 1 vs Type 2

How to get SOC 2 compliance in Canada: the 9 steps, a dated timeline, when to pick Type 1 or Type 2, and how PIPEDA, Law 25 and OSFI B-10 fit in.

Saeid GhobadiFounder and CEO17 min read
A straight line of round stepping stones crossing a calm pond toward the far bank, a picture of the step-by-step route to SOC 2 compliance

A customer's security questionnaire has a line that reads "Please provide your current SOC 2 Type 2 report." You don't have one. The deal is on hold until you do, and someone needs a date.

This guide gives you the route to SOC 2 compliance for a Canadian company: the steps in the order that works, a dated timeline you can put in front of a sales lead, and a simple rule for whether to start with a Type 1 or go straight to a Type 2.

Here's the short answer. You get SOC 2 compliance by scoping the service your customer cares about, closing the gaps against the AICPA's Trust Services Criteria, and then having an independent CPA firm examine your controls and issue a report. A Type 1 report checks your control design on one date and can land a few months after you start. A Type 2 report tests whether those controls actually worked over a period, usually 3 to 12 months, so a first Type 2 is typically 9 to 12 months away if you're starting from scratch. SOC 2 isn't a certificate and no Canadian law requires it. Your customers ask for it because PIPEDA, Quebec's Law 25 and, for banks and insurers, OSFI Guideline B-10 make them answerable for what you do with their data.

That's the whole job. The rest of this post is the detail.

Not sure where you'd start? Our free SOC 2 readiness assessment takes a few minutes and shows which of the steps below you've already covered.

An empty white picture frame hanging on a pale office wall, because SOC 2 gives you an auditor's report, not a certificate to frame

What is SOC 2 compliance, and what does it mean?

SOC 2 compliance means a licensed CPA firm has examined your controls against the AICPA's Trust Services Criteria and issued a report with an unqualified (clean) opinion that's still current. "SOC 2 compliant" is shorthand. What you actually hold is the report.

The criteria cover five categories. Security is always in scope. Availability, processing integrity, confidentiality and privacy are optional, and you add them only when a customer needs them. The current version is the 2017 Trust Services Criteria with revised points of focus from 2022 (AICPA). The AICPA kept the criteria the same and updated the guidance underneath them.

Microsoft's documentation shows the formal plumbing. Its SOC 2 Type 2 examination runs under the AICPA's SSAE 18 attestation standard, the AICPA SOC 2 Guide and the 2017 criteria, and the auditor "renders an opinion" at the end (Microsoft Learn). That opinion is what your customer reads first.

Is SOC 2 a certification?

No. This trips people up, partly because "SOC 2 certification" is one of the most-searched phrases on this topic in Canada. There's no SOC 2 certificate, no certifying body, and no pass mark printed on a wall plaque. A CPA firm gives an attestation opinion on your controls. That's different from ISO 27001, which really is a certification (more on that below).

You'll still see "SOC 2 certified" on vendor websites. Customers know what it means. Just don't put it in a contract.

What is a SOC 2 Type 2 "certification"?

It's a SOC 2 Type 2 report described loosely. The Type 2 part means the auditor tested whether your controls operated effectively across a whole period, not just whether they looked right on paper on one day. It's the one enterprise buyers usually ask for.

What are SOC 1, SOC 2 and SOC 3?

SOC 1, SOC 2 and SOC 3 reports compared

Report

Covers

Typical reader

SOC 1

Controls that affect your customer's financial reporting (payroll, billing)

Their finance team and external auditor

SOC 2

Security, plus any of availability, processing integrity, confidentiality, privacy

Their IT, security, privacy and procurement teams, usually under an NDA

SOC 3

A short public summary of a SOC 2 examination

Anyone, often posted on your website

AWS is a good real-world example: it releases SOC 2 and SOC 3 reports twice a year, each covering 12 months, and you need an NDA to read the SOC 2 while the SOC 3 is public (AWS SOC FAQs). If you want the buyer's view of these reports, our guide on what a SOC 2 report is and how buyers read it covers it in full.

Who needs SOC 2 compliance in Canada?

Nobody is legally required to have it. You need it when your customers start asking, and in Canada they usually ask if you:

  • Sell software or a hosted service to larger companies, especially US enterprises, where a SOC 2 question is standard in the security review.
  • Run IT, security or data processing for other companies: MSPs, MSSPs, payroll, call centres, backup and hosting providers.
  • Sell to banks, insurers or other federally regulated financial institutions, which have to manage third-party risk under OSFI Guideline B-10.
  • Handle personal information for clients across provinces, because their privacy duties follow the data to you.

Picture a 40-person Toronto SaaS company that sells scheduling software to clinics and has just landed a pilot with a US hospital network. The clinics never asked about SOC 2. The hospital's vendor-risk team asked on day one. That's the usual trigger: one bigger customer, one questionnaire. (A composite, not a client.)

If none of your customers have asked, you may not need SOC 2 yet. A security baseline like the Canadian Centre for Cyber Security's baseline controls for small and medium organizations will cover most of the same ground and makes SOC 2 easier later.

How do you get SOC 2 compliance? The 9 steps

Here's the order that works. Each step has an owner and an output, so you can use the list as your SOC 2 compliance checklist.

A hand pressing the last of a row of blank sticky notes onto a glass wall, like working through the steps of a SOC 2 project one at a time

1. What exactly is your customer asking for?

Get it in writing before you scope anything. You need four answers: Type 1 or Type 2, which trust services criteria, whether a Canadian-standard report is acceptable (see the Canada section), and the date they need it by. A one-line email from their security team saves months of guessing.

2. What's in scope?

Scope is the system behind the service the customer buys: the application, the infrastructure it runs on, the people who run it, and the processes around it. Keep it tight. Every extra product line, office or data centre adds controls to test.

List your subservice organizations too, meaning the providers your service depends on, like AWS, Azure or a colocation provider. It's common to leave the cloud provider's own controls out of scope and point to that provider's SOC 2 report instead. The auditor will want to see that you actually review it.

3. Which trust services criteria will you include?

Start with security, which is mandatory. Add availability if you sign uptime commitments, confidentiality if you hold customer secrets under NDA, and privacy only if the customer specifically asks. Each category you add means more controls and more evidence for the auditor to sample. The SOC 2 compliance work we do starts with this exact question, because cutting scope here is the cheapest decision in the whole project.

4. Where are your gaps today?

A gap assessment compares what you actually do against the criteria. The security criteria (the "common criteria") run from control environment and risk assessment through to logical access, system operations, change management and risk mitigation. The usual gaps are rarely missing tools. They're missing proof: no record of quarterly access reviews, no written change approval, no evidence the backup restore was ever tested.

The output is a gap list with an owner and a due date on every line.

5. How do you close the gaps?

Write the policies the criteria expect (information security, access control, change management, incident response, vendor management, business continuity), then put the controls in place behind them. Typical work:

  • MFA everywhere, plus joiner, mover and leaver steps tied to HR.
  • Logging and alerting on the in-scope systems, with someone named to review alerts.
  • Vulnerability scanning and a patch timeline you can actually meet.
  • A risk assessment, done and dated. Our cybersecurity risk assessment guide walks through a Canadian version.
  • Security awareness training with completion records.
  • Vendor reviews for your own suppliers, including their SOC 2 reports.

Write each control so it produces evidence on its own. A control that leaves a ticket, a log entry or a signed record is a control you can prove.

6. When should you pick the auditor?

Early, during step 4 or 5, not after. Auditors book up, and the auditor's view of your scope and evidence format shapes how you build things. Agree on the report type, the criteria, the reporting standard and the period start date in the engagement letter.

7. Should you run a readiness review?

It's optional, but a dry run against the gap list catches the controls that exist on paper but never ran. Treat it like a fire drill. If the evidence for a control is "we do that, just not formally", the auditor will treat it as missing.

8. Type 1 first, or straight into the Type 2 window?

If you need something to show a customer soon, get a Type 1 report as of a set date. Either way, the Type 2 observation window starts once your controls are running, and from then on every control has to keep producing evidence: every access review, every change ticket, every leaver removed on time.

9. What happens in the SOC 2 audit itself?

The auditor tests samples from across the period, writes up any exceptions, and you add a management response to each one. Exceptions aren't automatically fatal. Microsoft's own guidance says "most examinations have some observations on one or more of the specific controls examined. This outcome is expected" (Microsoft Learn).

Then the cycle starts again. Microsoft says it "doesn't allow any gaps in the consecutive periods of examination from one examination to the next", and that's the pattern your customers will expect from you too.

How long does SOC 2 take? A dated example

Here's a planning example for a small, cloud-hosted service company with security as the only criterion, starting Monday 2026-11-02. These are planning estimates, not a quote. Your auditor's calendar and the size of your gap list move every date.

A row of glass jars on a white shelf, each holding a little more white sand than the last, like the evidence that builds up month by month in a SOC 2 Type 2 window
A dated example SOC 2 timeline

Stage

Example dates

Length

Output

Confirm the ask, scope, criteria

2026-11-02 to 2026-11-13

2 weeks

Scope statement, customer's requirement in writing

Gap assessment, auditor shortlist

2026-11-16 to 2026-12-04

3 weeks

Gap list with owners and dates, signed engagement letter

Close the gaps, start running controls

2026-12-07 to 2027-02-26

about 12 weeks

Policies approved, controls producing evidence

Type 1 as-of date

2027-03-01

1 day

Type 1 report a few weeks later, around 2027-04

First Type 2 window

2027-03-01 to 2027-08-31

6 months

Evidence for every control, every month

Type 2 fieldwork and report

2027-09 to roughly 2027-11

a few months

First Type 2 report

Next window

2027-09-01 to 2028-08-31

12 months

No gap between periods

So the answer to "how long does SOC 2 take" from a cold start is roughly 4 to 5 months to a Type 1 and 12 months to a first Type 2 in this example. One compliance software vendor's published guide gives a similar range: 3 to 6 months for a Type 1 and 9 to 18 months for a Type 2.

Can you shorten the first window? Often, yes. There's no fixed minimum period in the AICPA's public material, but many firms won't examine less than about three months, because monthly and quarterly controls need enough cycles to sample. A three-month first window (2027-03-01 to 2027-05-31 here) could bring the first Type 2 report forward by about a quarter. Ask your auditor before you promise that date to anyone.

What usually breaks the plan? Controls that start late. If the access review that's meant to start in March starts in May, the auditor finds two missing months of evidence, and you either report an exception or move the window.

SOC 2 Type 1 vs Type 2: which should you get first?

SOC 2 Type 1 and Type 2 compared

Type 1

Type 2

What it tests

Whether controls are designed properly, on one date

Whether controls are designed properly and operated effectively over a period

Period

A single "as of" date

Usually 3 to 12 months

Time to first report

Months

Usually 9 to 12 months or more from a cold start

Buyer weight

A useful start, often accepted as a stopgap

What most enterprise and financial buyers ask for

Best for

New controls, new services, a deal that can't wait

Mature controls, renewals, buyers with formal vendor-risk programs

Here's the rule we'd use. Get a Type 1 first if a customer needs something within about a quarter, or if your controls are new. Go straight to a Type 2 if the customer's questionnaire already says "Type 2" and your controls have been running for a few months.

Big providers use both. Microsoft runs a mid-year Type 1 examination for new services issued since its last Type 2 audit, because "Type 1 audits don't look back over a period of performance" (Microsoft Learn). That's the same logic at a much bigger scale: Type 1 covers what's new, Type 2 covers what's proven.

Picture a 25-person Montreal MSP whose new bank client wants a SOC 2 before it signs the renewal in four months. A Type 2 can't be ready that fast. A Type 1 as of month three, plus a written plan for the Type 2 window, gives the bank's vendor-risk team something real to file under B-10. (A composite, not a client.)

One trap: a Type 1 doesn't count toward your Type 2 window. It just tells your customer the design is right while the clock runs.

Want the steps above run for you? Our SOC 2 readiness and gap work covers scoping, gap closing and evidence packs, then hands a clean file to the CPA firm you choose.

What is SOC 2 in Canada, and which Canadian laws push you toward it?

SOC 2 in Canada is the same AICPA framework your US customers know. The difference is who signs the report and under which standard.

The Toronto skyline and CN Tower seen across Lake Ontario on a bright day, for the section on SOC 2 in Canada and the Canadian laws behind it

Can a Canadian CPA firm issue a SOC 2 report?

Canadian standards don't have a SOC 2-specific standard. As CPABC puts it, "Canadian standards currently do not specifically include reports similar to SOC 2 or SOC 3, however, an engagement under CSAE 3000 could accomplish the same" (CPABC). So a Canadian firm can do the same work under CSAE 3000, using the same trust services criteria. US-style SOC 2 reports are issued under the AICPA's SSAE 18 standard instead, which is the one Microsoft names for its own report.

Which one do you need? It depends on your buyer, and we couldn't find any authoritative statement on how US buyers treat a CSAE 3000 report. So ask your auditor whether the report will be issued under CSAE 3000 or SSAE 18, and ask your biggest customer to confirm in writing that it'll accept that report. That's question three from step 1.

Does any Canadian law require SOC 2 compliance?

No. PIPEDA, Quebec's Law 25 and the provincial health privacy laws don't mention SOC 2. But they explain why your customers keep asking for it:

  • PIPEDA principle 4.1.3 says an organization "is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing", and must use "contractual or other means to provide a comparable level of protection" (Justice Laws). You're the third party. Your SOC 2 report is how they show they checked.
  • PIPEDA principle 4.7 requires "security safeguards appropriate to the sensitivity of the information", including physical, organizational and technological measures. That maps closely to the SOC 2 security criteria.
  • Law 25 (Quebec's private-sector privacy act, P-39.1), s. 18.3 lets a business share personal information with a service provider without consent only if the mandate is in writing and spells out the protection measures the provider must take (LégisQuébec). Expect Quebec customers to attach your SOC 2 report to that contract.
  • Law 25 s. 3.5 requires a business to notify the Commission d'accès à l'information and affected people about a confidentiality incident that presents a risk of serious injury. Your incident response control has to support your customer's duty, not just your own.

Our post on privacy laws in Canada covers these laws in more depth. If you serve Quebec, it's worth running Quebec Law 25 compliance work alongside SOC 2 rather than adding the privacy criterion by default.

What about banks, insurers and Bill C-8?

Federally regulated financial institutions work under OSFI's Guideline B-10 on third-party risk. It tells them to use "a range of audit and information gathering methods (e.g., independent reports provided by third parties, individually performed or pooled audits)" (OSFI B-10). A SOC 2 Type 2 is one of those independent reports. If you sell to a bank, expect the B-10 questions as well as the report. Our financial services page covers that buyer.

Bill C-8, the federal cyber security bill, received Royal Assent on 2026-06-15 (LEGISinfo). Its Critical Cyber Systems Protection Act part wasn't in force when we checked Justice Laws (current to 2026-09-30). When it is, operators in designated sectors will have supplier-risk duties, and a SOC 2 report is one way suppliers answer them. Our Bill C-8 guide tracks the status.

Is ISO 27001 the same as SOC 2?

No, although they overlap a lot. ISO/IEC 27001 is a certification of your information security management system, issued by an accredited certification body. In Canada, the Standards Council of Canada accredits those bodies. SOC 2 is a CPA firm's attestation opinion on specific controls for a specific service.

SOC 2 and ISO 27001 compared

SOC 2

ISO 27001

What you get

An attestation report with an auditor's opinion

A certificate

Who issues it

A licensed CPA firm

An accredited certification body

What it covers

Controls for a defined system and service

Your whole management system, within its declared scope

Sharing

Report under an NDA, SOC 3 public

Certificate is public

Which is better? Neither. It depends on who's asking. If your customers' questionnaires name SOC 2, start there. If they name ISO 27001, which is often the case with European buyers, start with that. Many companies end up with both and reuse most of the controls and evidence. Certificates to the 2013 edition had to move to ISO/IEC 27001:2022 by 2025-10-31, so if a customer sends you a 2013 certificate, that's out of date. Our ISO 27001 page covers the certification route.

Who are the top SOC 2 auditors, and how do you pick one?

There's no official top-10 list. We couldn't find a ranking from the AICPA or CPA Canada, so check who published any "top auditors" list you find. Pick on fit instead:

  1. Licence and standard. The signing firm must be a licensed CPA firm. Ask which licence the signing partner holds and which standard the report will follow (AICPA or CSAE 3000). In BC, for example, CPABC notes that CSAE 3416 work needs the audit category of public practice licence.
  2. Buyer acceptance. Send the firm's name to your biggest customer before you sign. A five-minute email beats a rejected report.
  3. Experience with your stack. Ask for examples of SOC 2 work on your cloud platform and your type of service.
  4. Independence. The firm that designs and runs your controls can't also give the opinion on them under AICPA independence rules. That's why readiness work and the audit usually sit with two different firms. SMEnode does the readiness side. We're not a CPA firm and we don't issue reports.
  5. Red flags. A guaranteed clean opinion, a guaranteed date before they've seen your scope, or no questions about your evidence.

If you're in Toronto, Montreal or Ottawa, our local cybersecurity pages explain how we work with companies in your city.

Common questions about SOC 2 compliance

How do you pass a SOC 2 audit?

Run your controls for the whole period and keep the evidence as you go. An exception means the auditor sampled a control and it didn't run the way your description says, so the fix is boring and reliable: never let a control skip a cycle. A mock audit against your gap list before the window starts is the cheapest insurance you'll buy.

Is it hard to get SOC 2 compliance?

The controls aren't exotic. The hard part is consistency: doing the same review, approval and check every month for six to twelve months, with proof. A small team with good habits can find it easier than a big team with a lot of moving parts.

Is SOC 2 legally required?

Not in Canada or the US. It's a contract requirement. It becomes mandatory the moment a customer writes it into a purchase agreement.

How long does SOC 2 compliance last?

A report doesn't expire on a set date, but buyers check how old the period is, and most will expect a new report every year. Between reports, providers issue bridge letters. Microsoft describes its bridge letters as "self-attestations by Microsoft, not reports based on examinations by the auditor" (Microsoft Learn), so they fill a gap but don't replace the next report.

What drives the cost of SOC 2?

Scope, mostly: the number of systems, locations and criteria in the examination, whether it's a Type 1 or Type 2, and how long the window is. Then there's the internal time to close gaps and collect evidence, plus any tooling you add. Get quotes after you've fixed the scope in step 2, not before.

Bottom line

SOC 2 compliance in Canada follows the same nine steps as anywhere else: confirm the ask, scope tight, pick the criteria, find the gaps, close them, book the auditor early, rehearse, run the window, and keep the cycle going. The Canadian parts are knowing which standard your report is issued under, and understanding that PIPEDA, Law 25 and OSFI B-10 are why your customers keep asking.

Plan on a Type 1 in a few months and a first Type 2 about a year out, and tell your sales team the real dates now.

Ready to put a date on it? Talk to us and we'll map your scope, your gap list and a realistic report date with you. You can also start with the free SOC 2 readiness assessment.

Keep reading

More from Compliance

Browse all articles

Let's connect

A senior SMEnode engineer replies within an hour, 24/7.