In this Privacy Tracker series, we look at laws from across the globe and match them up against the EU General Data Protection Regulation. The aim is to help you determine how much duplication of operational effort you might avoid as you move toward GDPR compliance and help you focus your efforts. In this installment, Alex Reynolds explains the relationship between U.S. state data breach laws and the GDPR’s breach provisions, Articles 33 and 34.
Breaches occur frequently, and the legal landscape of breach notification is highly fragmented. Organizations experiencing a breach today face a stressful and uphill battle: first, determining which state’s or country’s laws apply to affected persons (if any), then overcoming the logistical challenges of the notification process and perhaps regulatory investigations and litigation. Perhaps even more frustrating is the fact that no single approach works for every jurisdiction, so it is not possible to design a “fire and forget” procedure that guarantees compliance. Unfortunately, the GDPR’s looming breach reporting requirements will not lessen those frustrations.
Determining whether or not consumer and regulatory notifications are triggered by a security incident is a two-part analysis: First, an organization (a “controller” or “processor” in the GDPR’s terms) must determine whether the threshold conditions of a “breach” have been met; and second, if there was a breach, an organization must determine the recipients, content and timing of any required notifications. While this two part analysis is conceptually simple, small variations among breach statutes in the U.S. alone can create significant interpretive and logistical difficulties, but add the broader definitions of “personal data” and 72-hour reporting timelines in the GDPR, and the complexities of an international breach are magnified.
Step one: Was there a breach?
Answering this question requires organizations to examine a jurisdiction’s definition of “breach,” whether the jurisdiction’s harm threshold was met, and if a safe harbor applies.
Definition of breach
Statutory definitions of “breach” have two parts. The first is the information covered by the breach, the second is the event that gives rise to the breach.
Despite the variation in U.S. states’ data breach laws, at their basic levels they cover similar types of information and all states have a defined list of covered information. Typically, this is name plus a second piece of data like Social Security number, government issued ID number, or financial information like a bank account number or payment card number with enough information to enable theft or fraud. Many states have expanded covered information to include an email or a username and password. Some U.S. states are also expanding their definitions to include biometric data, and at least one state includes date of birth.
Additionally, some states’ statutes pertain only to electronic information; while other states consider a breach to be unauthorized acquisition of both paper and electronic records. Since U.S. privacy laws are sectoral, organizations may also need to consider whether the affected data is covered by federal laws such as HIPAA, GLBA, the Communications Act, or their state equivalents. These laws may trigger different and more specific reporting requirements.
The GDPR implements a uniform breach notification requirement, but instead of listing limited types of covered data elements, it covers a significantly broader set of data. Its definition of “personal data breach” references the definition of “personal information,” which means “any information relating to an identified or identifiable natural person,” including information that could identify a person indirectly such as an “online identifier” or personal characteristics sufficient to distinguish an individual from other people. Thus, while organizations in the U.S. must focus on protecting discrete types of data, organizations subject to the GDPR must carefully evaluate all data affected by a security incident to determine whether any single piece of information or combination of that information could meet the definition of personal data.
The events that could give rise to a breach are more numerous in the GDPR. U.S. states typically require notification if there has been “unauthorized access” to or “acquisition” of covered information. Federal laws are more specific but follow this formula; for example, HIPAA defines a breach to include access to protected health information in a manner not authorized by its Privacy Rule.
The GDPR covers unauthorized access to or acquisition of personal information, but its scope is much broader, requiring a determination whether there was “the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.” For example, the GDPR considers it a breach if an employee, who is otherwise authorized to access personal information, accidentally deletes that information. (The GDPR’s notification rules are in addition to new security incident reporting obligations that will apply to “essential service providers” and certain online service providers, including marketplaces, search engines and cloud service providers, under the Network and Information Security Directive.)
Harm threshold
There are significant differences between the harm threshold of U.S. states’ statutes and the GDPR. Many U.S. states do not have a harm threshold and simply require reporting for any “breach” when there is no safe harbor (see below). For those that do have such a threshold, the risk analysis typically focuses on financial harm, i.e., theft or fraud, or identity theft.
In contrast, the GDPR has two harm thresholds, one for notification to supervisory authorities (an EU member state’s data protection authority) and another for notification to consumers. First, with respect to notification to supervisory authorities, the test is whether the breach “is unlikely to result in a risk to the rights and freedoms of natural persons.” Second, with respect to consumer notification, the test is whether the breach is “likely to result in a high risk to the rights and freedoms of natural persons.” (Also notice that the risk analysis is with respect to natural persons generally, not just the persons whose information was the subject of the breach.) The breadth of the harm definition represents a significant challenge for organizations — on the spectrum of risk, what is a high risk and what is a low risk? How might risk differ depending on the affected population of data subjects? How might EU supervisory authorities address risk differently? This is a particularly thorny issue given that there has been no formal guidance from EU authorities on this point, although the Article 29 Working Party expects to update previous guidance on data breaches in 2017.
Safe Harbors
Organizations that experience a security incident must also consider whether any safe harbors apply. In the U.S., some states do not require organizations to make notifications if the affected data was encrypted and the encryption key was not compromised. In addition, many states do not require a separate notification if an organization is regulated by HIPAA or GLBA, as those laws have their own notification requirements. The GDPR does not require consumer notification (although regulatory notification would still be necessary) if one of two conditions are met: The controller implemented appropriate safeguards such as encryption, or the controller has taken subsequent measures to ensure that the risk to the rights and freedoms of persons “is no longer likely to materialize.” Additionally, individual consumer notification is not required if such notice “would involve disproportionate effort.” In that case, substitute notification via a public notice is required.
Step 2: If there was a breach, what is the organization required to do?
When an organization determines that a security incident is a breach under applicable law, it may be required to provide notification to one or more regulators, affected consumers/data subjects, consumer reporting agencies or Credit Reporting Agencies (U.S. companies such as Equifax, Experian and Transunion) and to provide credit monitoring for those consumers whose data was compromised.
In the U.S., about half of the states that have data breach statutes require notification to a regulatory entity (often an Attorney General’s Office); sometimes, regulatory notification is required only if the number of affected consumers reaches a certain threshold. All states with breach statutes require notification to consumers without exception, even if just one consumer was affected. Often, states require notification to consumer reporting agencies if the number of affected consumers reaches a threshold — 1,000 is a common number. Some states, like Connecticut, require organizations to provide free identity theft prevention services simultaneously with consumer notification for certain types of breaches.
The GDPR requires notification to the controller’s supervisory authority and to data subjects — there are no analogous requirements to notify consumer reporting agencies or to provide identity theft remediation services. Supervisory authorities are the national data protection authorities in each EU member state (as Germany is a federal system, there are both state and federal data protection regulators).
Notification Timing Requirements
In the U.S., the deadline for an organization to report a breach is often “without unreasonable delay” or a similar formulation. However, more states are setting hard deadlines that vary from as few as two days (Arkansas; for certain financial information) to as many as 90 days, although 30-45 days is more common. Some states require notification to regulators and CRAs prior to the consumer notifications.
The GDPR requires notification to an organization’s supervisory authority “without undue delay, and where feasible, not later than 72 hours after having become aware” of the breach. If organizations are unable to notify within 72 hours, the notification must include a reason for the delay, and notification to data subjects must be “without undue delay.” Thus, while the GDPR’s notification deadline is uniform across the EU, the timeline to notify regulators is very short — organizations that do not have a plan to identify security incidents when they occur and to take appropriate action will have extreme difficulty making a coherent notification to EU regulators in that timeframe. While the GDPR permits organizations to make multiple reports as more information about the breach becomes available, such tight deadlines are a major incentive to create security incident procedures and training. Finally, note that the entity to be notified is the supervisory authority, not the “lead” supervisory authority. Thus, there is some ambiguity with respect to which authority, or whether more than one authority, should receive notification.
If an organization is a contractor or processor to another entity that owns or is responsible for the affected personal information, the majority of U.S. states and the GDPR require such organization to notify the responsible organization quickly. In the U.S., this time frame ranges from “immediately” to “as soon as practicable.” The GDPR requires notification “without undue delay.”
Content of notice to regulators
In the U.S., state regulators often require affected organizations to describe the nature of the breach, the information affected, the remedial measures taken, whether law enforcement was notified and requested a delay, whether consumers are being offered identity theft protection, and contact information. Louisiana is unique among states because it requests a list of affected Louisiana citizens.
The GDPR requires an organization to describe to its supervisory authority the nature of the breach (including, where possible, the number of data subjects affected and “the categories and approximate number of personal data records concerned”), the contact information of the organization’s data protection officer or other contact point, the “likely consequences” of the breach, and the measures the organization proposes or has taken to address or remediate the breach.
Content of notice to consumers
Here again, U.S. states vary. Several states, such as California, require organizations to include certain information in consumer notifications and even dictate the format of the notifications — or, as in the case of Massachusetts’ law, exclude information about background details of the breach. Often, consumer notifications will describe what happened, the information affected, how the organization intends to, or has, remediated the situation, information about identity theft protection, and contact information.
The GDPR has very similar requirements. Organizations must explain in “clear and plain language the nature of the personal data breach” and “at least” the elements required in the content of the notice to supervisory authorities except for a description of the nature of the personal data breach.
Method of notice
In the U.S., states often do not specify the format of notice to regulators. Typically, notice is written although some regulators prefer email or online submission. For notice to consumers, states default to written notice provided by mail, but other methods such as email or substitute notice are possible if certain conditions are met. In contrast, the GDPR simply states that controllers must “notify” supervisory authorities and must “communicate” notifications to consumers without specifying the format. If an organization uses substitute notice, the GDPR requires that notice “be a public communication or similar measure” that informs data subjects in an “equally effective manner” compared to direct data subject notifications.
Other notable differences
The GDPR requires organizations to document any personal data breach to permit supervisory authorities to “verify compliance” with Article 33 and 34 requirements. Explicit documentation requirements do not exist in U.S. states’ breach laws, although organizations that experience a security incident — but not a breach — may wish to document the event as part of their internal compliance procedures.
Additionally, the GDPR permits supervisory authorities to override organizations’ decisions regarding whether there was a reportable breach (i.e., whether the definition of “personal data breach” and the harm threshold or safe harbor were met). U.S. authorities do not have a similar compliance enforcement mechanism; however, states may use penalties to accomplish the same result indirectly.
Conclusion
Recommendations for organizations to implement security incident response plans now take on new urgency as we draw closer to the GDPR’s effective date. Having a thorough, consistent, and tested understanding of one’s obligations to identify and report incidents can save an organization time, money, and its reputation.
Summary Table
| US States, Generally | GDPR | |
|---|---|---|
| Covered Information | Name, plus another identifier such as government issued identifiers or financial account information; usernames or email addresses plus passwords | “Personal information,” defined as any information relating to an identified or identifiable natural person who is alive |
| A breach occurs when… | There is unauthorized access to or acquisition of (typically electronic) covered information | There is “the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.” |
| Harm Threshold | Risk of financial harm or identity theft | With respect to notification to supervisory authorities, the test is whether the breach is likely to result in “a risk to the rights and freedoms of natural persons.” With respect to consumer notification, the test is whether the breach is likely to result in “a high risk to the rights and freedoms of natural persons.” |
| Safe Harbors | Encryption, where the encryption key has not been compromised; compliance with other applicable privacy laws | If (1) the controller implemented appropriate safeguards such as encryption, or (2) the controller has taken subsequent measures to ensure that the risk to the rights and freedoms of persons “is no longer likely to materialize.” |
| Notification Requirements (Regulatory) | Timing: Varies by state ranging from 2 to 90 days, with 30-45 being more common when specific timing required; otherwise, “without unreasonable delay.” Content: (1) Description of incident in general terms, (2) types of covered information affected by breach, (3) remedial or protective steps taken, (4) contact information for the organization. Method: Varies by state; postal delivery usually accepted, although some states prefer email or online submission and fax numbers available for others. | Timing: “Without undue delay” and “where feasible, not later than 72 hours after having become aware [of the breach].” Content: (1) Nature of the breach including approximate number of data subjects and records concerned, (2) contact information for controller’s DPO, (3) description of the likely consequences of the breach, and (4) measures taken to remediate or mitigate potential negative effects. Method: Not specified. |
| Notification Requirements (Consumer) | Timing: Varies; for states with deadlines, typically between 30-45 days unless special classes of covered information are at risk, such as health information; other states “without unreasonable delay.” Content: Typically the same as for regulatory notification, but including advice that directs the person to remain vigilant by reviewing account statements and monitoring free credit reports. Note Massachusetts prohibits sharing facts or circumstances that lead to breach. Method: Typically postal delivery; email notice possible but additional requirements may apply; “substitute notice” available in limited circumstances. | Timing: “Without undue delay.” Content: A description “in clear and plain language” of the nature of the breach and items (2)-(4) of the regulatory notification. Method: Not specified. |
Photo credit: Erlinda Olvera
photo credit: MPD01605 EU Flagga via photopin (license)