Instrument-to-control map
A working reference: which instrument applies to you, what it requires in substance, and the control organizations commonly put in place against it. The summaries below are mine, not quotations — verbatim provision text and links to the official consolidations are still being added, and the rows awaiting them say so. Check anything here against the source before relying on it.
Why this table exists. The single most commonly misstated point in
this market is whether British Columbia's private-sector privacy law requires you to report a breach.
It is worth getting right before you buy anything against it. See
the breach-reporting explainer.
| Instrument and provision | What the provision says | Control commonly used | Evidence a reader accepts |
|---|---|---|---|
| PIPEDA — breach of security safeguards reporting (federal, private sector) | Requires reporting to the Privacy Commissioner and notification to affected individuals where a
breach creates a real risk of significant harm, and requires records of breaches to be kept.
[Verify provision reference and paste the exact quoted text with a link to the official consolidation.] |
Breach assessment procedure with a documented risk-of-harm test; a breach register; named decision-maker; retention of records. | The register itself, with dated entries — including entries assessed and closed as non-reportable. |
| EU AI Act — Regulation (EU) 2024/1689 (reaches you if an AI system you provide or use has output relied on in the EU) | Obligations phase in rather than landing at once. In force 1 August 2024;
prohibited practices and the AI-literacy duty applied from 2 February 2025;
general-purpose AI model obligations from 2 August 2025.
The high-risk dates have already been amended once and now run later than most
summaries state — check the current text before you rely on a date, and
treat any timeline written in 2024 as superseded.
Source: the consolidated Regulation. This row is the one most likely to move again; it is dated on purpose. |
An inventory of where models are used and what leaves your estate; provider terms and retention; human oversight where output affects a person; logging that shows what was sent and returned. | The system-level record: which provider, which data, which retention, who reviews the output. Not a policy stating that AI is used responsibly. |
| BC PIPA — security of personal information (BC, private sector and non-profits) | Requires reasonable security arrangements to prevent unauthorized access, collection, use,
disclosure, copying, alteration, disposal or similar risks. It does not impose a
mandatory breach-notification duty. Reporting to the OIPC is voluntary, and the OIPC
has recommended that mandatory notification be introduced.
Source: BC PIPA s. 34 for the security requirement; the absence of a notification duty is an absence in the Act itself — there is no provision to cite, which is why the OIPC has recommended one be added. [Paste the exact quoted wording of s. 34 with a link to the BC Laws consolidation.] |
Documented safeguards proportionate to sensitivity: access control, encryption at rest and in transit, logging, retention and disposal. | Configuration exports and access reviews, dated. Not a policy asserting the safeguard exists. |
| BC FIPPA — public bodies (and their suppliers, by flow-down) | Public bodies are subject to a mandatory notification duty for privacy breaches meeting the
statutory threshold, and to privacy impact assessment requirements. Suppliers usually inherit
these through the contract schedule rather than directly from the Act.
[Verify provision references and paste quoted text with a link.] |
Contractual breach-notification clock to the public body; PIA support; controls matching the security schedule. | The executed schedule plus your evidence against each of its clauses. |