On November 1, 2018, the Canadian Digital Privacy Act came into effect. The Act, passed on June 18, 2015, modified the data breach obligations for companies subject to the Personal Information Protection and Electronic Documents Act (“PIPEDA”) by introducing three new requirements in the event of certain data breaches: reporting to the Canadian Office of the Privacy Commissioner (“OPC”), notification to the affected individuals, and recordkeeping obligations. Below, we discuss these requirements and recent guidance provided by the OPC, and explore some implications for companies subject to PIPEDA.
Requirements under the Digital Privacy Act and Recent Guidance:
The Act’s obligations apply to the same organizations currently subject to PIPEDA’s other requirements: organizations, regardless of size, that collect and use personal data in the course of “commercial activity” in Canada. On October 29, following public input, the OPC issued final guidance regarding the new requirements, supplementing regulations adopted in March 2018 specifying the content and form of notice.
Notification to the Government. Under the Act, companies must report to the OPC any “breach[es] of security safeguards” involving personal information, if the company reasonably believes the breach creates “a real risk of significant harm” (“RROSH”) to an individual. Thus, unlike certain U.S. state laws, government notification is tied to the nature of the breach and the potential harm and not to the number of people affected. Notification must be given “as soon as feasible” after discovering the breach and must include a description of the breach, the organization’s response, the type of data and number of persons affected, among other things.
Additionally, companies must also notify governmental institutions or organizations that could mitigate the harm caused from the breach, including, for example, law enforcement or payment processers. The OPC may also directly disclose information about the breach to other government agencies for purposes of criminal investigations.
Notification to Affected Individuals. Similarly, companies must notify affected individuals in the event of a breach of security safeguards that the company reasonably believes creates a RROSH. As with reports given to the OPC, notice given to individuals must be made “as soon as feasible” following discovery of the breach and include descriptions of the breach and the organization’s response. It also must be easily understandable, clearly explain the significance of the breach to the individual, and describe steps individuals could take to mitigate the impact of the breach. Direct notice is generally required except in limited situations.
Defining Real Risk of Significant Harm. The guidance broadly defines “significant harm” to include financial loss and identity theft, as well as physical harm, property damage, and damage to reputation, relationships, or employment opportunities. The factors relevant to determining the risk include (1) the sensitivity of the information involved and (2) the probability the information has or can be misused. This is a context-driven inquiry based, among other things, on the circumstances of the breach and the nature of the potential harm from misuse of the compromised information. However, the OPC guidance recommends that companies develop an overall framework for assessing RROSH to ensure consistent application of the standard to all breaches.
Recordkeeping Obligations. Unlike the breach notification provisions above, the new recordkeeping provisions require companies to keep records of every breach involving personal information under their control—regardless of whether it creates a RROSH—for two years. These records must contain enough information for the OPC to verify the organization’s compliance with its notification obligations, such as the date of the breach, a description of the breach and information involved, and whether notice was made to the OPC or any individuals. Further, the records should provide sufficient information for the OPC to assess whether the organization “has correctly applied the real risk of significant harm standard and met its obligations to report and notify” the OPC.
Implications for Multinational Companies Subject to PIPEDA:
Consider Variations in Mandatory Reporting Requirements and Timelines. Organizations that are under the purview of PIPEDA may also be covered by a web of breach notification obligations in other jurisdictions. As such, companies should evaluate how the RROSH-based requirements under PIPEDA differ from triggers under other data privacy legislations. For example, despite the OPC’s suggestion that the new regulations were “drafted with a view to harmonizing the requirements [with the GDPR] to the extent possible,” the GDPR’s requirement that notification be given unless a breach is “unlikely to result in a risk to the rights and freedoms of natural persons” may trigger notification where PIPEDA would not.
Similarly, the timeline for reporting breaches, whether to a government entity or affected individual, often varies between regulations. Under PIPEDA, notification to the OPC and affected individuals must be made “as soon as feasible after the organization determines the breach has occurred,” in contrast to the GDPR’s requirement that notification be made within 72 hours of becoming aware of a breach or other timing requirements under applicable U.S. state law. Given these differences, companies implementing breach notification plans should consider how regulators may react to learning that a data breach was reported to overseas counterparts days or weeks before, even if all legal requirements were technically satisfied.
Be Mindful of Third-Party Vendors. One increasingly common thread through the patchwork of data security laws is that a company may be responsible for breaches of third-party vendors to whom the company has provided personal information. The OPC guidance interprets the Act to place the obligation to report a breach on the company “in control of” the compromised personal information. While recognizing that this determination may be context-specific based on the commercial and contractual realities of the business relationship, the guidance advises that companies generally have “control” of personal information given to a third-party vendor for processing and therefore may be responsible for reporting breaches of those processors. Where the processor uses or discloses the personal information for other purposes, however, the processor may assume “control” of the information under the Act. This differentiation of information processors is in line with the approach taken under the GDPR and actions taken by U.S. regulators. As we have previously cautioned, companies should conduct thorough diligence before onboarding a third-party vendor and monitor the vendor throughout the engagement.
Carefully Assess What Information Can—and Should—Be Provided. Forensic investigations of data breaches necessary to accurately determine key facts of a data breach frequently extend far beyond the time horizon for notification to government entities or affected individuals. Companies should consider the risk of providing incomplete or inaccurate information when providing requisite notifications. Canadian lawmakers have acknowledged that “it often takes weeks or months to fully investigate [a data breach] incident and that initial theories about the time frame, cause or scope of the breach are often proven incorrect.” In recognition of this, PIPEDA permits organizations to report information “to the extent it is available at the time of reporting” and to update the report “at a later date.”
Maintain Thorough Records. As the OPC guidance simply puts it: “there must be a record of every breach of security safeguards.” And although PIPEDA only requires these records be kept for two years, companies may have other legal requirements requiring data to be kept for longer periods. In light of this, companies should understand what laws are applicable and the relevant recordkeeping requirements when designing record retention policies in incident response plans and before permanently altering or deleting data.