- Data Strategy,
– 02 Jul, 2018
Dealing with Data Breaches under GDPR
There are at least three types of data breaches, which are not mutually exclusive: Breach of Confidentiality, Breach of Integrity and Breach of Availability.
Opinion Piece by Paul Gillingwater, MBA, CISM, CISSP
Breach of Confidentiality
This first type of breach is clear: confidentiality breaches mean unauthorised disclosure of data, which may be personal or otherwise.
For example, a company’s financial position including bank balance and monthly revenues would be confidential data, but is not personal data.
Breach of Integrity
A breach of integrity means that unauthorised changes were made to existing information.
As an example, a young hacker breaks into a school database, and makes changes to their student grades, or deletes negative school reports.
Breach of Availability
A breach of availability means that people who are authorised to access information or systems are prevented from doing so for more than a short period of time.
As an example, ransomware which encrypts company files, thereby preventing legitimate users from working on them, is clearly such a breach.
Is there one more?
There is a fourth type of breach which is occasionally cited but rarely seen, and which usually does not involve personal data, known as a breach of non-repudiation.
Therefore, this type of breach is usually not part of GDPR’s breach reporting obligation.
What to do in the event of a breach
Article 33 describes the obligation faced by Data Controllers and Data Processors, to report personal data breaches “unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.”
Such breaches should be reported to the relevant Data Protection Authority without delay, but certainly within 72 hours of the Controller first becoming aware of the breach.
Processors need not inform the DPA, but instead are required to inform the Controller without delay, so they can meet the 72 hour obligation.
Note that not all breaches are reportable to the authorities. Only those where there is a “risk to the rights and freedoms.”
What are such risks?
This is outlined in Recital 85, which identifies any breach that may “result in physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned.”
Furthermore, not all breaches involve personal data.
One of the first steps in your enterprise’s incident response plan should be to filter events according to whether personal data was involved, or is suspected to be involved.
Only if personal data is involved should the breach be considered a candidate for reporting to the DPA — however don’t forget that other types of breach may be reportable to other authorities, depending on the industry sector in which you are working.
For example, within the U.K., utilities and other critical infrastructure governed by the Networking and Information Systems Directive (NIS) have only 24 hours to report data breaches to a different authority.
The recital goes on to say that “Where such notification cannot be achieved within 72 hours, the reasons for the delay should accompany the notification and information may be provided in phases without undue further delay.”
A question that sometimes arises is what happens to situations where a data breach involves large scale processing of personal data belong to people from different countries.
In this case, the normal practice is to report only to the lead DPA, if this is known, and rely on the “one-stop shopping” principle for them to inform other DPAs as appropriate.
However, best practices suggest that it may be appropriate to report the breach to each affected DPA, whilst designating which DPA has the lead.
A secondary responsibility owed by Data Controllers is the obligation to inform the individual data subjects affected by the breach.
This is slightly different in wording, found in Article 34(1): “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.”
The key difference here is “high risk.”
Only if there is a high risk, are you obligated to inform the data subjects individually. The deadline for such reporting is not specified in Recital 87, which merely recommends “promptness”, and “without undue delay.”
Article 34 also outlines three conditions under which notification of data subjects may be avoided. Specifically:
- 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
- the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects referred to in paragraph 1 is no longer likely to materialise
- it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner
This requires little explanation, but an example or two may help.
Case 1, a business accidentally publishes an internal telephone and email address list of its employees to its public website. This is reportable to the supervisory authority, since there is a risk that some employees will receive unwanted telephone calls or emails, but will not be otherwise inconvenienced.
In Case 2, a medical doctor loses a memory stick containing patient records. This is clearly a much more serious breach and can lead to substantial consequences for those affected, even if it’s a single person. Such a breach must definitely be notified to the data subjects concerned.
Regarding mitigations of breaches, in the Case 2 example, if the memory stick patient records were encrypted, this would substantially reduce the impact of the breach on the data subject.
It would still be reportable to the supervisory authority, but would not require notification to the individuals concerned.
Whatever is decided, usually in conjunction with the enterprise’s DPO, the decisions made should be documented as part of the breach notification report that is sent to the supervisory authority.
What needs to be communicated as part of the breach notification?
As a start, identify the Data Controller, plus any joint controllers and data processors. Explain the category of data subjects and the scope of which data subjects and how many were likely to be impacted.
Article 33 identifies at least four major parts that should be included in the notification:
- describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned
- communicate the name and contact details of the data protection officer or another contact point where more information can be obtained
- describe the likely consequences of the personal data breach
- describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects
Note that if possible, the deadline for breach notification should be respected, even if all of the information is not available. Provide the supervisory authority with what you have, then send additional information as it becomes available.
Finally, ensure that you have good records concerning your past data breaches, and how they were handled. This is required so that the supervisory authority can verify compliance with Article 33(5).
Chaucer offers advisory services on GDPR, as well as DPO and GDPR Representative services. Please contact us on DataPrivacy@Chaucer.com or 0203 934 1099.
Paul Gillingwater MBA, CISSP, CISM, RHCE
Paul Gillingwater GDPR, ISO27001, PCI/DSS, GRC, DPA18
Paul is a Managing Principal Consultant and registered DPO at Chaucer who has worked for more than 30 years as a cyber security and risk specialist and advisor to businesses, government and non-profits with their governance, regulatory and compliance requirements. Over the past five years he has focused on UK & EU data protection and is a passionate advocate of online privacy rights education.