The Office of the Privacy Commissioner of Canada (OPC) recently issued PIPEDA Findings #2022-004 (Report). The Report provides insight into the threshold for triggering organizations’ privacy breach notification and reporting obligations under the Personal Information Protection and Electronic Documents Act (PIPEDA)[1] and underscores the need for a timely risk assessment that includes Canadians’ personal information. PIPEDA does not currently have a hard timeline for breach reporting, saying instead that organizations must report/notify “as soon as feasible after the organization determines that the breach has occurred.” With this Report, the OPC is setting the expectation that while this timeline is flexible, it is not infinitely elastic.
Background
The OPC Report follows an investigation into a US-based entity that owns and operates several hotels and casinos in the US (Company), which suffered a privacy breach in July 2019. An unauthorized third party gained access to the Company’s external cloud server, extracted guest data, and then offered the dataset – which contained guest records for approximately 10.6 million guests – for sale on a hackers forum on the dark web. The Company became aware of the breach shortly after it occurred, hired security experts to conduct a forensic investigation, took steps to ensure that the unauthorized user no longer had access to its server, and purchased a copy of the dataset in return for the vendor’s agreement to remove the posting. It also began notifying affected American guests andAmerican privacy regulators of the incident in September 2019.
In February 2020, the OPC learned of the incident through media reports and, apparently assuming that the personal information of Canadians must have been included in the affected dataset, noted that it had not received a breach report. The OPC contacted the Company to obtain information about the breach. The Company conducted further analysis and reported to the OPC in June 2020 that the personal information of 1.9 million Canadians had been affected, including government identifiers of 5,635 Canadians. The Company began notifying the affected Canadians immediately.
Given the potential impact on Canadians and the amount of time that had elapsed between the discovery of the incident and the Company’s report/notification under PIPEDA (roughly 12 months), the OPC decided to initiate its own complaint under section 11(2) of PIPEDA. The OPC is entitled to do so if it is “satisfied that there are reasonable grounds to investigate” a matter under Part 1 of PIPEDA. The OPC Report does not indicate whether it received any complaints from affected individuals.
The OPC’s analysis focused on whether the breach met the “real risk of significant harm” (RROSH) threshold and whether the Company’s report of the breach to the OPC and notification to affected Canadians was done “as soon as feasible,” as required by section 10.1 of PIPEDA.
“Real risk of significant harm” assessment
Sections 10.1(1) and 10.1(3) of PIPEDA provide that an organization must report a breach of security safeguards to the OPC and notify affected individual(s)[2] [2] “if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm” to an individual. If the circumstances do not give rise to an RROSH, then an organization is not required to notify individuals and report the breach to the OPC.
The factors relevant to the RROSH assessment are set out in section 10.1(8) and include the sensitivity of the personal information involved in a breach and the probability that the personal information has been, or will be, misused.[3]
1. Sensitivity of personal information
In its Report, the OPC found that government-issued identifiers, such as passport numbers, Nexus numbers, health card numbers, military identification numbers, and driver’s licence numbers, are sensitive information because they “can be very useful in the context of fraud and identity theft.”
With respect to the other personal information implicated in the breach, such as names, dates of birth, phone numbers, email addresses, and full or partial residential addresses, the OPC remarked that sensitivity would depend on context. While these pieces of personal information may not be sensitive on their own, their sensitivity level can increase when combined with other personal information or when the circumstances of a breach suggest that there is a potential for nefarious use.
In this case, the OPC found that the sensitivity of the remaining personal information was heightened because it was combined with government-issued identifiers and “was posted for sale to malicious actors on a hacking forum on the dark web,” thereby increasing the risk of misuse.
This latter point conflates the sensitivity leg of the test with the risk of misuse portion and artificially inflates the sensitivity of the affected information. The result of this approach means that in almost every hacking incident, the information will be “sensitive.” This is problematic for two reasons: (a) it removes the distinction between “personal information” and “sensitive personal information,” which, in our view, creates a risk of exacerbating breach fatigue among consumers, and (b) it removes the ability of an organization to usefully respond to risk by categorizing information.
The approach taken by the OPC suggests that it may be inclined to find all personal information in a hacking context to be sensitive. The OPC also takes an “all or none” approach, concluding that it “…consider[s] the Canadian personal information breached to be sensitive.” “Alternatively, the OPC could have taken a more nuanced approach and concluded that there were two buckets of information: (a) the first bucket includes the government identifiers, and was therefore sensitive; and (b) the second bucket contains the other information (names, dates of birth, phone number, email address, and full/partial residence address), and was personal information but not – in and of itself – sensitive.
However, this does not appear to be the approach taken by the OPC, so organizations should be careful to use the OPC’s contextual approach when assessing the sensitivity of personal information affected by a privacy breach.
2. Probability of misuse
The OPC noted that a number of factors might be relevant when determining the probability of misuse for the purpose of an RROSH assessment. Such factors include, but are not limited to, the following:
- Who accessed (or who could have accessed) the information;
- How long the personal information was exposed;
- Whether there is any evidence of malicious intent (e.g., theft, hacking);
- Whether the risk of misuse is raised due to a number of pieces of personal information being breached;
- Whether the information was exposed to individuals/entities who are unknown or to a large number of individuals (where certain individuals might use or share the information in a way that would cause harm);
- Whether harm has materialized for any affected individuals;
- Whether the personal information has been recovered; and
- Whether the personal information was easily accessible (e.g., protected by adequate encryption or anonymization).[4]
In the circumstances of the investigation, the OPC found that there was a high probability of the affected individual’s personal information being misused based on the following considerations:
- The breach was caused by an unauthorized actor who demonstrated malicious intent by hacking into the Company’s server and attempting to profit from the extracted data by offering it for sale on the dark web;
- The personal information had been exposed to an unknown number of “malicious actors” on the dark web;
- The significant number of pieces of personal information increased the value of the information and the likelihood of it being misused;
- The personal information was reasonably accessible;
- The data could have been used in a way that had not yet been detected;
- The data could be misused in the future; and
- Although the dataset had been removed by the vendor in July 2019, it reappeared for sale on the dark web in February 2020.
Notably, the Company had argued that the affected information was not in a format that made it easily accessible, and therefore the risk of misuse was lower. It claimed that “the state of the data set was such that it would be extremely challenging for someone without knowledge of the source systems and expertise in data reconstruction to make meaningful use of the data set.” In its view, knowledge of the Company’s source systems was required to understand the information breached. The OPC rejected this claim, noting that it had been able to “organize the data into a form that allow[ed] identification of the personal information contained therein.”
The Company also argued that the risk was reduced as it had purchased a copy of the dataset from the dark web in the weeks following the attack in return for the seller’s agreement to remove the posting. However, the OPC noted that the dataset reappeared for sale on the dark web in February 2020.
Organizations should note that the OPC has consistently rejected the “honour among thieves” argument – that is, any risk is reduced just because the individual(s) who stole the information has promised to delete it/remove it/not use it. The OPC is rightly wary of the promises of bad actors.
The OPC’s findings emphasize the need for a holistic approach to assessing the probability of misuse. It is not enough to only consider whether a misuse has already occurred; organizations must also consider, given the circumstances, the likelihood of misuse occurring in the future.
In this case, given the OPC’s ultimate finding that the likelihood of misuse was so high, there was likely no need for the OPC to find that all of the personal information was sensitive – the RROSH threshold likely would have been triggered regardless. However, the OPC nonetheless conducted that sensitivity inquiry and found that both (the high likelihood of misuse of the personal information and the high sensitivity of the personal information) triggered RROSH.
Need for timely assessment
Where an RROSH exists, the notification and reporting obligations of PIPEDA are triggered, and the organization must execute these duties “as soon as is feasible.”[5]
In its Report, the OPC noted that the Company began investigating the breach in August 2019 and notifying affected American individuals and privacy regulators in September 2019. However, it did not conduct the required risk assessment with respect to Canadians’ personal information until February 2020, after being contacted by the OPC, and it did not report the breach to the OPC or notify affected Canadians until June 2020.
While the OPC quite reasonably acknowledged that it can often take weeks or months to investigate a breach and determine its scope, it found it unacceptable that the Company did not start an RROSH assessment until almost six months after it began notifying affected Americans. The OPC found that the Company should have conducted concurrent analyses regarding the risk to its Canadian and American guests. Had it done so, the Company would have been able to notify affected Canadians and report to the OPC months earlier than June 2020. On this basis, the OPC found that the Company contravened its obligations under section 10.1 of PIPEDA, as it failed to report the breach to the OPC and notify affected individuals as soon as feasible.
Takeaways
There is a tendency amongst foreign-based organizations to ignore the Canadian regulatory requirements while they focus on their domestic obligations (in many cases, US obligations) or high-risk obligations (e.g., under the GDPR, where there can be significant monetary penalties). This Report of the OPC suggests that the approach will be seen as deficient. Organizations should consider the following:
- Assessing the risk to Canadians at the same time they are assessing the overall risk. To do so, an organization’s breach response plans – particularly the technical side – need to have provisions that emphasise the need to quickly establish the location/source of personal information.
- The above should also be a requirement of any statement of work/contract with outside cybersecurity firms assisting with breach response.
- Quantifying the impact on Canadians (or any other localized demographic) is made much easier when the personal information is already segregated on that basis or is persistently tagged so that it can be readily identified as having originated from a Canadian resident. In our experience, failing to do this type of work as part of any up-front information governance will cause months of delay in notification and reporting, and will likely cost tens of thousands of dollars more in breach response fees just to get a rough approximation of the source.
- There is no substitute for adequate encryption. The mere fact that the data originated from proprietary systems or software and/or in an unusual format will not be sufficient to lower the risk of misuse. Organizations should consider robust anonymizations and destruction processes for personal information at end-of-life, and active personal information should be encrypted where possible.
Not all privacy breaches will trigger notification and reporting obligations under PIPEDA. If your organization finds itself faced with a breach of security safeguards, contact the Dentons Privacy and Cybersecurity team for assistance in determining whether you are required to notify affected individuals and report the incident to the OPC.
For more information about Dentons’ data expertise and how we can help, please see our unique Dentons Data suite of data solutions for every business, including enterprise privacy audits, privacy program reviews and implementation, data mapping and gap analysis, and training in respect of personal information.
[1] SO 2000, c 5.
[2] Unless such notification would be prohibited by law.
[3] Section 10.1(8) also provides that additional factors may be prescribed by regulation. Presently, none are prescribed.
[4] Other factors that may be relevant in determining the probability of misuse can be found in the OPC’s guidance document, What you need to know about mandatory reporting of breaches of security safeguards.
[5] PIPEDA, sections 10.1(2) and 10.1(6).
