Privacy by design for custom software in Canada

This guide is about software design, not legal advice. Which law applies to you depends on where you operate and what kind of organisation you are: the federal PIPEDA for many private-sector organisations, provincial equivalents such as British Columbia’s and Alberta’s Personal Information Protection Acts for activity within those provinces, Quebec’s Law 25, which adds stricter requirements, and freedom-of-information legislation such as BC’s FOIPPA for public bodies. Confirm the position with your privacy officer or counsel.

The design principles below hold across all of them.

The principles, as design decisions

Canadian private-sector privacy law is built on fair information principles — accountability, identifying purposes, consent, limiting collection, limiting use and retention, accuracy, safeguards, openness, individual access and the ability to challenge compliance. In a software project, each becomes a concrete decision.

Limit collection. Every field on every form should have a reason. If the system does not need a date of birth, do not ask for it. The cheapest personal information to protect is the information you never collected.

Record purpose and consent. Where consent is the basis, store what the person agreed to, when, and which version of the wording they saw — so you can show it later.

Enforce retention in the system. Retention schedules written in a policy and enforced by memory do not work. Build them in: records reach the end of their retention period and are deleted or anonymised automatically, with a log of what was removed.

Make access and correction requests answerable. A person can ask what you hold about them. If their information is spread across systems with no common identifier, answering takes days of searching. Design the data so it can be found.

Safeguards proportionate to sensitivity. Encryption in transit and at rest, access by role, the minimum privilege each role needs, and stronger protection for the most sensitive data.

Audit trails. Who viewed or changed personal information, and when. This is what lets you investigate an incident — and demonstrate that nothing happened.

Incident records. Know how you would detect, record and assess a privacy breach before you need to. Several Canadian laws require breaches to be recorded and, where there is a real risk of significant harm, reported.

Know your processors. Every third-party service the system uses — hosting, email, analytics, AI — handles personal information on your behalf. List them, know where they process data, and make sure your privacy notice says so.

Quebec’s Law 25

If you have customers or users in Quebec, Law 25 raises the bar: privacy impact assessments for certain projects, privacy-protective settings by default, designated responsibility for privacy, and stronger rights for individuals. Designing to it from the start is far easier than retrofitting, and it improves the system for everyone else too.

Built in versus bolted on

Adding privacy controls to a finished system means changing its data model, its screens and its integrations — the most expensive kind of change. Specifying them up front costs a few pages of requirements and some careful thought about the data.

A checklist for your specification

1. A data inventory: every piece of personal information, why it is collected and where it lives.
2. Consent records, where consent is the basis.
3. Retention periods per record type, and how deletion happens.
4. How an access or correction request will be answered.
5. Roles and what each can see.
6. Audit logging for personal information.
7. Third-party processors and where they process data.
8. How incidents are detected and recorded.

Our requirements analysis puts these into the specification from the start, and every custom software build we deliver is designed to them. For AI systems specifically, see using AI in a regulated practice.