WP29 guidelines on personal data breach notification under GDPR
Browse this blog post
The Article 29 Working Party this week published draft Guidelines on personal data breach notification under GDPR. The relevant GDPR provisions are often misrepresented, and in many respects leave matters open to interpretation – a good or bad thing depending on the day. Many are now asking what further clarity the draft guidelines bring for companies looking to design and implement a GDPR-compliant incident response and breach notification process in time for May 2018.
GDPR makes it clear that a wide range of types of risk must be considered in assessing the impact of a personal data breach: physical, material, or non-material damage. The more difficult question is whether the degree of risk is such that the supervisory authority or the affected data subjects must be notified.
The draft guidelines refer to the European Union Agency for Network and Information Security (ENISA) recommendations for assessing the severity of a breach; these entail a scoring system based on multiple factors which can then be adjusted for contextual factors; the output then shows the severity from low (data subjects either will not be affected or may encounter a few inconveniences, which they will overcome without any problem (time spent re-entering information, annoyances, irritations, etc.) to very high (data subjects may encounter significant, or even irreversible, consequences, which they may not overcome (financial distress such as substantial debt or inability to work, long-term psychological or physical ailments, death, etc.).
The draft guidelines themselves offer no further principles by which to measure the differential between breaches triggering a notification to supervisory authority only, compared to those requiring notification to the data subject. A table of examples is provided, but all examples should be treated with caution. The draft guidelines make it clear that a case-by-case analysis is required; the context in which a data breach arises may indicate a different decision from that provided in the example.
A continuing obligation
The draft guidelines note that the effect of a data breach must be monitored, the risk re-evaluated and the notification decisions reviewed. In principle this must be right but this continuing obligation will need to be managed carefully so as not to become an undue compliance burden. Further guidance, for example on circumstances in which the risk might be assumed to decrease with the age of the breach, would be welcomed.
Notification to both supervisory authorities and data subjects is a controller obligation. A processor can make the notification on behalf of the controller but WP29 emphasises that legal responsibility to make the notification remains with the controller. In any event, the envisaged dialogue with the supervisory authorities, the risk assessment and continuing obligations to review make this a process that will usually be best performed by the controller. However, processors are integral to the controller’s compliance: the controller is deemed to be aware of a breach once a processor is aware; there is no time lag and the onus is on controllers to ensure that the basic GDPR obligations on processors to notify controllers without undue delay and to provide them with necessary information are supplemented by more detailed contractual obligations.
When does the clock start ticking?
Controllers have to notify both the supervisory authority and affected data subjects without undue delay (and, where feasible, notifications to the supervisory authority need to be made within 72 hours) of having become aware of the breach, i.e. having a reasonable degree of certainty that there has been an incident that has led to a personal data breach. Anyone hoping to delay notification by inserting a drawn-out investigation process should think again, as the draft guidelines make it clear that failure to act in a timely manner when it becomes apparent that a breach may have occurred may itself be considered as a failure to notify. A short period for investigation is permitted to establish the reasonable degree of certainty and the possible consequences; at that point the controller is deemed to be aware and the controller must consider whether to notify. From that point there must be no undue delay to notifications (to the extent they are required).
Although both notifications are to be given without undue delay, there could be a difference in timing: the point of the notification to supervisory authorities is to encourage controllers to act promptly on a breach, contain it and, if possible, recover the compromised personal data, and to seek relevant advice from the supervisory authority. The draft guidelines indicate that notifying the supervisory authority within the first 72 hours can allow the controller to make sure that decisions about notifying or not notifying data subjects are correct. On the other hand, supervisory authority notification may not serve as a justification for failure to communicate the breach to the data subject where it is required; in exceptional cases communication to the data subject may precede that to the supervisory authority. Once again, the context must be considered bearing in mind that the purpose of the notification to affected data subjects is to help them to take steps to protect themselves from any negative consequences of the breach.
Exceeding the 72 hour longstop for supervisory authority notification
The draft guidelines suggest it will be rare that a delay beyond 72 hours is justified.
The draft guidelines contemplate the use of a bundled notification addressing multiple similar breaches concerning the same type of personal data breach, which emerge over a short period of time and affect large numbers of data subjects in the same way. However, the draft guidelines note that bundled notifications can also be made for multiple similar breaches reported within 72 hours. It may be wise to treat this example as justifying delayed notification only because the severity of the breach only becomes clear once the chain of breaches is known.
The draft guidelines add little to the text of GDPR on this topic except to note that the analysis made should be documented and that the decision reviewed and risk reassessed over time.
Data subjects in other member states
Although GDPR only requires the lead supervisory authority to be notified, the draft guidelines note that controllers may choose also to proactively report to the supervisory authority where the data subjects are located and recommends that controllers should at least indicate to the lead supervisory authority if establishments are located in other member states or data subjects in other member states are likely to have been affected by the breach. Identifying where affected data subjects are located will also be essential to communicating with them effectively.
Communication to data subjects
Breach notifications and information about how to mitigate damage should not be sent with other information: dedicated messages should be used.
More than one channel may need to be used, including direct messaging (e.g. email, SMS, direct message), prominent website banners or notification, postal communications and prominent advertisements in print media. A notification solely confined within a press release or corporate blog would not suffice.
Appropriate formats and relevant languages (including the native language of the recipient) should be used to ensure data subjects are able to understand the information being provided to them.
Embed data breach response in all aspects of data processing
Although the draft guidelines do not provide many concrete answers , they do highlight the importance of ensuring that all processing operations are designed with breach notification obligations in mind: records of processing, DPIAs, security measures, reporting lines, processor contracts, and more, will all play a part in ensuring that the controller is able to act appropriately upon a breach occurring. It is a reminder that GDPR requires a holistic approach to the data security lifecycle and that compliant breach notification is merely one aspect of good preparation throughout that lifecycle.