Businesses need to be absolutely clear about terms and definitions if they are to achieve compliance with the new General Data Protection Regulation, writes Jes Breslaw, director of strategy, EMEA at Delphix, a data management product company.
Semantics is rarely a matter of life and death, but a misunderstanding over a couple of words could do serious damage to your business. When the General Data Protection Regulation (GDPR) comes into force in May 2018, businesses will need to have a precise and thorough understanding of the various terms and definitions outlined in the most stringent of privacy regulations yet devised. The GDPR outlines the acceptable use of personal data by organisations, how they should structure their approach to managing personal data, and the fines (or risk) for improperly protecting personal data. In the event of a breach the fines for non-compliance can be extensive, with the maximum penalty set at 4pc of worldwide income or 20m euros – whichever is higher.
The intersection of technology and the law always creates a plethora of complex terms, and in the case of the GDPR, it is a lexicon that businesses must master if they are to comply fully with the letter of the regulations.
The definition
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. According to the text, a data subject is: “an identifiable natural person … 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 relevant data can be used to identify (through whatever means) a specific individual. This requires a new way of thinking about personal data: while an unnamed person’s age and gender might not seem like personally-identifiable information, in many circumstances it could be. For example, 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. An organisation may only have a single 23-year-old or a single male in an office and someone could use the available data to work out who that is.
As you can see, the set of data that is considered controlled under the GDPR is quite a bit broader than initially expected. This challenge expands as, frequently, user data can span tables (or databases). 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 the introduction of a required role, the Data Protection Officer.
Notification
Put simply, the GDPR requires that organisations 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, unauthorised 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, organisations must notify the supervisory authority. The GDPR defines two separate concepts that typically (but not always) refer to organisations – Data Controller (or Controller) and Data Processor (or Processor).
The Data Controller is the entity (in most cases, an organisation, but sometimes a person) that directs the reason why personal data is processed in the first place. For example, a ride sharing company wants to analyse 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 analyses / processes data.
The Data Processor is the entity (again a person or organisation, etc.) that actually does the processing or analysis of data. For example, banks frequently outsource their fraud analysis to third parties. In this 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 organisation must notify the supervisory authority of the member state where the data controller has its main establishment and the affected data subjects. For example, if an organisation 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.
The notification checklist
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 organisation 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 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 organisational protection measures that render the data unintelligible to any person who is not authorised to access it
– The controller takes actions subsequent to the personal data breach to “ensure threats against the rights and freedoms of data subjects are unlikely to materialise; and
– Notification to each data subject would involve disproportionate effort, in which case alternative communication measures may be used.
Complying with the breach notification requirements is only a part of the spirit of the regulation. Effectively doing so requires two other steps. The first, assessing which data an organisation has that is considered to be “personal data”. The second, understanding if a breach has occurred in the first place.
At the end, however, the major push for understanding these requirements comes down to the potential penalties. With a ceiling of 4pc of worldwide income (measured by the prior year) or €20m, the impact of a breach is extreme. The implications go further, however. Not only must organisations ensure they protect individuals’ data, but they must institute organisational 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. When we think of data protection we associate it with a company’s critical systems and the live data that sits within them. But the reality is that 90% of an organisations data sits in non-production systems like development and test environments, compliance and financial reporting systems, analytics and big data tools and archive/backup tools.
This is where DataOps can be such a powerful tool. DataOps is an approach which focuses on aligning people, process, and technology to enable the rapid, automated, and secure management of data. Its goal is to eliminate ‘data friction’ – the functional gap between the huge volumes and copies of information that we generate and our ability to use it securely and effectively.
With regards to the GDPR, DataOps can create a comprehensive library of data sources that enables users to pinpoint the exact location of sensitive data across an organisation’s entire IT estate, whether on-premises or in the cloud. What is more, with the right tools organisations can identify which data values are subject to GDPR, and adapt these to the business’ unique definitions of what is considered personal, confidential information.
Identifying personal data is only half the challenge, protecting it comes next and a big challenge to companies is masking this data for all live and non-production systems. If you can successfully mask say all your test data, then that in essence removes it from GDPR compliance. Modern dynamic data platforms can be used to apply masking policies for multiple systems at once in a matter of minutes meaning you can be GDPR compliant without inhibiting speed or agility.
With the right processes and technology in place, it’s possible for any organisation to keep track of all sensitive information, mask and pseudonymise it (or rather, hold it in a format that does not directly identify a specific individual without the use of additional information) where necessary, and control who has access to data and for how long. Like all the best technical approaches, it goes beyond mere compliance – crucial as that is – and gives organisations the best, most robust way of protecting their customers’ most valuable assets: their data and their identity.
