What a Privacy Impact Assessment Actually Looks Like for a 10-Person Canadian Company

The PIA Problem for Small Organizations

Privacy impact assessments have a reputation problem in the SMB world: they're universally described as important and almost universally associated with enterprise-scale processes, multi-month timelines, and teams of privacy specialists. This creates a gap where small organizations that genuinely need PIAs don't do them because the process seems out of reach.

Quebec's Law 25 made PIAs mandatory for any technology project that presents privacy risks — specifically, projects involving collecting, using, or disclosing personal information using technological means. This applies to organizations of all sizes. The CAI has published guidance, but it's framed for organizations with dedicated privacy functions.

PIPEDA doesn't mandate PIAs by name, but the Privacy Commissioner has repeatedly endorsed them as a best practice and has cited their absence as a factor in assessing whether organizations have adequate safeguards.

Here's what a PIA actually looks like for a company with ten people and no privacy specialist.

When You Need One

A PIA is appropriate when you're changing how you handle personal information in a meaningful way. Triggers that warrant a PIA:

• Adopting a new software tool that processes customer or employee data
• Building a new product feature that collects additional personal information
• Sharing data with a new vendor or partner
• Moving data to a new storage location or cloud provider
• Starting a new marketing program that uses existing customer data in a new way
• Implementing AI or automated decision-making that uses personal information

You don't need a PIA for every minor operational change. The question is: does this change create new or meaningfully different privacy risks? If yes, document your thinking before you proceed.

The Four Questions a PIA Answers

A PIA for a small organization doesn't need to be a 40-page document. It needs to honestly answer four questions.

1. What personal information is involved?

Name exactly what personal information the project, feature, or change involves. Be specific — not "customer data" but "customer names, email addresses, and purchase history" or "employee names, job titles, and performance review scores." Include the personal information of people who might not be the primary subject: a project management tool that employees use will also contain information about their clients or contacts.

2. What are the risks?

For each category of personal information, identify what could go wrong. The risks to evaluate are: unauthorized access (who could get this who shouldn't), unauthorized disclosure (how could this end up somewhere it shouldn't be), collection beyond what's needed (are we collecting more than the purpose requires), secondary use (could this information be used for something beyond its stated purpose), and retention beyond necessity (how long will we keep it and why).

You don't need sophisticated risk modeling. A table with a row per risk, a "likelihood" column (low/medium/high), and an "impact" column (low/medium/high) is sufficient for a small organization.

3. What are you doing to address those risks?

For each meaningful risk, document the control or mitigation. Access control — who has access to this data and how is that enforced? Encryption — is data encrypted at rest and in transit? Vendor assessment — if a third party is involved, what do you know about their security practices and do they have a contract requiring appropriate protection? Retention policy — when and how will this data be deleted? Training — do the people handling this data know the relevant obligations?

If a risk has no mitigation, acknowledge it and decide consciously whether the project should proceed, whether an alternative approach would reduce the risk, or whether the risk is acceptable given the benefits.

4. Is the project or change appropriate to proceed?

The conclusion of a PIA is a recommendation: proceed as designed, proceed with modifications to address identified risks, or don't proceed. Document which conclusion you've reached and why.

A Practical PIA Template for Small Organizations

The template below takes roughly two to four hours to complete for a typical project. It's not comprehensive in the enterprise sense — it's complete enough to demonstrate that you thought through the privacy implications before proceeding.

Project name and description: [What are you doing?]

Date and person completing: [Record this — you'll want it later]

Personal information involved:

Risks:

Mitigations:

Residual risks after mitigation: [Any risks that remain after controls are applied]

Recommendation: [Proceed / Proceed with modifications / Do not proceed]

Approval: [Name and date]

The Documentation Value

The primary value of a PIA for a small organization isn't the process — it's the document. If a privacy complaint is filed related to the project, or if the CAI or OPC investigates, you can show that you thought about privacy risks before proceeding and implemented controls based on that thinking. This is the evidence of a safeguards-oriented organization.

Organizations that implement new technology without privacy review, discover a problem later, and then try to demonstrate after the fact that they had appropriate safeguards in place are in a difficult position. The contemporaneous document is the proof.

Law 25 requires PIAs to be kept on record and, in some cases, made available to the CAI on request. The document you write before a project starts is the document you'll have if the CAI ever asks.