What counts as a real risk of significant harm (RROSH)? A breach-triage explainer

Every privacy breach starts with the same question, and it is not "what happened?" It is "does this cross the threshold?" In Canada, that threshold has a name: a real risk of significant harm, usually shortened to RROSH. It decides whether a breach stays an internal incident record or becomes a report to a regulator and a notification to the people affected. This guide explains where the test comes from, what its two limbs actually require, how regulators distinguish a real risk from a speculative one, and how the same three facts patterns tend to triage in practice.

Where the threshold comes from

Alberta got there first. Since 2010, section 34.1 of Alberta's Personal Information Protection Act (PIPA) has required organizations to report to the provincial Commissioner any incident involving loss of, or unauthorized access to or disclosure of, personal information "where a reasonable person would consider that there exists a real risk of significant harm to an individual." Under section 37.1, the Commissioner then decides whether the organization must notify affected individuals. Because Alberta's OIPC publishes its breach notification decisions, fifteen years of them now form the closest thing Canada has to a RROSH case law.

The federal Personal Information Protection and Electronic Documents Act (PIPEDA) adopted the same formulation when its mandatory breach provisions came into force on November 1, 2018. Section 10.1 requires an organization to report to the Privacy Commissioner of Canada, and to notify affected individuals, any breach of security safeguards involving personal information under its control "if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual." Unlike Alberta's two-step model, PIPEDA makes the organization itself responsible for both decisions.

The public sector is now converging on the same test. Ontario's Bill 194, the Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024, amended FIPPA so that as of July 1, 2025, provincial institutions must report privacy breaches meeting the RROSH threshold to the Information and Privacy Commissioner of Ontario as soon as feasible, notify affected individuals, and file annual breach statistics. The definition of significant harm is lifted almost verbatim from PIPEDA. Quebec's Law 25 built a parallel structure for "confidentiality incidents" on a differently worded threshold — a "risk of serious injury" — with mandatory notification to the CAI and affected persons and a standing incident register. Health-sector statutes such as Ontario's PHIPA run their own notification regimes alongside. The vocabulary shifts at each border; the architecture does not.

The two-part test

RROSH is really two questions stacked on top of each other: would the harm be significant if it happened, and is the risk of it happening real?

What "significant harm" includes

PIPEDA defines the term by enumeration in subsection 10.1(7). Significant harm includes "bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on the credit record and damage to or loss of property." Two things about that list matter in triage. First, it is broad: humiliation and damage to relationships sit alongside financial loss, which is why breaches with no monetary angle at all — a disclosed health condition, an outed address, a browsing history — can still qualify. Second, it is a list of harm types, not a severity scale; the severity question is carried by the word "significant" and, in practice, by the risk limb of the test.

Factor one: sensitivity

Subsection 10.1(8) names two factors for assessing whether a risk is real: the sensitivity of the information and the probability of misuse. The Office of the Privacy Commissioner's guidance, What you need to know about mandatory reporting of breaches of security safeguards, treats sensitivity as contextual rather than categorical. Medical records, financial account details, government identifiers such as the Social Insurance Number, and information about ethnicity, religion, or sexual orientation are generally sensitive on their face. But ordinary information becomes sensitive in combination: a name is not sensitive, a date of birth is not especially sensitive, and a name plus date of birth plus SIN is an identity-theft kit. Triage should assess the compromised data set, not each field in isolation.

Factor two: probability of misuse

The second factor asks how likely it is that the information "has been, is being or will be misused." The OPC's guidance frames this as a series of concrete questions: Who actually accessed, or could access, the information? Is there evidence of malicious intent, such as theft or hacking, as opposed to accident? Were multiple pieces of information compromised together? Is the information still exposed, has it been recovered, or has the recipient credibly confirmed deletion? Has any harm already materialized? And was the information protected — encrypted, anonymized, or otherwise unreadable to whoever holds it? A breach caused by a targeted attacker who exfiltrated data scores very differently on this factor than the same data set left in a taxi on a locked, encrypted device.

"Real" versus speculative

The word doing the most work in the phrase is "real." A real risk does not mean a certain harm, or even a probable one; it means more than a conjectural one. Alberta's OIPC has put the standard crisply in its breach guidance: the likelihood that significant harm will result "must be more than mere speculation or conjecture," and there must be a "cause and effect relationship between the incident and the possible harm." That formulation travels well. If you find yourself constructing a chain of hypotheticals — if someone found the device, and if they defeated the encryption, and if they recognized the data's value — you are describing a speculative risk. If the harm follows directly from what is already known — an unknown third party holds an unencrypted file of names, SINs, and account numbers — the risk is real even though no fraud has yet been observed. Absence of observed misuse at the time of triage is not evidence of absence; most identity-theft harm surfaces months later.

Three worked triage examples

The same two factors, applied to the three fact patterns that account for a large share of real-world triage calls.

1. The lost encrypted laptop

A caseworker's laptop, containing client files with names, addresses, and case notes, is stolen from a car. Full-disk encryption was enabled, the device was powered off, and the credentials were not stored with it. Sensitivity is high — but the probability-of-misuse factor collapses the risk. The thief almost certainly wanted hardware, not data, and intact strong encryption means the data is unreadable even if they wanted it. This pattern typically triages below the threshold. Three caveats keep it honest: verify, rather than assume, that encryption was actually enabled and the disk fully encrypted; confirm no keys, tokens, or written passwords travelled with the device; and record the incident and the reasoning anyway, because the 24-month record-keeping duty applies to every breach, not just reportable ones. If any of those checks fails — encryption unverified, device found logged in, password on a sticky note — the analysis reverses.

2. The misdirected email containing a SIN

An HR officer emails a benefits enrolment form — name, date of birth, SIN, banking details — to the wrong recipient. One individual affected, one recipient, an honest mistake: it feels small. The factors say otherwise. The data set is a near-complete identity-theft kit, so sensitivity is at the top of the scale, and the identity-theft and financial-loss harms in subsection 10.1(7) are squarely engaged. The triage then turns almost entirely on who received it. A known, trusted counterparty who responds promptly and credibly confirms deletion pulls the probability of misuse down, and the incident may defensibly stay below the threshold, well documented. An unknown recipient, a bounced confirmation request, or silence leaves the probability unknowable, and an unknowable probability of misusing a SIN is a real risk. When the threshold is met, this is also the classic case for notifying third parties under section 10.2 — the credit bureaus and the affected person's bank can blunt the harm the statute is worried about.

3. The snooping employee

An employee is found to have repeatedly looked up the records of an ex-partner, a neighbour, or a local public figure without any business reason. No data left the building, and it is tempting to treat that as containment. The factors point the other way. Deliberate unauthorized access is the "evidence of malicious intent" the OPC's probability questions ask about — the misuse is not probable, it has already occurred; snooping is the misuse. And the harms engaged are the ones the enumerated list is often misread as ignoring: humiliation, damage to reputation, damage to relationships. The unknowns — what the snooper did with what they learned, whom they told — add risk rather than subtracting it. Snooping cases routinely meet the threshold for the individuals whose records were accessed, which is why health-sector regulators, who see the most of them, treat them as presumptively serious.

When the threshold is met

Crossing the threshold triggers three duties at once. The organization must report to the Commissioner "as soon as feasible after the organization determines that the breach has occurred" — there is no fixed hour count, but the OPC expects promptness, accepts initial reports on incomplete information, and expects them to be updated as facts develop. The prescribed report covers the circumstances and cause if known, when the breach occurred, the personal information involved, the number of individuals affected, what the organization has done to reduce the risk, what it plans to do to notify individuals, and a contact point.

It must notify affected individuals, also as soon as feasible, in a way that is conspicuous and, wherever possible, direct. The notification must give the individual enough to protect themselves: what happened and when, what information was involved, what the organization has done, what steps the individual can take, and whom to contact. And under section 10.2, it must notify any other organization or government institution that may be able to reduce or mitigate the harm — credit bureaus, payment processors, law enforcement — and may do so without the individual's consent.

The duty below the threshold

The most commonly missed obligation in the regime has nothing to do with notification. Under the Breach of Security Safeguards Regulations, an organization must keep a record of every breach of security safeguards — including the ones it concluded were not reportable — for 24 months from the day it determines the breach occurred, and must provide those records to the OPC on request. The record has to contain enough detail for the Commissioner to verify that the RROSH assessment was done and done correctly: the date and circumstances, the information involved, the two-factor analysis, and the conclusion. A triage decision that lives only in someone's memory does not satisfy this. Knowingly failing to report, notify, or keep records is an offence carrying fines of up to $100,000 per violation. The practical takeaway: the output of every triage, whichever way it goes, is a written assessment.

How the EU and the US draw the line differently

The GDPR splits what Canada fuses into one threshold into two. Under Article 33, a controller must notify its supervisory authority within 72 hours of becoming aware of a personal data breach unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons" — a low bar that makes authority notification close to the default. Under Article 34, affected individuals must be told "without undue delay" only where the breach is "likely to result in a high risk" to them. Many breaches clear the first bar without clearing the second, so a European program routinely notifies its regulator about incidents it would never escalate to data subjects. A Canadian organization operating in both regimes should notice the inversion: PIPEDA's single RROSH threshold governs both audiences, and its "as soon as feasible" clock is softer than 72 hours but starts with no floor beneath it.

The United States has no single national threshold; all 50 states, plus DC and the territories, maintain their own breach notification statutes. Most trigger on the unauthorized acquisition of defined categories of personal information — typically a name combined with an SSN, driver's licence, or financial account credentials — with many states then providing a harm-based off-ramp where the entity determines there is no reasonable likelihood of harm. Regulator notification is threshold-based by headcount rather than by risk: attorney general notice is commonly owed once a breach affects a set number of state residents (250 in Texas, 500 in California, 1,000 in a number of others), and deadlines range from 30 days in states such as Colorado and Florida to "without unreasonable delay" standards elsewhere. The practical consequence for a multi-jurisdiction breach is that triage in the US is mostly a mapping exercise across statutes, where in Canada it is a single reasoned judgment.

Making triage repeatable

The pattern across every regime is the same: the threshold decision must be made quickly, on incomplete facts, and be defensible two years later. That argues for a standing triage discipline rather than an improvised one — a consistent assessment template that walks the two statutory factors, records who decided and when, captures the conclusion either way, and feeds the 24-month record automatically. Organizations that run breach response this way spend their crisis hours on containment and notification quality instead of on reconstructing what the test even requires.

Last reviewed: August 2026.

Sources

• PIPEDA, sections 10.1–10.3 — Justice Laws Canada (accessed August 2026).
• What you need to know about mandatory reporting of breaches of security safeguards — Office of the Privacy Commissioner of Canada, October 2018, last updated August 2025 (accessed August 2026).
• Breach notification requirements and Guidance for notifying the OIPC about a privacy breach under PIPA (April 2024) — Office of the Information and Privacy Commissioner of Alberta (accessed August 2026).
• Bill 194, the Strengthening Cyber Security and Building Trust in the Public Sector Act — Information and Privacy Commissioner of Ontario (accessed August 2026).
• Regulation (EU) 2016/679 (GDPR), Articles 33 and 34 — EUR-Lex, official text (accessed August 2026).

Related reading on this site: how privacy breach management software runs the RROSH assessment as a live, statute-computed notification checklist; the Ontario FOI in transition guide for the rest of the Bill 194 picture; the Canada federal ATIP jurisdiction pack; or book a demo to see breach triage as a workflow rather than a scramble.