Steps to GDPR Compliance: Data Breach
Post number 7/12 in HireRight's "Steps to GDPR Compliance" blog series covers data breaches, including the different types of data breach and what are how are businesses required to report data breaches under the GDPR.
Step 7 – Data Breaches
“Once more unto the breach….” Why galvanising your troops to deal with data breach is a key part of compliance with the GDPR
Introduction to data breaches
The GDPR introduces a duty on organisations to report certain data breaches to their supervisory authority (Article 33) and, in some cases, to individuals (Article 34). The GDPR now makes it mandatory for all data controllers to notify the supervisory authority unless a breach is unlikely to result in a risk to the rights and freedoms of individuals. Data processors also have an important role to play, and they must notify their controller of any breach.
This is the latest topic to be tackled by the Article 29 Working Party, who issued their guidelines on data breach notification for consultation. The consultation period will run for 6 weeks from 17 October 2017. Read the Article 29 Working Party guidelines.
What is a data breach?
The GDPR defines a “personal data breach” in Article 4(12) as “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”. In essence, a data breach for the purposes of the GDPR is a type of security incident where there is a breach of personal data.
The Working 29 Party opines that a personal data breach under the GDPR breaks down into, and can be one or a combination of, three categories:
“Confidentiality breach” – where there is an unauthorised or accidental disclosure of, or access to, personal data.
“Availability breach” – where there is an accidental or unauthorised loss of access to, or destruction of, personal data.
“Integrity breach” – where there is an unauthorised or accidental alteration of personal data.
What types of data breaches require notification?
Supervisory authority: Data controllers only must notify the relevant supervisory authority of a breach where it is likely to result in a risk to the rights and freedoms of individuals. If unaddressed, such a breach is likely to have a significant detrimental effect on individuals – for example, result in discrimination, damage to reputation, financial loss, loss of confidentiality or any other significant economic or social disadvantage. The data controller will need to assess this on a case-by-case basis. For example, they likely will need to notify the relevant supervisory authority about a loss of customer details where the breach leaves individuals open to identity theft. On the other hand, the loss or inappropriate alteration of something like a staff telephone list, for example, would not normally meet this threshold.
Individuals: Where a breach is likely to result in a high risk to the rights and freedoms of individuals, the data controller must notify those individuals directly.
A ‘high risk’ means the threshold for notifying individuals is generally higher than for notifying the relevant supervisory authority.
Who has to notify and in what time period?
A notifiable breach has to be reported by the data controller to the relevant supervisory authority without “undue delay” and in any event within 72 hours of the organisation becoming aware of the breach. This seems like a tight time frame, but the GDPR does recognise that it will often be impossible to investigate a breach fully within that time-period and therefore allows for the disclosure of information in phases.
How to rally the troops – can your data processor support your data breach notification efforts?
The simply answer is “yes”. The data processor has an important role to play in supporting the controller’s data breach notification efforts.
Article 28(3)(f) of the GDPR requires that a controller has in place with its third party processors contractual arrangements governing processing of data, including in respect to assisting the controller in complying with its obligations under Articles 32 to 36 (i.e. data breach).
What does that actually mean? Article 33(2) states that a processor must inform the controller of any breach of the personal data it handles “without undue delay”. However, there is no definition of what “without undue delay” means exactly.
Interestingly, the Working 29 Party guidance appears to be a little contradictory in respect to what it interprets this to mean vis-a-vis a controller and processor.
The guidance states that in respect to the controller, the controller should be regarded as having become “aware” when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. This allows for a period of investigation to take place before controller notification to the supervisory authority is required.
However, in respect to processors, the guidance states that the controller becomes aware when their processor becomes aware of the breach. The Working 29 Party therefore recommends that the notification from the processor to the controller occur immediately, with further information about the breach provided by the processor in phases as information becomes available. This apparently is on the basis that this is important in order to help the controller to meet the requirement of notification to the supervisory authority within 72 hours.
However, it seems that this notification framework could be impractical to support and lead to incidents being reported by the processor before adequate information has been gathered to establish a breach has occurred. It seems reasonable that the processor should also have a period of time in which to investigate an incident before it must notify the controller.
Perhaps it would be good practice to set out in detail a data breach response plan in any contract between a controller and processor. The intent of this would be to allow the processor to carry out reasonable steps such as following an internal incident response plan and appropriate internal reporting before notifying the controller. Time constraints would need to be imposed to ensure that the controller can still comply with its own obligations. E.g., controllers taking the most stringent interpretation of their 72-hour notification requirements may want to impose requirements of 48-hours’ notice by processors of any actual or suspected breach in order to maintain at least a further 24 hours to be able to notify any supervisory authority should the controller determine it to be necessary or appropriate.
Conclusion
The data breach requirements are stringent and will result in fines for your organisation if not dealt with appropriately. The timescales for reporting data breaches are tight, and therefore it is important to have robust breach detection, investigation, and internal reporting procedures in place, and these should be accounted for in any contract that a controller has in place with its processor.
Release Date: December 29, 2017
Caroline Smith
Caroline is a UK qualified lawyer with over 18 years’ experience and currently serves as HireRight’s Deputy General Counsel for the EMEA and APAC regions. When not “lawyering” or writing blogs, Caroline can be found striking yoga poses in remote locations such as Mongolia and Bhutan.