If you have been looking for a SOC 2 compliance checklist Canada teams can actually work through, this is it. SOC 2 is not a certificate and there is no pass mark. It is an attestation report written by a CPA firm against the AICPA Trust Services Criteria, and what you receive at the end is a practitioner's opinion on whether your controls were designed properly and, in a Type 2, whether they operated over a period of time.

That distinction changes how you prepare. You are not studying for an exam. You are building a paper trail that an auditor can test independently, and most of the work happens months before anyone opens a report template.

Why the Canadian version of this checklist is different

SOC 2 itself is an American standard, and every checklist you find online is written for an American company. The controls do not change at the border, but three things around them do.

First, your privacy obligations run on Canadian law. If you handle personal information in the course of commercial activity, PIPEDA applies to you whether or not you ever pursue SOC 2. The Office of the Privacy Commissioner of Canada requires organizations to report breaches of security safeguards that create a "real risk of significant harm" to individuals, notify the people affected, and keep records of all breaches for two years. Those breach records are exactly the kind of evidence a SOC 2 auditor asks to see, so building the process once serves both purposes.

Second, your buyers ask different questions. Canadian enterprise and public sector procurement teams routinely ask where data is stored and processed before they ask for the report itself. Your SOC 2 system description needs to answer the data residency question in plain terms, because a report that says nothing about it will just generate a follow up questionnaire.

Third, you have a Canadian security baseline available to you. The Canadian Centre for Cyber Security publishes Baseline Cyber Security Controls for Small and Medium Organizations, aimed at organizations with fewer than 499 employees, built on an 80/20 approach and structured as 13 baseline controls covering incident response, patching, malware defence, secure configuration, authentication, training, backups, mobile security, perimeter defence, cloud services, website security, access control and portable media. It is not a SOC 2 framework and it will not satisfy an auditor on its own. It is a very good floor to reach before you start, and it is free.

Step 1: Fix your scope before you do anything else

Scope is the single decision that determines how much work follows. Write down which product, which environments and which supporting systems are in the report, and just as importantly what is out. A team that scopes one production platform and its cloud infrastructure has a manageable project. A team that scopes "the company" has a project that never finishes.

Your scope statement should name the system, the infrastructure it runs on, the data it handles, the people who operate it and the third parties involved in delivering it. Everything downstream in this checklist inherits from that paragraph.

Step 2: Choose your trust services categories

The AICPA framework covers five trust services categories: security, availability, processing integrity, confidentiality and privacy. The official SOC 2 report title itself is phrased as an examination of controls "Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy", which tells you these are selected rather than automatically all applied.

In practice every engagement we have supported starts with security, and the other four are added only when a customer contract or a regulatory obligation actually requires them. Availability matters if you sell an uptime commitment. Confidentiality matters if you hold customer data covered by an NDA. Privacy is the heaviest of the four and overlaps significantly with your PIPEDA programme, so add it deliberately rather than by default.

Step 3: Build the governance evidence

Auditors test governance first because it is where most young companies are thinnest. You need a documented information security policy set approved by leadership, a defined owner for security, evidence that policies are reviewed on a schedule, and a risk assessment that was actually performed rather than downloaded.

The risk assessment is the piece teams underestimate. It needs to identify the risks to your system, rate them, and connect each significant risk to a control you operate. If your risk register and your control set have no visible relationship, expect a finding.

Step 4: Access control

Work through the full lifecycle. Joiners get access through an approved request. Movers have access adjusted when their role changes. Leavers are removed promptly, and you can prove the timing. Add multi factor authentication on everything that touches production and on your identity provider, unique named accounts with no shared logins, least privilege on production data, and a documented access review performed at a set interval with the reviewer and date recorded.

The evidence here is not the policy. It is the ticket history, the review records and the offboarding timestamps.

Step 5: Change management and development

Every production change should be traceable: a ticket, a peer review, a test result and an approval before release. Separate your environments, keep production data out of development, and make sure the person who wrote the change is not the only person who approved it. If you deploy continuously, your pipeline logs are your evidence, so confirm they are retained long enough to cover the audit window.

Step 6: Vendor and subservice management

Your cloud provider, your payment processor and your monitoring tools all sit inside your control environment. Maintain a vendor inventory, classify vendors by the sensitivity of the data they touch, collect their SOC 2 or ISO 27001 reports at onboarding, review them annually, and record what you concluded. If you carve out a subservice organization in your report, you also have to document the complementary controls you expect them to run.

Step 7: Monitoring, logging and incident response

You need centralized logging for the systems in scope, alerting that a human actually receives, an incident response plan that names roles, and evidence that the plan has been exercised. A tabletop exercise with dated notes counts. An untested plan in a folder does not.

Tie this back to your PIPEDA breach process so a single incident produces one investigation record that satisfies both the auditor and the Privacy Commissioner's record keeping requirement.

Step 8: Resilience and backups

Document your backup schedule, prove restores actually work by testing them and keeping the results, and write a business continuity and disaster recovery plan that reflects the recovery objectives you have promised customers. If you selected the availability category, this section becomes central rather than supporting.

Step 9: Decide Type 1 or Type 2

A Type 1 report assesses whether controls are suitably designed as at a specific date. A Type 2 assesses whether those controls also operated effectively across a period. Buyers generally want Type 2, but a Type 1 first is a reasonable path if you need something in a sales cycle quickly and want an early read on design gaps before committing to an observation window.

Step 10: Select your auditor and run a readiness assessment

SOC 2 reports must be issued by a licensed CPA firm. Ask candidate firms how many reports they issue a year, who actually performs the fieldwork, and how they handle evidence collection. Before fieldwork begins, run a readiness assessment against the criteria so gaps surface while there is still time to fix them rather than during testing. Our walkthrough of how to prepare for a SOC 2 audit in 90 days covers the sequencing, and how to get SOC 2 certified in Canada covers what happens once the auditor is engaged.

One note if your product ships AI features: anything your model can reach is now inside your system boundary, and auditors are starting to ask how you test it. Our sister platform SecuritAI covers AI red teaming and runtime controls for teams in that position.

Where to start this week

Pull your scope statement, your access review records and your last restore test. Those three artifacts tell you honestly how far along you are. If any of them do not exist yet, that is your first week of work, not your auditor's problem to discover.

You can see how the full programme fits together on our SOC 2 compliance in Canada page, and the SOC 2 and ISO 27001 Readiness Checklist in our free resource library gives you the control by control version of this article to work through with your team.

Frequently asked questions

Is SOC 2 mandatory in Canada?

No. SOC 2 is a voluntary attestation, not a legal requirement. What is mandatory is PIPEDA if you handle personal information in commercial activity, including the obligation to report breaches that create a real risk of significant harm and to keep breach records for two years. SOC 2 becomes effectively mandatory only when your customers make it a condition of buying.

Does a Canadian company need a Canadian auditor for SOC 2?

The report must be issued by a licensed CPA firm. Canadian firms issue SOC 2 reports and are generally the practical choice for a Canadian company, because they understand the PIPEDA overlap and the data residency questions your buyers will ask. A US firm can also issue the report, and the criteria applied are identical either way.

How does SOC 2 relate to ISO 27001?

They overlap heavily in substance and differ in form. ISO 27001 is a certification against a management system standard with a defined set of Annex A controls. SOC 2 is an attestation report where the auditor expresses an opinion against the trust services criteria. Most of the underlying work, including access control, change management, vendor management and incident response, serves both. If you expect to need both, build the evidence once and map it to each.

Can I use the Canadian Centre for Cyber Security baseline controls to get SOC 2 ready?

Partly. The 13 baseline controls are a strong security floor for organizations under 499 employees and closing them will remove a lot of obvious gaps. They are not mapped to the trust services criteria and they do not address the governance, risk assessment and evidence retention requirements an auditor tests, so treat them as preparation rather than as a substitute.

What is the most common reason a first SOC 2 goes badly?

Missing evidence rather than missing controls. Teams often operate a control correctly but cannot show it happened on a given date, particularly access reviews, restore tests and vendor reviews. Decide at the start of your observation window how each control produces a dated, retrievable artifact.

References

AICPA and CIMA, SOC 2 for Service Organizations: Trust Services Criteria
AICPA and CIMA, 2017 Trust Services Criteria with Revised Points of Focus, 2022
Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards
Canadian Centre for Cyber Security, Baseline Cyber Security Controls for Small and Medium Organizations

SOC 2 Compliance Checklist Canada: The 2026 Readiness Guide