As of this writing, we have just over 190 days before the General Data Protection Regulation (GDPR) becomes effective on 25th May 2018. If you exclude weekends, that becomes just over 130 days. That’s not a lot of time to get your organization ready for the GDPR.
I’ve written a number of blogs on GDPR, and for this one I want to focus on the topic of data breaches, because that’s where a lot of the GDPR pain comes from.
Helpfully, the Article 29 Data Protection Working Party (WP29) produced a guideline to data breaches last month: 17/EN 250 “Guidelines on Personal data breach notification under Regulation 2016/679.”
Why does it matter?
GDPR fines will come from transgressions: Article 83 describes that data controllers in breach of Article 5 requirements can be served up to the highest possible fines.
Article 5.1(f) deals with handling of personal data such that controllers ensure that it is processed in a manner to prevent “unauthorised or unlawful processing and against accidental loss, destruction or damage.”
Article 32 for data processors deals with processing security, and processors are to “ensure a level of security appropriate to the risk.” Failure can lead to fines up to the second tier of fines.
So, a proper understanding of data breaches, and managing them with “appropriate technical and organisational measures” will in all likelihood stop or reduce your GDPR fines.
Types of personal data breaches
WP29 defined three types of personal data breaches:
- “Confidentiality breach” – seeing personal data one shouldn’t
- “Availability breach” – losing control of access to personal data, or inappropriate deletion of personal data
- “Integrity breach” – inappropriate alterations to personal data
A data breach could be one or any combination of the above.
Severity of breaches will need to be assessed on a case-by-case basis taking the “risk to the rights and freedoms of natural persons” as the yardstick. Adverse effects are “physical, material, or non-material damage” and can include:
- Loss of control over personal data
- Limitation of data subject’s rights
- Identity theft or fraud
- Financial loss
- Unauthorized reversal of pseudonymization
- Damage to reputation
- Loss of confidentiality of personal data protected by professional secrecy
- Any other significant economic or social disadvantage
- The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
Data breaches are therefore not ‘just’ obvious cases of leaving laptops or USB sticks on a train, or someone hacking into your systems and stealing personal data. They reach much wider and are far subtler.
Furthermore, regulators have the power to enforce the regulation in the context of accountability, to require evidence of data protection by design, and evidence to demonstrate good data protection is a cornerstone of their operations and culture.
The WP29 Guidance document also provides some fascinating examples of data breaches:
- The only copy of a set of personal data has been encrypted by ransomware, or has been encrypted by the controller using a key that is no longer in its possession or has been lost.
- Significant disruption to the normal service due to power failure or denial of service attack rendering personal data unavailable even temporarily. if the risk is significant (for example, if critical medical data about patients is unavailable and operations must be cancelled).
- Infection by ransomware leading to a temporary outage for a media company is most likely not a breach if a ghost image and backup can be restored resulting in low downtime. However, if personal data was accessed at the same time, this could result in risk to data subjects and be a data breach.
- Personal data is securely encrypted with state-of-the-art technology, the data is lost or stolen, the de-encryption key is safe, rendering the encrypted copy useless, and there is a backup. This first case is likely not a breach; however, this may still constitute a breach if it takes a long time (tens of hours) for a backup copy to be restored and normal services resume.
- In the above example, if at a later stage it is discovered that the de-encryption key or process is not secure, the first case would become a data breach.
- In the above example, if there is no backup of the data and services cannot be restored, this could be a data breach
- Systemic gaps in processes that can allow personal data from one subject be made visible/sent to another data subject.
Some helpful points to note on data breaches and breach notifications:
- There isn’t going to be a penalty for reporting an incident that ultimately turns out not to be a data breach.
- Where personal data are already publicly available, a disclosure by another party of the same data is not going to be a risk to individuals and is not going to be considered a data breach.
- Not all data breaches require supervising authorities or data subject to be notified; for example, an organization has a securely encrypted backup of an archive on a CD, and it is stolen.
Bear in mind, the GDPR will also most likely be updated over time, and there are other data/security related regulations already in the wings such as the NIS and the e-Privacy directive.
Organizations would do themselves a great favor if they saw this as an opportunity to address a cultural mind-set change towards a “value-add” approach to how they run their business, as opposed to a compliance tick-the-box “value-retain” approach.
I anticipate that 2018 is going to be the year for organizations to properly understand the sea change in data protection, not the quick-fix approaches I see a lot of at the moment. Making a few narrow technical fixes to some of the more obvious GDPR requirements is not going to provide a midterm, never mind long-term, solution. Invest precious resources wisely now, and reap the benefits to follow.
Read all the GRC Tuesday series blogs on GDPR to learn more about the regulations and what you can do to get your company ready.