PIPEDA Breach Recordkeeping: What to Document After a Data Breach

Since November 1, 2018, PIPEDA has required organizations to maintain records of every privacy breach involving personal information — not just breaches that rise to the level of OPC notification. This often-overlooked requirement catches many Canadian businesses unprepared when the OPC requests their breach register. Here's what you need to document and why.

Last updated: April 2026

The PIPEDA Breach Recordkeeping Requirement

Under PIPEDA's breach provisions and the Breach of Security Safeguards Regulations (in force since November 1, 2018), organizations must:

1. Report breaches to the OPC when there is real risk of significant harm (ROSH)
2. Notify affected individuals when ROSH exists
3. Keep records of every breach of security safeguards — regardless of whether it involves ROSH

The recordkeeping requirement is broader than the reporting requirement. You must document even minor incidents that don't meet the notification threshold.

What Is a "Breach of Security Safeguards"?

PIPEDA (s. 2(1)) defines a breach of security safeguards as the loss of, unauthorized access to, or unauthorized disclosure of personal information resulting from a breach of your security safeguards or resulting from a failure to establish those safeguards.

Examples that require recordkeeping (even if not reportable):

• A laptop with encrypted data is briefly lost but recovered with no evidence of access
• An employee accidentally emails a customer's invoice to the wrong client
• A vendor inadvertently shares a small amount of customer data before correcting the error
• A phishing email resulted in brief unauthorized access to a system with personal data
• A paper file is misplaced in your office (found later, no external disclosure)

Examples that likely require both recordkeeping and OPC notification:

• A hacker accesses your customer database and downloads records
• An employee deliberately sells customer information to a third party
• A large-scale unencrypted data exposure on a publicly accessible server

The threshold for recordkeeping is lower than for notification. When in doubt, document it.

What Your Breach Record Must Contain

The regulations (s. 6(2)) require that a breach record contain any information that enables the OPC to verify compliance with PIPEDA's reporting and notification requirements (s. 10.1(1) and (3)). The OPC's guidance says that, as a starting point, it would expect a record at minimum to include the date or estimated date of the breach, a general description of the circumstances, the nature of the information involved, and whether the breach was reported to the OPC and individuals were notified. The record should also contain enough detail for the OPC to assess whether you correctly applied the real risk of significant harm standard.

Core Elements

1. Date (or approximate date) of the breach When did the breach occur or when do you estimate it occurred? If you discovered it after the fact, note the discovery date and estimated occurrence date separately.

2. Description of the personal information involved What categories of personal information were affected?

• Names and contact information
• Financial data (credit card numbers, banking details, SINs)
• Health information
• Employee data
• Any other category

Include approximate number of records/individuals affected.

3. Description of the circumstances of the breach How did the breach happen?

• Unauthorized external access (hacking)
• Accidental disclosure by employee
• Physical theft or loss
• Vendor error
• System misconfiguration
• Other

4. Whether the organization notified the OPC If yes — when was the report filed? If no — explain why (e.g., ROSH threshold not met, assessed as low risk).

5. Date of OPC notification (if applicable)

Recommended Additional Elements

Beyond the minimum, strong breach records should also include:

• Discovery date (vs. occurrence date)
• Who discovered the breach (internal/external)
• Root cause analysis
• Containment actions taken (and when)
• Affected individuals — were they notified? When? How?
• Third parties involved (vendors, partners)
• Remediation steps taken
• Policy/process changes made as a result
• Who reviewed and approved the record

The Breach Register Format

Your breach register can be as simple as a spreadsheet or as formal as a dedicated incident management system. What matters is that:

• It's maintained consistently
• It's accurate
• It's accessible to your Privacy Officer
• It can be produced for the OPC on request

Simple spreadsheet structure:

Field	Example
Breach ID	2026-001
Date discovered	2026-02-15
Date occurred	2026-02-14
Description	Employee sent customer invoice to wrong email address
Data involved	Name, address, invoice total — 1 individual
Circumstances	Human error — incorrect email address selected in email client
ROSH assessment	No — limited data, accidental, no evidence of misuse
OPC notified?	No
Individual notified?	Yes — contacted the affected customer by phone 2026-02-15
Remediation	Staff reminder on double-checking email recipients
Record created by	[Name], Privacy Officer
Record date	2026-02-16

Download this register as a CSV template (opens in Excel or Google Sheets; delete the example row first). A template is a place to keep the record, not a decision about whether a breach is reportable, and it does not replace advice from a privacy lawyer.

How Long to Keep Breach Records

PIPEDA's Breach Regulations require breach records to be retained for a minimum of 24 months from the date the organization determines the breach occurred.

Best practice: Retain for 5-7 years. Breach records may become relevant in:

• OPC investigations
• Civil litigation
• Insurance claims

Store breach records securely — they themselves contain personal information.

What Happens If the OPC Requests Your Breach Register?

The OPC can request access to your breach register at any time. Under PIPEDA (s. 10.3(2)), organizations must, on request, provide the OPC with access to, or a copy of, a breach record.

If you have maintained your register properly:

• Provide the register as requested
• This demonstrates compliance and good faith
• The OPC may close its inquiry once satisfied you're maintaining records appropriately

If you have no breach register or an incomplete one:

• This itself is a PIPEDA violation (failure to maintain records)
• The OPC may investigate more deeply
• Penalties for failure to maintain records can apply independently of penalties for the underlying breach

Connecting Breach Records to Your Broader Privacy Programme

Your breach register is one component of a privacy incident response programme. Related documentation you should maintain:

Breach Response Plan: Your documented procedure for detecting, containing, assessing, reporting, and remediating breaches.

Risk Assessments: For each breach, an assessment of whether ROSH exists (required to determine notification obligations).

Notification Records: For breaches where you notified the OPC and/or individuals, retain copies of the notifications, dates, and evidence of delivery.

Third-Party Notifications: If your vendor suffered a breach involving your customers, document the vendor's notification to you and your subsequent actions.

Avoiding Common Recordkeeping Mistakes

Mistake 1: Only documenting notifiable breaches Every breach requires a record — not just those that meet the ROSH threshold. Your low-severity incidents must be documented too.

Mistake 2: Vague or incomplete records A log entry that says "email error — minor" is not sufficient. Include the specific data types, individuals affected, and actions taken.

Mistake 3: No documentation trail for the ROSH assessment Document why you concluded a breach didn't reach ROSH. "We assessed that the inadvertent email disclosure to a single recipient of a non-sensitive invoice did not create real risk of significant harm because [reasons]." This reasoning protects you if the assessment is later questioned.

Mistake 4: Storing breach records insecurely Your breach register contains personal information. It should be access-controlled and handled with the same care as other personal information.

Mistake 5: Not reviewing the register periodically Use your breach register as a management tool. Review it quarterly to identify patterns (recurring vendor errors, staff training gaps) and improve your privacy programme.

Frequently Asked Questions

Q: If an employee accidentally overwrites a customer file (data is lost, not disclosed), is that a breach? A: Accidental data loss can be a breach if personal information is involved and security safeguards were not adequate to prevent the loss. Assess the circumstances and document accordingly.

Q: We had a breach before November 2018. Do we need to retroactively document it? A: The regulation applies to breaches occurring on or after November 1, 2018. You're not legally required to retroactively document pre-regulation incidents, but doing so voluntarily builds a complete picture for your privacy programme.

Q: Our IT department logs security incidents. Can this serve as our breach register? A: IT security logs can supplement your breach register, but they likely don't contain the privacy-specific information PIPEDA requires (ROSH assessment, notification status, Privacy Officer review). You need a privacy-focused layer on top of IT security logs.

---

Breach Documentation Built Into Your Compliance Programme

Canada Compliance AI helps Canadian SMEs work through CASL, PIPEDA and Quebec Law 25: a free two-minute compliance check, readiness scores, a prioritized task plan, a 24-month breach register and an exportable audit log. See what's live and what's planned.

Start your free trial today — document every incident properly, from day one.

Related reading: Data Breach Response Canada | PIPEDA Compliance Guide | Privacy Audit Checklist Canada