In the\u00a0first blog\u00a0of this series, we introduced the General Data Protection Regulation (GDPR) and explored the impact it\u2019s 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).\nThe GDPR is the first EU data privacy law to explicitly define a \u201cpersonal data breach\u201d and require notification when one occurs. \u201cPersonal data\u201d is\u00a0defined\u00a0in the GDPR as \u201cany information relating to an identified or identifiable natural person (\u2018data subject\u2019).\u201d Notably, there is\u00a0not\u00a0a specific set of information (or data fields) that define a data subject. From the text itself:\n\u201cAn 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;\u201d\nWhile listing common fields, the crucial piece of this definition notes the relevant data are those that can be used to\u00a0identify\u00a0(through whatever means) a specific individual. To give an example:\n\nThe first example is clearly enough information to identify a data subject, and the latter\u00a0could\u00a0be as well. Even if the data subject\u2019s name isn\u2019t present but their age or gender is, this could be considered personal data if it\u2019s 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 user data frequently can span tables (or databases). When we come to data pseudonymization we\u2019ll revisit what needs to be discovered and anonymized and the challenges with doing so.\nThe 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.\nData Breach Notification\nSimply, the GDPR requires that organizations who suffer a data breach report it as quickly as possible.\nIn more detail, under the GDPR, a \u201cpersonal data breach\u201d is \u201ca 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.\u201d Note that this definition of personal data is as above - anything that can lead to the identification of a unique person or persons.\nIn 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).\n\nThe Data Controller is the entity (in most cases, an organization, but sometimes a person) that directs the reason\u00a0whypersonal data are processed in the first place. For example, a ride-sharing company wants to analyze its riders\u2019 usage patterns to better allocate drivers. Note that the entity that is the controller doesn\u2019t actually have to be the one who analyzes\/processes data.\u00a0\nThe 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\u2019s done with data) and the third party is the processor (actually doing the analysis).\u00a0\n\nIn the event of a breach, the organization (likely the responsibility of the Data Protection Officer, which we will cover in a future blog post) must notify the supervisory authority of the member state where the data controller has its main establishment\u00a0and\u00a0the 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.\u00a0Article 51\u00a0in the GDPR covers the creation of the per-state supervisory authority. We\u2019ll see how this works in practice as the law comes into play, but it\u2019s not unreasonable to assume that breaches lead to notification of multiple supervisory authorities as business frequently exists across many EU states.\nNotice must be given \u201cwithout undue delay and, where feasible, not later than 72 hours after having become aware of it.\u201d For those familiar with the recent Equifax breach, the organization\u00a0waited six weeks\u00a0before 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.\nThe notification to the supervisory authority must include \u201cat least\u201d the following:\n\nThe nature of the personal data breach, including the number and categories of data subjects and personal data records affected.\u00a0\nThe Data Protection Officer\u2019s (we\u2019ll cover this role in detail in a future post) contact information.\nThe likely consequences of the personal data breach.\nHow the controller proposes to address the breach, including any mitigation efforts.\n\nThe GDPR does provide some exceptions to the additional requirement of notifying the data subjects of the personal data breach, if:\n\nThe 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.)\nThe controller takes actions subsequent to the personal data breach to \u201censure that the high risk for the rights and freedoms of data subjects\u201d is unlikely to materialize.\nNotification to each data subject would involve disproportionate effort, in which case alternative communication measures may be used\n\nComplying 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 \u201cpersonal data\u201d and understanding if a breach has occurred in the first place. The latter is well outside of our area of expertise, but we\u2019ll 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.\nAt 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\u2019 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\u2019 best interests.\nStay tuned for our next week\u2019s installment as we dig into the roles required and discovery process.\nRead more about Delphix.