Lost or Stolen Device: What Canadian SMEs Must Do Under PIPEDA, Alberta PIPA, and BC PIPA

What makes this scenario different

Most breach scenarios leave access probability as an open question. A lost or stolen device leaves it as the central question — and the answer usually cannot be confirmed.

Unlike ransomware, where an attacker's presence in your environment is established, a lost or stolen device may have been found by someone with no interest in your data, picked up by an opportunist, or targeted deliberately. You often do not know. That uncertainty is what makes this scenario unique: your RROSH assessment turns almost entirely on whether you can resolve the access question, and in most cases, you cannot.

Two variables determine the outcome. The first is encryption: was the device encrypted at rest, and can you confirm the encryption keys were not accessible to whoever had the device? The second is recovery: was the device recovered in a state that allows you to verify the data was never accessed?

When neither variable can be confirmed in your favour, ClearBreach applies High Watermark scoring. Rather than treating uncertain access probability as a midpoint, the assessment uses the worst plausible case as the baseline — access is treated as having occurred unless evidence affirmatively rules it out. This is the correct approach under PIPEDA and both provincial PIPA laws. Regulators do not accept "we don't know" as a basis for concluding no harm risk exists.

---

Immediate containment — this scenario only

Act before you assess. For every other breach type, containment happens concurrently with investigation. For a lost or stolen device, one action takes priority over everything else: remotely wipe or lock the device through your MDM platform while it may still be connected to a network.

• Trigger a remote wipe or lock through your MDM platform (Intune, Jamf, etc.) immediately — document the timestamp and the MDM response
• Revoke any credentials, tokens, or certificates cached on the device: VPN access, corporate email, cloud storage, SSO sessions
• Revoke the device's certificate or remove it from your device management enrollment if it has not already been wiped
• File a police report if the device was stolen — do this promptly, as the report is relevant to your breach record and insurance claim
• Identify what personal information was on the device: locally stored files, cached email, browser-stored credentials, application data
• Determine encryption status: was BitLocker, FileVault, or equivalent enabled? Can you confirm it was active at the time of loss? Were the encryption keys escrowed in your MDM or in an accessible location?

If your MDM shows the remote wipe completed before the device connected to any external network, document this as part of your RROSH assessment — it is a meaningful mitigating factor. If the MDM shows the device never checked in after the loss event, you cannot confirm the wipe succeeded.

---

What drives RROSH in a lost or stolen device scenario

Encryption status is the dominant factor. A device with confirmed full-disk encryption, where recovery keys were not stored on or near the device, presents meaningfully lower access risk than an unencrypted device. But "we require encryption" is not the same as "this device was encrypted." You need confirmation, not policy.

The High Watermark rule applies when encryption cannot be confirmed. If you cannot affirmatively establish that the device was encrypted and that the keys were not accessible to the person who had the device, treat access as having occurred for RROSH purposes. This is consistent with how the OPC and provincial commissioners approach uncertainty in breach assessments.

Probability of misuse depends on context. A device stolen from a locked car by a break-and-enter is different from a device left at a coffee shop and found by another patron. Both are breaches — but the theft scenario carries higher intentional misuse probability, which is a weighted RROSH factor. Be accurate in how you characterize the event.

Sensitive data types determine the harm ceiling. Contact information only — names, email addresses — carries lower inherent harm than financial records, health data, SINs, or passwords. The data types on the device set the ceiling for potential harm if access occurred. In most business contexts, a laptop holds email, which in turn holds far more sensitive information than the employee who owned it may have recognized.

Recovery with verified non-access is the only significant mitigating factor. If the device was recovered and you can establish through forensic analysis or MDM logs that no files were accessed, this materially reduces RROSH. Recovery without verification does not.

---

Likely verdict range

HIGH in most cases where the device was not recovered or encryption cannot be confirmed.

MINIMAL or LOW verdicts require: (a) confirmed full-disk encryption with keys that were not accessible to the person who had the device, and (b) either device recovery with verified non-access or confirmed remote wipe completion before the device connected to any network.

If you cannot confirm one or both of those conditions, assume HIGH and assess carefully. Devices holding only low-sensitivity contact information with confirmed encryption may land at LOW or MEDIUM — but most business devices hold significantly more.

CRITICAL verdicts occur where the device held health records, financial data, SINs, or employee credential files, and encryption cannot be confirmed. If your organization handles that category of data on portable devices without a confirmed encryption and MDM policy, CRITICAL is a realistic outcome.

---

Scenario-specific obligations and complications

BC PIPA applies to Alberta organizations with BC clients or employees. This playbook covers all three jurisdictions because lost or stolen devices often hold information about individuals in multiple provinces. If any of the affected individuals are BC residents, BC PIPA applies to that information. This means a third regulatory notification — to the OIPC BC — in addition to the OPC PIPEDA report and the OIPC Alberta submission.

Alberta PIPA simultaneous notification. Under the OIPC Alberta's April 2024 streamlined review process, organizations that notify affected individuals simultaneously with their regulatory filing receive a private closing letter rather than a public investigation. Do not delay individual notification to await direction from the regulator — simultaneous filing is the correct approach.

Device encryption policy gaps. A lost or stolen device incident almost always reveals a gap: either devices were not actually encrypted as policy required, encryption was not enforced through MDM, or recovery keys were not properly escrowed. This gap is relevant both to your breach report (it affects RROSH) and to your regulatory standing. The OPC and OIPC Alberta have both noted inadequate device encryption safeguards in investigation findings. If this incident reveals a systemic gap, document your remediation steps.

Credential exposure beyond the device. A stolen device with cached credentials — email, VPN, cloud storage — extends the breach scope beyond the files on the device itself. If the thief uses those credentials to access connected systems, you have a second breach. Revoke credentials immediately and monitor for unauthorized access to connected accounts after the device is reported missing.

Insurance notification timing. Most cyber insurance policies require notification within a specified window after discovering a breach. A lost or stolen device qualifies. Check your policy language before concluding this incident is below the notification threshold — insurers and regulators apply different tests.

---

Documents you will need

For a lost or stolen device where RROSH is confirmed:

• Internal Incident Record — always required; begin populating immediately, retain for 24 months minimum
• OPC PIPEDA Breach Report — required if PIPEDA RROSH threshold is met; file as soon as feasible after determining RROSH
• OIPC Alberta PIPA Notification Form — required if Alberta PIPA applies and RROSH is met; email to breachnotice@oipc.ab.ca
• OIPC BC Notification — required if BC PIPA applies and RROSH is met; submit through the OIPC BC's official breach notification process
• Individual Notification Letter — required for all affected individuals where the individual notification obligation fires
• AB PIPA Individual Notice (s.19.1) — required for Alberta PIPA individual notification; attach to your OIPC Alberta submission

ClearBreach generates all of these automatically from your assessment answers.

---

Common mistakes — this scenario specifically

Assuming "encryption required" means "device was encrypted." Policy is not the same as enforcement. If your MDM does not confirm encryption compliance at the time of loss, you cannot rely on your encryption policy as evidence the device was encrypted. This is the most common and most consequential error in device loss assessments.

Treating recovery as resolution. A device returned by a Good Samaritan, or found in the lost and found, is not a closed breach. You need forensic or MDM evidence that the data was not accessed while the device was out of your control. Recovery without that evidence does not eliminate the RROSH question.

Waiting to see if the device turns up. The obligation to assess begins when you become aware the device is missing — not when you decide it is definitely lost. Waiting days to report the loss internally, or waiting weeks to begin the RROSH assessment while hoping the device is found, is not an acceptable approach. Regulators consider when you first became aware in assessing whether your response was timely.

Characterizing every device loss as "probably nothing." The instinct to minimize is understandable. It is also the reason most lost device breaches are reported late or not at all. The RROSH assessment exists precisely to apply consistent criteria rather than gut feel. Run the assessment before reaching a conclusion.

Not revoking credentials promptly. Revoking a device from MDM does not automatically revoke cached credentials for email, VPN, or SSO. These must be revoked separately. A stolen device with valid credentials is a more serious breach than a stolen device with expired or invalidated access.

---

MSP note

If you are an MSP managing devices for a client and a client device is lost or stolen, your obligations depend on whether you hold or can access personal information through your management role.

If your MDM platform manages the device, you have access to MDM logs and may be the one to execute the remote wipe. Do that immediately, regardless of who leads the breach response. Document the MDM action with timestamps.

If the lost device connects to systems you manage, revoke its access credentials immediately — do not wait for client direction.

Confirm with your client who leads regulatory notification before acting unilaterally. Your service agreement should define this. If it does not, get written confirmation from the client before filing on their behalf. Run the ClearBreach assessment under your MSP account for the affected client organization to establish the RROSH verdict before advising them on obligations.

---

Ready to assess this breach? ClearBreach walks you through 18–23 questions and generates your assessment verdict, regulator reports, and individual notification letters automatically — in under 15 minutes. Start your assessment →