GDPR: Making Sense of its Definitions of Data Subjects, Breaches and Notifications
In the first blog of this series, we introduced the GDPR and explored the impact it’s set to make on companies around the world. Widely regarded as one of the most stringent governmental privacy regulations yet, the GDPR outlines acceptable use of personal data by organizations, how they should structure their approach to managing personal data and the fines (or risk) for improperly protecting personal data. The fines can be extensive, as high as 4% of worldwide income (this will be covered more in a future blog).
The GDPR is the first EU data privacy law to explicitly define a “personal data breach” and require notification when one occurs. “Personal data” is defined in the GDPR as “any information relating to an identified or identifiable natural person (‘data subject’).” Notably, there is not a specific set of information (or data fields) that define a data subject. From the text itself:
“an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;”
While listing common fields, the crucial piece of this definition notes the relevant data are those that can be used to identify (through whatever means) a specific individual. To give an example:
The first example is clearly enough information to identify a data subject. However, the latter could be as well -- even if the data subject’s name isn’t present but their age or gender is, this could be considered personal data if it’s enough to identify an individual. For example, an organization may only have a single 23 year-old or a single male in an office. Thus, the set of data that are considered controlled under the GDPR are quite a bit broader than initially expected. This challenge expands as frequently, user data can span tables (or databases). When we come to data pseudonymization we’ll revisit what needs to be discovered and anonymized and the challenges with doing so.
The GDPR lists a number of key controls and activities related to data subjects and personal data. The first two of these are Data Breach Notification and a required role, Data Protection Officer.
Data Breach Notification
Simply, the GDPR requires that organizations who suffer a data breach report it as quickly as possible.
In more detail, under the GDPR, a “personal data breach” is “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.” Note that this definition of personal data is as above - anything that can lead to the identification of a unique person or persons.
In the event of a personal data breach, organizations must notify the supervisory authority. The GDPR defines two separate concepts that typically (but not always) refer to organizations - Data Controller (or controller) and Data Processor (or Processor).
- The Data Controller is the entity (in most cases, an organization, but sometimes a person) that directs the reason why personal data are processed in the first place. For example, a ride sharing company wants to analyze its riders usage patterns to better allocate drivers. Note that the entity that is the controller doesn’t actually have to be the one who analyzes / processes data.
- The Data Processor is the entity (again: person, organization, etc.) that actually does the processing or analysis of data. For example, banks frequently outsource their fraud analysis to third parties, in which case the bank is the controller (directing what’s done with data) and the third party is the processor (actually doing the analysis).
In the event of a breach, the organization (likely the responsibility of the Data Protection Officer, covered in a future blog post) must notify the supervisory authority of the member state where the data controller has its main establishment and the affected data subjects. Meaning, if an organization is based in Frankfurt and has the majority of their customers in Germany, the notification should go to the German supervisory authority. Article 51 in the GDPR covers the creation of the per-state supervisory authority. We’ll see how this works in practice as the law comes into play, but it’s not unreasonable to assume that breaches lead to notification of multiple supervisory authorities as business frequently exists across many EU states.
Notice must be given “without undue delay and, where feasible, not later than 72 hours after having become aware of it.” For those familiar with the recent Equifax breach, the organization waited six weeks before announcing it publicly. This delay in announcement seems to have only made the situation worse: executives took time to sell shares in the company and the public was prevented from taking action to protect their identities.
The notification to the supervisory authority must include “at least” the following:
- The nature of the personal data breach, including the number and categories of data subjects and personal data records affected.
- The Data Protection Officer’s (we’ll cover this role in detail in a future post) contact information.
- The likely consequences of the personal data breach.
- How the controller proposes to address the breach, including any mitigation efforts.
The GDPR does provide some exceptions to the additional requirement of notifying the data subjects of the personal data breach, if:
- The controller has implemented appropriate technical and organizational protection measures that render the data unintelligible to any person who is not authorized to access it (see our forthcoming blog on pseudonymization)
- The controller takes actions subsequent to the personal data breach to “ensure threat the high risk for the rights and freedoms of data subjects is unlikely to materialize
- Notification to each data subject would involve disproportionate effort, in which case alternative communication measures may be used
Complying with the breach notification requirements, as covered above, is only a part of the spirit of the regulation. Effectively doing so requires two other steps: assessing which data an organization has that is considered to be “personal data” and understanding if a breach has occurred in the first place. The latter is well outside of our area of expertise, but we’ll return again in future blogs to personal data, how to identify it and steps that can be taken to reduce the risk / penalty of a breach.
At the end, however, the major push for understanding these requirements comes down to the potential penalties. With a ceiling of 4% of worldwide income (measured by the prior year), the impact of a breach is extreme. The implications go further, however. Not only must organizations ensure they protect individuals’ data but they must institute organizational change across employees to truly understand what is covered and how the employees in their day-to-day operations can act in data subjects’ best interests.
Stay tuned for our next week’s installment as we dig into the roles required and discovery process!