Choosing your App's compliance posture
When you create an App in Septenar, the platform asks two questions: what kind of data the App will collect, and where the participants will be located. A third axis — where your organization itself sits — is read silently from your Account settings. Together these three answers determine the App's compliance posture: which privacy laws apply, what labels surface to your team and to participants, which processor agreements get generated, and what the platform will require before you can publish.
This Guide explains what those questions mean and what the answers do. It does not decide for you. The decision depends on facts only you know.
The three things the platform is using
| Axis | Where it comes from | What it determines |
|---|---|---|
| Controller jurisdiction — where your organization is | Account.country + Account.province from your Account settings | Your home regulator, your privacy officer's reporting line, your organization's sub-processor obligations |
| Participant jurisdictions — where the people you survey live | App creation, Step 2 | Most of the framework selection (see below) |
| Sector — the kind of data the App collects | App creation, Step 1 | Whether parallel regimes (PHIPA, HIA, HIPAA, TCPS 2) attach on top of the privacy law |
The platform asks only about sector and participant jurisdictions during App creation. Controller jurisdiction is set once, at the Account level.
Why participant jurisdiction matters more than where your organization sits
Canadian privacy law follows the data subject, not the organization holding the data. An Ontario-registered research firm surveying Quebec residents is bound by Quebec's Law 25 with respect to those participants. Its Ontario address does not change that.
This is settled in recent case law. Clearview AI Inc. v. Alberta (Information and Privacy Commissioner) (ABKB 2025) confirmed that Alberta's PIPA applies to out-of-Alberta organizations on a real-and-substantial-connection test — offering services to Albertans or collecting their personal information is sufficient connection. Clearview AI Inc. v. British Columbia (Information and Privacy Commissioner) (BCCA, March 2026) reached the same conclusion for BC's PIPA, with the court explicitly stating that BC PIPA "regulates the conduct of organizations that collect personal information of persons with a direct link to BC." Quebec's Law 25, by its own text (s. 1), applies whenever the organization collects personal information about a person residing in Quebec.
Three implications follow:
- An Ontario research firm surveying Quebec residents complies with Law 25.
- An Alberta HR firm surveying employees in BC complies with BC PIPA.
- A pan-Canadian survey complies with every implicated framework simultaneously — PIPEDA at the federal baseline, plus Law 25 if any Quebec residents are included, plus AB PIPA and BC PIPA on top.
This is why the platform asks separately about participant jurisdictions: forcing them to inherit the controller's location would be wrong for a sizeable share of real Canadian survey work.
Why sector adds a different layer
Privacy law is the floor. Some sectors have parallel regimes on top.
- Healthcare data in Ontario can trigger PHIPA (the Personal Health Information Protection Act), which adds custodian-to-information-manager obligations and a stricter breach-reporting timeline.
- Healthcare data in Alberta can trigger HIA (the Health Information Act), with its own custodian framework and breach-notification provisions.
- Healthcare data in the United States triggers HIPAA, with the Business Associate Agreement requirements and 6-year documentation retention.
- Research data anywhere brings TCPS 2 — the Tri-Council Policy Statement on the ethical conduct of research involving humans — into the picture. Chapter 5 governs privacy, Chapter 8 covers multi-jurisdictional review, Chapter 9 covers research involving First Nations, Inuit, and Métis peoples.
The custodian wrinkle
A point that surprises non-healthcare organizations: PHIPA s. 3 and HIA s. 1 define "custodian" as a closed list — hospitals, long-term care homes, pharmacies, regulated health practitioners, the Minister. A research firm collecting health-related survey data in Ontario is not automatically a PHIPA custodian. It becomes PHIPA-bound either as an agent of a custodian (PHIPA s. 17) or by receiving personal health information under PHIPA s. 44's research-disclosure regime with REB approval.
This is why, when you select sector = healthcare and your participants include Ontario or Alberta residents, the platform asks a follow-up: Are you (or are you acting as an agent of) a custodian under the relevant provincial law? If yes, the corresponding Information Manager Agreement (PHIPA IMA for Ontario, HIA IMA for Alberta) attaches. If no, your App is governed by general privacy law with health-data sensitivity overlays — but the custodian-specific obligations do not attach.
HIPAA follows the same pattern. It triggers only when participants are in the US, sector is healthcare, and you assert that your organization is or acts for a Covered Entity.
The survey-level dimension: data sensitivity
The three App-level answers set the frame. A fourth answer lives on each survey: data sensitivity — what the most sensitive answer in the survey would reveal about a participant. Four levels: Low (opinions and feedback, nothing about the person), Moderate (professional or demographic information), High (could cause harm if linked to a person's identity), Health (health information — screeners, outcomes, care experience).
Every survey type carries an honest default — a mental-health screener starts at Health, an exit interview at High, an event-feedback form at Low — and you can adjust it at creation or in Settings → Details while the survey is a draft. Once published, it is frozen: participants and ethics reviewers relied on it.
Sensitivity does two jobs.
It makes obligations proportionate. A Privacy Impact Assessment is required before publish only when a Law 25 or HIPAA App hosts a High- or Health-sensitivity survey; at lower sensitivity it is recommended, not blocking. A Moderate-sensitivity satisfaction survey and a depression screener in the same App owe different things — which is the Commission d'accès à l'information's own proportionality principle, applied per survey rather than per App.
It enforces a ceiling. A PIPEDA-baseline App can host up to High sensitivity. Health data needs an App at Law 25 level or above. The protections health data requires are structurally App-level — the audit trail, the retention clocks, the breach-notification fan-out, and the signed data-handling agreements all key on the App's compliance level — and cannot be bolted onto a single survey. When a survey's sensitivity exceeds its App's ceiling, the platform routes you to create an App that can host it (sector and jurisdictions pre-filled) and copy the draft over. It never upgrades the existing App in place: the other forms in that App were built and published under its current rules.
High sensitivity stays legitimate at PIPEDA baseline, with counsel rather than a wall — the platform recommends anonymous tokens and a PIA for High-sensitivity work at any level. An Ontario nonprofit's staff-experience survey with hard questions doesn't need a health-data App; it needs care with identity.
The platform also checks the content against the declaration. If question text drifts into Law 25's sensitive categories — health, racial or ethnic origin, religion, sexual orientation, biometric or genetic data, judicial history — while the declared sensitivity sits lower, the builder sees a non-blocking review notice with a path to the sensitivity setting.
Four scenarios
The same person could ask "what compliance level do I need?" four different ways and get four different answers — each correct for their situation.
A. A Toronto Community Health Centre running internal evaluations
What you tell the platform: Account in Ontario. Sector = healthcare. Participants = Ontario only. Custodian = yes (CHCs are PHIPA custodians).
What the platform shows back:
PHIPA-aligned · PIPEDA-compliant
Audit trail retained 1 year. Privacy Impact Assessment required.
Processor agreement available: PHIPA Information Manager Agreement.
What gets required before publish: PIA on file for any survey collecting sensitive health information. Consent text presented to participants. Audit logging on by default.
What does not apply: No French gate (no Quebec participants). No BAA (no US participants). No REB package required (sector is healthcare, not research — though CHC evaluation work often goes through internal review anyway).
B. An Alberta HR firm surveying employees across AB + BC + ON
What you tell the platform: Account in Alberta. Sector = general. Participants = Alberta, British Columbia, Ontario.
What the platform shows back:
PIPA-aligned (Alberta participants)
PIPA-aligned (BC participants)
PIPEDA-compliant (Ontario participants + federal baseline)
Audit trail covered by application logs.
Processor agreements available: standard DPA, AB PIPA addendum, BC PIPA addendum.
What gets required before publish: Consent text presented. That is the floor.
What does not apply: No PIA required (no Law 25 implicated — no Quebec participants). No French gate. No custodian question (sector is general). No REB package.
C. An Ontario-based research firm running a national survey
What you tell the platform: Account in Ontario. Sector = research. Participants = Any Canadian province or territory (the pan-Canadian default). Custodian question does not fire (research, not healthcare).
What the platform shows back:
Law 25 compliant (Quebec participants)
PIPA-aligned (Alberta participants)
PIPA-aligned (BC participants)
PIPEDA-compliant (federal baseline + non-Law-25 provinces)
TCPS 2-aligned — multi-jurisdictional review (Chapter 8 applies)
French-language survey forms required before publishing to Quebec participants.
Privacy Impact Assessment required for High- and Health-sensitivity surveys;
recommended otherwise.
REB approval reference required before publish.
Cross-border §17 assessment required for any sub-processor outside Quebec.
Breach notification: 72-hour clock (CAI) is the shortest applicable deadline;
notifications fan out to CAI, OPC, OIPC Alberta on a breach affecting
those jurisdictions.
Processor agreements: Law 25 outsourcing, PIPEDA DPA,
AB PIPA addendum, BC PIPA addendum, TCPS 2 research addendum.
What this scenario demonstrates: how a single national survey produces a posture that satisfies every implicated framework simultaneously. The strictest applicable standard from each framework applies to the whole App. Law 25 sets the bar for the audit trail and the PIA expectation. Bill 96 sets the language posture (French required for QC participants). The CAI's 72-hour breach-notification practice sets the response deadline.
If your research involves First Nations, Inuit, or Métis participants, the platform additionally surfaces a TCPS 2 Chapter 9 + OCAP™ pre-publish checklist (community consent, data sovereignty, return-of-data commitments). A dedicated Guide for Indigenous research is in development.
D. A Quebec community foundation surveying Quebec residents
What you tell the platform: Account in Quebec. Sector = general. Participants = Quebec only.
What the platform shows back:
Conforme à la Loi 25 · PIPEDA-compliant
Journal d'audit conservé pendant 1 an. ÉFVP requise pour les sondages
de sensibilité Élevée ou Santé.
Entente d'impartition Loi 25 disponible en téléchargement.
What gets required before publish: French-canonical content (your participants are in Quebec; Bill 96 governs the language posture). PIA on file for High- and Health-sensitivity surveys. Audit logging on by default.
Note: Quebec's regime is detailed enough to warrant its own Guide — see Surveying participants in Quebec under Law 25.
The Pan-Canadian default
When you create a new App, the participant-jurisdictions question defaults to Any Canadian province or territory. This is deliberate.
Forcing a builder to enumerate 13 provinces and territories before they understand what their research design will look like is operationally absurd. National surveys, multi-jurisdictional research, and surveys across mobile workforces are common enough that the inclusive default reflects the actual shape of Canadian survey work. If your survey turns out to be province-specific, you narrow before you publish.
When pan-Canadian is selected, the platform applies the strictest-framework rule: the App must satisfy every implicated framework, and where two frameworks disagree, the stricter one governs. In practice that means:
- Law 25 sets the bar. Once Quebec residents are in scope, Law 25 is the upper bound of Canadian private-sector privacy law. Designing to Law 25 satisfies PIPEDA, AB PIPA, and BC PIPA.
- Bill 96 sets the language posture. French becomes canonical for material presented to Quebec participants. Publishing without complete French translation is blocked when Quebec is in the participant set.
- The CAI's 72-hour practice sets the breach clock. Quebec's Commission d'accès à l'information notifies the regulator on confidentiality incidents within 72 hours as a matter of practice — the shortest applicable Canadian deadline. (The statute itself says "with diligence"; the 72-hour figure is regulator practice.)
Septenar hosts in ca-central-1, the AWS region in Montreal. For data-residency purposes, this is within Quebec — which means the Law 25 § 17 cross-border assessment requirement is about sub-processors (Stripe, the email provider, etc.), not about the platform itself.
What the customer-facing labels mean
When the platform displays a compliance label, it names the law by its public name — what a careful reader would search for — rather than the platform's internal enforcement enum. The labels you might see on your App:
| Label | The law behind it | What it means for you |
|---|---|---|
| PIPEDA-compliant | Personal Information Protection and Electronic Documents Act (federal). Regulator: Office of the Privacy Commissioner of Canada. | The federal baseline for commercial activity. Applies to every Canadian App. |
| PIPA-aligned (Alberta) | Alberta's Personal Information Protection Act. Regulator: OIPC Alberta. | Applies whenever you have Alberta residents in your participant set. Mandatory breach notification under s. 34.1. |
| PIPA-aligned (BC) | British Columbia's Personal Information Protection Act. Regulator: OIPC BC. | Applies whenever you have BC residents. Breach notification is currently voluntary; OIPC BC has called for statutory reform. |
| Law 25 compliant / Conforme à la Loi 25 | Quebec's Act respecting the protection of personal information in the private sector (s. 1). Regulator: Commission d'accès à l'information. | Applies whenever Quebec residents are in your participant set, regardless of where your organization sits. The strictest Canadian private-sector privacy regime. |
| PHIPA-aligned | Ontario's Personal Health Information Protection Act (s. 3). Regulator: IPC Ontario. | Applies when you (or the customer you act for) are a custodian under PHIPA's closed-list definition, surveying Ontario participants on health-related matters. |
| HIA-aligned | Alberta's Health Information Act (s. 1, s. 66). Regulator: OIPC Alberta. | Applies on custodian assertion for Alberta health-data work. |
| HIPAA compliant | US Health Insurance Portability and Accountability Act (45 CFR 164). Regulator: HHS Office for Civil Rights. | Applies to US healthcare with custodian assertion. Requires a Business Associate Agreement and US data residency. |
| TCPS 2-aligned | Tri-Council Policy Statement: Ethical Conduct for Research Involving Humans, Chapters 5, 8, 9. | Applies whenever sector = research. Chapter 8 covers multi-jurisdictional REB review; Chapter 9 covers research involving First Nations, Inuit, and Métis peoples. |
| Coverage deferred | — | The platform does not yet support compliance for this jurisdiction or sector. You will be invited to book a setup conversation if your situation requires it. |
The labels are descriptive, not promotional. A reader who knows their domain will recognize what each name signals; a reader who doesn't can search the public sources directly.
What you can change later, and what costs more to change
The compliance posture is computed from your three answers. Changing the answers recomputes the posture — with consequences that scale to how much was already in flight.
- Adding or removing a participant jurisdiction. Recomputes immediately. Adding Quebec to an App that did not previously include Quebec triggers the French-translation gate before your next publish, prompts a PIA if sensitive categories are involved, and may push the tier requirement to Core.
- Changing sector. Recomputes. The platform shows a banner reminding you that the historical audit retention reflects the prior level — for example, if an App was at LAW_25 for 8 months under sector = healthcare and you switch to sector = general, the audit rows from those 8 months are retained on Law 25's clock; new rows write on the recomputed clock.
- Account-level country or province change. Available only via admin action. Affects every App in the Account, with per-App migration confirmation.
- Custodian assertion. Flippable. Asserting custodian status for an Ontario healthcare App switches the available processor agreement from "DPA + health overlay" to "PHIPA Information Manager Agreement."
Compliance level is mutable, but mutability does not undo prior obligations. Records you have already collected sit on the clock under which they were collected.
Common questions
What if I'm not sure where my participants will be? Leave the default (Any Canadian province or territory). Pan-Canadian is the inclusive case — it applies every Canadian framework that could plausibly apply. Narrowing later is straightforward; expanding later triggers recomputation and may require additional work (French translation, PIA) before your next publish.
What if my participants include some in the US? Add United States to the participant set. If your sector is general, the platform will surface a "Coverage deferred" note and invite you to book a setup conversation — the US compliance path is still maturing on the platform. If your sector is healthcare and you can assert Covered Entity status, the HIPAA path is available on the Advanced tier, subject to the US data-residency prerequisite.
What if my organization is in Canada but I'm doing contract research for a US Covered Entity? Then the customer is the CE, your relationship with them is via a Business Associate Agreement, and the App's participants drive the privacy-law layer. Talk to us before you create the App — the routing here is fact-specific.
Does sector = research mean my App is only usable for academic research? No. Sector = research is a signal that TCPS 2 and REB workflows apply. Independent evaluators, non-academic research firms, and community-based research projects all fit. The classification is about the work, not about the organization's tax status.
Where does the audit trail live? Inside Septenar's DynamoDB AuditLog table, partitioned per App per month. Retention is 1 year for Law 25 and 6 years for HIPAA — the HIPAA clock is on the platform's documentation of access controls, not on the participant's data itself.
What this Guide is not
This Guide is not legal advice. The platform applies a deliberate framework to translate your answers into a compliance posture, but the framework cannot cover every edge case: agency relationships under PHIPA s. 17, the §17 cross-border assessment specifics for your particular sub-processors, multi-jurisdictional research with mixed REB designations, breach response under overlapping regulators with different definitions of "risk of serious harm." For those, the platform surfaces the right templates and timelines and routes the events. The substantive judgment is yours and your counsel's.