The documentation expectation
Canadian privacy law operates on an accountability principle. Under both PIPEDA and Law 25, organizations aren't just required to comply — they're required to demonstrate compliance through documented records. This isn't a theoretical distinction. When a privacy commissioner investigates, when a procurement officer evaluates a vendor, or when a client conducts a third-party risk assessment, the first request is always the same: show us your documentation.
Organizations that can produce structured, current records pass these moments. Organizations that can't start from a position of failure.
Document 1: SaaS vendor inventory with jurisdictional mapping
This is the foundation everything else depends on. A complete register of every SaaS tool your organization uses, mapped to: parent company, parent jurisdiction, CLOUD Act exposure status, data residency location, and data categories processed.
This is not a nice-to-have. Under Law 25, you cannot complete a Transfer Impact Assessment without knowing which tools transfer data cross-border. Under PIPEDA, you cannot demonstrate accountability for third-party processing without knowing who your processors are and where they operate.
Our SaaS inventory guide walks through how to build this step by step.
Document 2: Register of Processing Activities (RoPA)
A RoPA is a structured record of how your organization collects, uses, stores, and shares personal information. It maps data flows across your entire operation — not just SaaS tools, but internal systems, manual processes, and third-party relationships.
Law 25 requires Quebec organizations to maintain what is effectively a RoPA, though the legislation uses the term "inventory of personal information." PIPEDA's accountability principle creates the same practical requirement. GDPR-aligned organizations will recognize this as Article 30 compliance.
A RoPA should document: the categories of personal information held, the purposes for processing, the legal basis, retention periods, who has access, and where data flows cross-border.
Document 3: Transfer Impact Assessments (TIAs) or Privacy Impact Assessments (PIAs)
Every cross-border transfer of personal information should have a documented assessment. In Quebec, TIAs are explicitly required under Law 25 for any transfer outside Quebec. In other provinces and at the federal level, PIAs serve a similar function.
Each assessment should cover: the nature of the data being transferred, the jurisdiction receiving it, the legal framework in that jurisdiction, specific risks (including CLOUD Act exposure), safeguards in place, and the residual risk determination.
If you use 30 SaaS tools and 20 of them are US-based, you need 20 documented assessments. There is no shortcut. Upper Harbour provides a model TIA template to standardize this process.
Document 4: Data Processing Agreements (DPAs)
A DPA is a contract between your organization and each SaaS vendor that governs how personal information is handled. It should specify: what data the vendor processes, the purposes of processing, data retention and deletion terms, security obligations, sub-processor disclosure, breach notification requirements, and audit rights.
Many SaaS vendors offer standard DPAs. Some don't. The absence of a DPA for a tool processing personal information is a compliance gap that regulators will flag. Your inventory should track DPA status for every tool.
Document 5: Incident response and breach notification plan
Both Law 25 and PIPEDA require organizations to maintain a documented process for responding to privacy incidents and notifying affected individuals and regulators. Under Law 25, a breach involving personal information must be reported to the CAI. Under PIPEDA, breaches creating a "real risk of significant harm" must be reported to the OPC.
The plan should document: how incidents are detected, who is responsible for assessment, decision criteria for notification, timelines, and communication templates. This is not the same as an IT incident response plan — it specifically covers privacy obligations.
Document 6: Privacy governance framework
This is the umbrella document that describes your organization's privacy program: who the privacy officer is, what policies are in place, how compliance is monitored, how staff are trained, and how the program is reviewed and updated.
Law 25 requires the designation of a person responsible for the protection of personal information. PIPEDA requires a designated privacy officer. The governance framework documents that these roles exist and describes how they function.
1. SaaS vendor inventory with jurisdictional mapping · 2. Register of Processing Activities (RoPA) · 3. Transfer Impact Assessments or Privacy Impact Assessments for each cross-border tool · 4. Data Processing Agreements with each vendor · 5. Incident response and breach notification plan · 6. Privacy governance framework with designated officer
What regulators actually look for
Privacy commissioners don't expect perfection. They expect evidence of a functioning accountability framework. During an investigation, they look for: documented awareness of data flows, structured risk assessment processes, evidence that assessments were actually conducted (not just templated), a clear chain of responsibility, and evidence that the program is maintained over time — not just created once and forgotten.
The organizations that fare worst in investigations are not the ones with imperfect documentation. They're the ones with no documentation at all.
Getting started
If you're starting from zero, begin with the SaaS inventory. Everything else — TIAs, RoPAs, DPA tracking — depends on knowing what tools you use and where your data flows. HarbourScan produces the first structured record of your SaaS jurisdictional exposure in about 10 minutes. The full report builds on that foundation to generate the compliance documentation described in this guide.