> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Canada PIPEDA Posture Guide
> Map Canada's PIPEDA fair-information principles — consent, safeguards, individual access, breach of security safeguards, and openness — onto the consent ledger, DSAR pipeline, retention, breach register, and subprocessor surfaces you configure on Orbit, alongside the separate CASL anti-spam regime.
# Canada PIPEDA Posture Guide
Canada's **Personal Information Protection and Electronic Documents
Act (PIPEDA)** is the federal private-sector privacy law: ten
fair-information principles that govern how you collect, use, and
disclose personal information in the course of commercial activity.
If you message or call Canadian recipients, PIPEDA sits behind every
record you hold about them — separate from
[CASL](/compliance/casl-canada-anti-spam), the anti-spam statute that
governs whether you may *send*, and separate from the provincial
laws a few provinces run on top of the same consent model.
Everything below is a **tenant-owned control**. Orbit ships the
surfaces — the consent ledger, the DSAR workflow, retention
settings, the breach incident register, the subprocessor registry —
defaults-open; your organization configures them for Canada. PIPEDA
compliance remains your responsibility, and the Office of the
Privacy Commissioner of Canada (OPC) enforces it regardless of what
any toggle says. This page is documentation, **not legal advice** —
have counsel review your consent capture language, your retention
schedule, and whether PIPEDA or a substantially-similar provincial
law (Quebec Law 25, Alberta PIPA, BC PIPA) governs any given
recipient.
***
## 1. PIPEDA vs CASL — two separate obligations
Canadian operations routinely conflate the two federal regimes. They
answer different questions:
| Regime | What it governs | Where it lives on Orbit |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| **CASL** (anti-spam, CRTC-enforced) | Whether you may *send* a commercial electronic message — express/implied consent tiers, identification, unsubscribe | [CASL (Canada's Anti-Spam Legislation)](/compliance/casl-canada-anti-spam) |
| **PIPEDA** (privacy, OPC-enforced) | What you *owe the person* behind each record — meaningful consent, safeguards, access, accountability, openness | This page |
A CASL-compliant campaign can still breach PIPEDA: the message went
out with valid implied consent, but the record behind it has no
purpose limitation, no retention window, and no answer when the
recipient asks what you hold. Conversely, an immaculate privacy
posture does not authorise a single send — CASL judges dispatch;
PIPEDA judges stewardship. You need both, and Orbit keeps the
surfaces separate on purpose.
***
## 2. The PIPEDA surface map
PIPEDA codifies ten fair-information principles
(accountability, identifying purposes, consent, limiting collection,
limiting use/disclosure/retention, accuracy, safeguards, openness,
individual access, challenging compliance). This table maps each
principle a Canadian reviewer actually tests to the Orbit control
that holds it:
| PIPEDA principle | Orbit control | Deep page |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Meaningful consent** — informed consent appropriate to the sensitivity of the information, with a named purpose | `POST /compliance/consent` records the per-channel opt-in with `purpose`, `lawful_basis`, `consent_text_version`, and a `consent_proof_url` on every row; the unknown-consent default policy can refuse marketing traffic until a row exists | [Consent Management](/compliance/consent-management), [Consent default policy](/compliance/consent-default-policy) |
| **Individual access (requests)** — the person can see, correct, and challenge their information | The DSAR pipeline files the request with `applicable_jurisdiction: "pipeda"` and applies PIPEDA's **30-day** clock; a completed `delete` flows into suppression so the contact does not re-enter sends | [Data Subject Access Requests (DSAR)](/compliance/dsar) |
| **Safeguards** — security appropriate to sensitivity, plus limiting retention | Per-domain retention windows under `PUT /compliance/data-retention`; the residency answer per data class documented against the platform geography | [Data Retention Policy](/compliance/data-retention-policy), [Data Residency Overview](/compliance/data-residency-overview) |
| **Accountability + breach of security safeguards** — the *Breach of Security Safeguards Regulations* require a **Report to the OPC** and notification to affected individuals when the breach poses a **real risk of significant harm (RROSH)**, plus a 24-month record of every breach | The breach incident register opens the incident, stamps each notification, and produces the **72-hour attestation** — `discovered_at` anchors the window and the attestation proves when the notification record went out | [Breach incident register](/compliance/breach-incident-register) |
| **Openness** — make your privacy practices, processors, and contracts easy to find | The self-serve DPA (preview, e-signature, executed copy, version tracking) and the published subprocessor registry answer "who processes the data and under what contract" | [Data Processing Agreement](/compliance/data-processing-agreement), [Subprocessor registry](/compliance/subprocessor-registry) |
The accountability principle also asks where your processing answer
is *written down*: the [privacy register](/compliance/privacy-register)
records each activity's purpose, lawful basis, and retention window,
and PIPEDA appears there as a first-class jurisdiction exactly as it
does on the DSAR surface.
PIPEDA's mandatory breach-record duty is broader than its
notification duty: you keep a record of **every** breach of
security safeguards for 24 months, even the ones you assess as
below the RROSH threshold. Open each incident in the register when
you detect it, close below-threshold incidents with
`notification_required: false` and the RROSH rationale in
`remediation`, and the register *is* the 24-month record.
***
## 3. Worked sequence — an access or erasure request
A Canadian recipient emails your privacy address asking what you
hold about them, or asking to be erased. File it under PIPEDA from
the first call so the SLA tracker applies the statutory clock:
```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar \
-H "X-API-Key: dv_live_sk_..." \
-H "Content-Type: application/json" \
-d '{
"subject_email": "jordan@example.ca",
"requester_email": "privacy@yourcompany.ca",
"applicable_jurisdiction": "pipeda",
"request_type": "delete",
"requester_statement": "Canadian recipient requested erasure of personal information under PIPEDA Principle 4.9 (challenging compliance); identity verified by support."
}'
```
What happens next, and what evidence each step leaves:
1. **The 30-day clock starts.** `applicable_jurisdiction: "pipeda"`
puts the request in the DSAR queue on PIPEDA's statutory response
window, alongside `gdpr`, `ccpa`, `lgpd`, `pdpa`, and `dpdp`. If
the request arrived generically, reclassify it after intake — the
jurisdiction decides which deadline counts.
2. **Erasure feeds suppression.** When a `delete` completes, the
outcome flows into your suppression list, so the erased Canadian
contact does not re-enter marketing sends through a later CSV
import — see [Opt-Out & Suppression](/compliance/opt-out-suppression).
3. **Retention sweeps before requests arrive.** PIPEDA's
limiting-retention clause only defends itself if data aged out on
schedule. Configure the
[retention policy](/compliance/data-retention-policy) per data
domain and individual requests mostly find nothing left to erase.
For an access (`know`) request the same intake applies — swap
`request_type` to `know` and fulfil through the export the DSAR
pipeline produces.
***
## 4. Worked sequence — a breach with a real risk of significant harm
A support agent's credential is phished and a mailbox with customer
email threads is read. You assess the breach against RROSH — the
sensitivity of the information and the probability it will be
misused — and conclude reporting thresholds are met. The register
carries the record; **you** carry the Report to the OPC and the
individual notifications.
1. **Open the incident.**
`POST /compliance/breach-incidents` — the incident lands as
`detected` and `discovered_at` anchors the attestation clock:
```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/breach-incidents \
-H "X-API-Key: dv_live_sk_..." \
-H "Content-Type: application/json" \
-d '{
"title": "Support mailbox accessed from an unauthorised account",
"description": "An employee credential was used from an unmanaged device; mailbox contained customer email threads.",
"severity": "high",
"affected_data_subjects": 412,
"affected_records": 1830,
"data_categories": ["email address", "message content", "contact details"],
"notification_required": true
}'
```
2. **Assess.** `PATCH /compliance/breach-incidents/{id}` with
`status: "under_assessment"`, refining the affected counts as
forensics progress. Record the RROSH reasoning in `remediation`
— the sensitivity/probability assessment is exactly what an OPC
review asks for.
3. **File your Report to the OPC yourself.** You submit through the
OPC's reporting channel, then stamp the register:
`POST /compliance/breach-incidents/{id}/notifications` with
`party: "supervisory_authority"` and the OPC case reference —
the same move the GDPR walkthrough makes with `authority_portal`;
carry `method: "other"` or your actual channel when the report
went outside a portal. Repeat with `party: "data_subjects"` for
the individual notifications PIPEDA also requires at RROSH.
4. **Pull the attestation.** `GET /compliance/breach-incidents/{id}/attestation`
returns the discovery instant, the computed deadline, both
parties' notification timestamps, and a `compliant` verdict —
the **72-hour attestation** that turns "we reported promptly"
from a claim into a timestamped proof. Attach it to your evidence
binder.
Cross-border chains (Ontario → Quebec → British Columbia recipients
in one breach) mean the Report, the Quebec CAI filing, and the
Alberta OIPC filing may all be owed — the register records each
party separately, counsel decides which thresholds apply.
***
## 5. Boundary — what Orbit never does for you
State these out loud in any posture review, because they define the
edge of the platform:
* **Orbit never reports to the OPC for you.** The register records
and attests; the Report to the Privacy Commissioner, the Quebec
CAI, or the Alberta OIPC leaves through your legal channels. Same
for the individual notifications.
* **CASL consent is not PIPEDA consent.** A CASL implied-consent
tier (existing business relationship, conspicuously published
address) answers "may we send" — it does not stand in for
PIPEDA's meaningful-consent principle behind the record. Track
both; see
[CASL (Canada's Anti-Spam Legislation)](/compliance/casl-canada-anti-spam).
* **Provincial carve-outs are yours to route.** PIPEDA applies
federally and to federally-regulated industries, and to
inter-provincial trade; Quebec Law 25, Alberta PIPA, and BC PIPA
carry their own rights and sometimes stricter clocks. The DSAR
surface files `pipeda` for the federal route — the provincial
decision is a legal classification Orbit never makes.
* **Nothing here gates sending by itself.** Every control on this
page defaults open; an empty register exports as an empty
register. Assemble the posture first, export second.
***
## Frequently asked questions
**Does a completed CASL posture give me PIPEDA compliance?**
No. CASL covers the dispatch — consent tier, identification,
unsubscribe. PIPEDA judges the stewardship behind the record:
purpose limitation, safeguards, retention, access, and breach
reporting. A CASL-clean campaign whose records have no retention
window still fails a PIPEDA review.
**Which DSAR clock does a Canadian request carry?**
30 days — file or reclassify with
`applicable_jurisdiction: "pipeda"` and the SLA tracker applies the
federal statutory window.
**Do I report every breach to the OPC?**
No — notification and the OPC Report attach when the breach poses a
real risk of significant harm. But the 24-month **record-keeping**
duty covers every breach, including the ones assessed below RROSH;
close those in the register with `notification_required: false` and
the assessment rationale recorded.
**Does Orbit decide my Canadian privacy posture?**
No. Orbit ships defaults-open controls — the consent ledger, the
DSAR pipeline, retention settings, the breach register — for your
organization to configure. Tenant-owned posture, explicitly.
***
This page is documentation, not legal advice — an engineering map
of the Orbit surfaces, not a legal opinion. PIPEDA breaches
attract OPC findings and can be liable to fines under the
Breach of Security Safeguards Regulations for the record-keeping
duty alone; have counsel review your consent language, RROSH
threshold, and provincial routing before you send to Canadian
recipients.
***
## Related references
* [CASL (Canada's Anti-Spam Legislation)](/compliance/casl-canada-anti-spam)
— the separate CRTC-enforced anti-spam regime for dispatch.
* [Consent Management](/compliance/consent-management) — the consent
record contract behind meaningful consent.
* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the
access/erasure surface where `pipeda` and its 30-day clock live.
* [Breach incident register](/compliance/breach-incident-register) —
the RROSH record and 72-hour attestation.
* [Data Retention Policy](/compliance/data-retention-policy) and
[Data Residency Overview](/compliance/data-residency-overview) —
the safeguards pair.
* [Data Processing Agreement](/compliance/data-processing-agreement)
and [Subprocessor registry](/compliance/subprocessor-registry) —
the openness pair.
* [Privacy Register](/compliance/privacy-register) — the documented
processing activities accountability asks for first.
* [Compliance evidence binder](/compliance/evidence-binder) — the
quarterly review artifact the attestation rolls up into.
* [API Reference → Compliance](/api-reference/endpoints/compliance) —
full request/response schemas (regenerated from the live API).