In this installment of 
A Deeper Dive, let’s take a look at GDPR’s breach notification requirements. The old adage applies when it comes to security breaches, an ounce of prevention is worth a pound of cure. No organization wants to be the victim of a data breach. The aftermath costs exorbitant amounts of money and has immeasurable affects to your reputation, not to mention the fact that it causes real damage to the individuals whose data was compromised. Yet, breaches happen every day. 2016 saw 1,792 reported breach incidents worldwide that exposed over 1.3 billion records.
GDPR’s stance on this is clear. If you’re breached and it risks the rights and freedoms of those whose data is affected, your organization will be responsible for notifying both the supervisory authority for your region, and the affected data subjects. Article 33 (Notification of a personal data breach to the supervisory authority) lays out this requirement. It states:
“1. In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”
In short, in the event of a breach, the victimized organization will have to notify their regulator within 72 hours. At first glance, this may seem a cut and dry requirement. However, the requirement isn’t absolute. The notification obligation is triggered only if the data breach jeopardizes the subjects’ rights and freedoms. The following article (number 34) entitled ‘Communication of a personal data breach to the data subject’ goes further in describing the exemption starting in sub-point 3 which states:
“3. The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:
(a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;”
In short, the combination of these two articles says that organizations can avoid their notification obligations – to both regulators and the data subjects – by adopting encryption and enterprise key management to keep their customers’ data safe.
To understand why encryption plays this role, we again return to its fundamental nature; it attaches security to the data itself. Only those that have access to the appropriate encryption key can read data in clear text. So, when a breach occurs, encrypted personal data will remain protected and unreadable to unauthorized users, rendering it unlikely that the rights and freedoms of those affected will be at risk.
Part of the challenge, though, will be in demonstrating to the appropriate regulatory bodies that, in the face of the data breach, these risks are unlikely. As the crux to any encryption deployment, the key manager will be the tool that lets organizations show minimized risk. Best practice dictates that key material should be stored separately from both where encryption takes place and where encrypted data is stored. The same key management functions that establish an organization’s data control will be the ones that demonstrate to regulators that breached data is unusable and poses no risk to the subjects. (For more on this see last week’s post on GDPR’s data integrity and control requirements.) Since decrypting data requires a key, monitoring and recording who accesses the keys and how they are used gives a complete map of access to the data. Storing and managing those keys separately in a secure external key management appliance, centralizes that oversight – with only one way in and out of the key management appliance, the corresponding logs serve as demonstrable proof that only authorized users accessed the keys, and consequently could access the data. In the event of a breach, a hacker or privileged user may abscond with encrypted data, but with proper key management in place, they won’t be able to use it for their gain. Without the corresponding key, it is highly unlikely, or even virtually impossible, that the data will ever be readable thus protecting the rights and the freedoms of the individuals concerned.
In this way, organizations can avoid GDPR’s breach notification requirements.
Encryption not only insulates organizations from the damage a data breach causes, it also helps them preserve their reputation in the eyes of their customers and the general public. Data breaches are more common than we like to admit and they affect organizations large and small – public and private. GDPR won’t let organizations off the hook. If an organization is breached and the appropriate safeguards aren’t in place, then they will have to tell regulators and the world that they were unprepared. And, these consequences don’t even take into account the impending fines they will surely face. Fortunately, solutions are out there to mitigate those risks so no organization should have to bear the indignity of that mea culpa.
Much like data integrity and control, breach notification is still only one piece of the larger GDPR story. Next week we’ll take a look at GDPR’s expectations around risk mitigation and due diligence for collaborative contractual relationships. Stay tuned!
Do you understand GDPR Compliance? Read The General Data Protection Regulation ebook.
