Privacy by design checklist for Canadian software: what to build in before Bill C-36

What changed in 2026?

Three things changed in 2026 for anyone building software that holds personal information in Canada: a new federal privacy bill was tabled, breach costs reached a record, and patient demand for digital access kept rising.

What has not changed: PIPEDA still applies until Bill C-36 passes and comes into force, including the duty to record every breach of security safeguards and keep that record for two years.

What does it cost not to build privacy in?

The cost shows up in three places: breach costs, possible penalties and rework. Only the first is certain today.

• Breaches: the average Canadian breach cost CA$7.11 million in IBM's 2026 report, across mostly large organizations, with an average lifecycle of 205 days. Supply-chain compromise added about CA$367,899 per incident.
• Penalties (proposed): Bill C-36 as tabled would allow administrative penalties of up to the greater of $10 million or 3% of gross global revenue. It is not yet law.
• Rework: adding deletion or export to a system that was never designed for it means tracing every table, file and backup where a person appears. That is usually far more work than designing it in, because nobody remembers every place data was copied.

The checklist below is ordered by what saves the most rework. If you are comparing a new build against keeping your current tools, the ROI calculator helps you weigh the running costs.

1. Know where personal information lives

Every other item depends on this one. If you cannot list where personal information is stored, you cannot protect, export or delete it.

• A written data map: every database, file store, spreadsheet, inbox, backup and analytics tool that holds personal information.
• Each field tagged by sensitivity: contact details, financial, health, children's information.
• One record per person, with a stable ID, rather than copies scattered across systems.
• A flag for records about people under 18. Bill C-36 would treat children's information as sensitive.
• No personal information in places nobody manages, such as test databases or exported CSV files.

2. Access control and logging

Limit who can see what, and record who did. Access logs are what turn a suspected breach into a known one, and you need them to keep the breach record PIPEDA requires now.

• Role-based access: staff see only the records their job needs.
• Multi-factor sign-in for anyone who can see personal information.
• An access log for viewing, editing, exporting and deleting personal records, kept for at least as long as your breach records.
• A breach register: date, what happened, data involved, people affected, whether it met the real risk of significant harm threshold, and who was notified.
• Encryption in transit and at rest, including backups.

3. Retention and deletion

Decide how long each type of data is kept, and make the system delete it when that time is up. Bill C-36 would also let people ask for disposal of their information when it is no longer needed, consent is withdrawn or it was handled unlawfully.

• A retention period for each data type, set with your accountant or counsel, since tax and professional rules may require keeping some records.
• Automatic deletion or anonymization when the period ends.
• A delete-person function that reaches every system in the data map, including vendor systems.
• A record that the deletion happened, without keeping the deleted data.
• A clear rule for backups: either they expire on a schedule, or deleted records are suppressed if a backup is restored.

4. Access requests and data export

People can already ask what you hold about them under PIPEDA. Bill C-36 would add a right to have their information transferred to another organization, under frameworks still to be set by regulation.

• A way to produce everything held about one person, in readable form, within days rather than weeks.
• A structured export (for example CSV or JSON) of a person's records, so a mobility request can be met when the rules are set.
• A request log: who asked, when, what was provided, and when.
• Identity checks before releasing anything, so the export itself is not a breach.

5. Automated decisions and AI

If software makes or supports a decision with a legal or similarly significant effect on a person, Bill C-36 would require you to explain it on request and allow a human review. The definition covers rules-based systems as well as AI, according to Gowling WLG.

• A list of every place software decides something about a person: pricing, credit, eligibility, fraud flags, hiring screens.
• A decision log: the inputs, the rule or model version, and the result, for each significant decision.
• A plain-language explanation you could give a person about how the decision is reached.
• A route for a person to ask for a human review, and someone responsible for doing it.
• For AI tools: what data the model can see, where it is processed, and whether your data is used to train someone else's model.

Quebec's private-sector law, as amended by Law 25, already has similar rules for decisions based exclusively on automated processing. If you serve Quebec, build for it now. The wider picture on business AI is in is AI worth it for a small business.

6. Vendors and data outside Canada

Vendors are where most breach cost now comes from. IBM's 2026 report named supply-chain compromise the largest single cost driver for Canadian breaches, and Bill C-36 would require a privacy impact assessment before personal information is transferred outside Canada.

Extra items for health data

Health software carries more risk and more demand. Healthcare had the highest average breach cost of any industry for the 13th year in IBM's 2026 report, at US$6.64 million worldwide, and 91% of Canadians want electronic access to their health records.

• Confirm which provincial health privacy law applies to you as a custodian or as a vendor to one.
• Patient consent recorded with each use that needs it, including AI scribes: where the audio is stored, for how long, and who can hear it.
• Patient access to their own records and appointments, with identity checks, since nine in ten patients want it.
• Audit logs that show every staff view of a patient record.
• Data residency in Canada unless there is a clear, assessed reason otherwise.

Our patient portal features checklist and healthcare portal development service cover the build in more detail.

Questions to ask a developer before you hire

Ask these before signing. A developer who builds privacy in should answer each one in a sentence or two, without needing to check.

1. 1How will the system delete every record about one person, including backups and vendor systems?
2. 2How would I export one person's data in a structured file?
3. 3What is logged when staff view, change or export personal information, and for how long?
4. 4Where will data be hosted, and which third-party services will receive it?
5. 5How are roles and permissions set, and who can change them?
6. 6If the system makes decisions about people, how will each decision be logged and explained?
7. 7How will retention periods be enforced automatically?
8. 8Will I own the code, the data and the infrastructure accounts at the end?

These are fair questions to ask us too, and we are happy to answer them in writing before you sign anything. If you want a second opinion on an existing system or a quote you have received, book a free review. We will tell you plainly which items on this list it meets and which it does not. Our guide to choosing a software development company covers the rest of the hiring decision.