Canada Privacy & PIA

Overview

The Canada Privacy & PIA skill helps Rakenne users align with Canadian privacy law (PIPEDA, applicable provincial private-sector laws, and Bill C-27 / CPPA status) and draft or complete Privacy Impact Assessments (PIAs) for federal and private-sector data handling. It provides reference material on PIPEDA fair information principles, CPPA/AIDA proposed-law implications, and PIA requirements for federal institutions and private-sector accountability practice. Use it together with the privacy_impact_validator skill to elaborate full PIA documents from an outline or draft.

Getting Started

Add your initiative description, data-flow notes, and any existing PIA draft to the project workspace, then activate the Canada Privacy & PIA skill. The agent will clarify scope (federal vs private sector), apply the Canadian legal references and PIA template, and—if you use the privacy_impact_validator—produce a structured PIA. Save outputs to output/ for review and sign-off.

Example Conversation

Below is an example of a typical session when drafting a PIA for a Canadian private-sector initiative. The agent uses the skill’s references and template, then works with the privacy_impact_validator to elaborate the document.

You: We’re building a new customer onboarding flow that will collect name, email, and optional phone. We’re in Canada and want to make sure we’re PIPEDA-aligned and have a PIA we can show internally.

Agent: I’ll help you get a PIA in place for the Canadian context. To tailor it, I need to confirm: (1) Is this purely private-sector (PIPEDA), or do you have any federal government contracting involved? (2) Where will the data be stored and who has access (only your team, or any subprocessors)? (3) Do you already have a privacy notice and retention policy for this data?

You: Private sector only, PIPEDA. Data stays in Canada with our cloud provider; only our product and support teams have access. We have a generic privacy notice but no retention policy yet for onboarding data.

Agent: I’ve pulled in the skill’s PIPEDA and PIA requirements. I’ll draft a PIA using the outline template (purpose, legal basis, information flows, necessity, risks, mitigation, fair information principles). I’ll note the gap on retention and recommend defining a retention period and disposal process. Running this through the privacy_impact_validator to flesh out each section.

Agent: I’ve generated a full PIA draft and saved it to output/pia-customer-onboarding.md. It includes: executive summary (proceed with conditions); legal authority (PIPEDA); description of the initiative; personal information (name, email, phone — sensitivity low); information flows (collection at sign-up, use for account management and support, no disclosure beyond your team and the Canadian cloud provider, retention TBD — flagged); necessity and proportionality; a short risk table (unauthorized access, over-retention) with mitigations (access controls, encryption, retention policy to be adopted); and a checklist against PIPEDA principles. The main recommendation is to adopt and document a retention period and disposal process before go-live.

You: Add a line in the conclusion that we’ll update the PIA if we add more data fields or change providers.

Agent: Done. I added a follow-up condition in the conclusion: the PIA will be reviewed and updated if the initiative expands (e.g. additional data elements or change of subprocessor). The file is updated at output/pia-customer-onboarding.md.

Sample Output Excerpt

Below is a representative excerpt from a Privacy Impact Assessment produced with the Canada Privacy & PIA skill and the privacy_impact_validator — private-sector initiative, PIPEDA context.

Privacy Impact Assessment — Excerpt (private sector, PIPEDA)

Initiative: Customer onboarding flow
Organization: [Company Name]
Date: 2025-02-10
Legal framework: PIPEDA (federal private sector)

1. Executive summary

This PIA assesses the privacy implications of the new customer onboarding flow, which collects name, email, and optional phone number for account creation and support. The initiative is necessary for service delivery; the main risks are unauthorized access and over-retention. With the recommended mitigations (access controls, encryption, and a defined retention and disposal policy), the initiative can proceed. Conclusion: Proceed subject to adoption of a retention and disposal policy before launch.

2. Legal authority and context

• Private sector: Collection, use, and disclosure of personal information are governed by the Personal Information Protection and Electronic Documents Act (PIPEDA). Provincial legislation may apply where substantially similar; this assessment assumes federal PIPEDA applies.
• Bill C-27 (CPPA): When in force, the Consumer Privacy Protection Act will modernize requirements (e.g. privacy by design, possible PIA expectations). This PIA is structured so it can be updated to align with CPPA.

5. Information flows (excerpt)

7. Privacy risks and mitigation (excerpt)

This excerpt is illustrative. Final PIAs must reflect your actual initiative, data flows, and legal advice.

Scripts and validations

This skill does not include executable scripts. It provides:

• Reference documentation — PIPEDA and Bill C-27 (see references/pipeda-bill-c27.md), PIA requirements and steps for federal and private sector (see references/pia-requirements.md).
• PIA outline template — A structured outline (see assets/pia-outline-template.md) for authority, flows, necessity, risks, mitigation, and compliance.

Elaboration and validation of the PIA content are done by using this skill together with the privacy_impact_validator skill: you (or the agent) supply the Canadian context and the outline or draft, and the validator produces a full, section-by-section PIA. For federal institutions, the validator can align output with the TBS Directive process; for private sector, with PIPEDA (and future CPPA) expectations. The Canada Privacy & PIA skill does not perform automated checks itself—it ensures the agent has the correct Canadian law and PIA structure when calling the validator.