On 3rd October 2017, the Article 29 Working Party (WP29) issued draft guidelines on personal data breach reporting.
The General Data Protection Regulation introduces obligations for:
Data controllers to report personal data breaches
to data protection authorities within 72 hours
unless a breach is unlikely to result in a risk to individuals
to individuals without undue delay
where there is a likely high risk of adverse effects
Data processors to report personal data breaches
to data controllers but not to authorities or individuals
Sanctions: 2+ 2= 4%
The GDPR introduces two tiers of sanctions. Failure to report a personal data breach can attract fines of up to 2% of worldwide turnover (as opposed to the higher 4% level). However, WP29 notes that failure to report a personal data breach may also indicate a wider failing in security measures (as not having systems in place to address breach reporting is itself a security failing). This may then attract a separate 2% sanction. WP29 emphasizes that it sees these as two separate infringements, attracting separate, and cumulative, fines.
72 hours is fast: when does the clock start?
Time starts to run from the moment the controller becomes 'aware' of the breach. WP29 considers that this requires a 'reasonable degree of certainty' that a security incident has occurred which has led to personal data being compromised. WP29 notes that, whilst in some cases this may be clear at the outset, in other case it may take some time to establish that personal data has been compromised.
WP29 emphasises that any investigation by the controller should begin as soon as possible: the aim should be to establish quickly whether a breach has taken place. A more detailed investigation can then follow later. WP29 considers that this should all be completed soon after the initial alert – only in exceptional cases should this take longer.
WP29 gives examples to assist with determining when the clock starts to run:
Loss of unencrypted media
Controller aware as soon as realises the media has been lost.
Fact that controller does not know whether unauthorised persons have gained access not relevant
Third party advises controller they have bene sent personal data by the controller in error
Controller immediately aware of the breach
Controller detects possible network intrusion
Controller should establish if there is personal data on the system has been compromised. Aware once controller confirms this is the case
Cybercriminal contacts controller with ransom demand after hacking system
Controller immediately aware
Who do you need to call?
In the draft guidance on one- stop- shop, WP29 suggested that one benefit of knowing your lead authority would be that you only had to report personal data breaches affecting cross border processing to that lead authority. The final text deleted this sentence – casting doubt over the role of the lead authority in breach reporting.
The draft Guidelines on personal data breach reporting do refer to streamlined breach reporting. Where there is cross-border processing of personal data and a breach affects individuals in more than one member states, then the controller must notify its lead supervisory authority. WP29 suggest that the controller may choose to notify authorities in other member states where individuals are affected. If the controller chooses not to do this, then it should advise the lead authority in which other member states individuals are likely to be affected.
When does a breach not need to be reported?
There is no need to report breaches to data protection authorities if the breach is 'unlikely to result in a risk to the rights and freedoms of natural persons'.
Controllers should only report to individuals when the breach poses a 'high risk' – to avoid unnecessary notification fatigue.
There are examples throughout the Guidelines of what may, or may not, need to be reported and there is an Annex of worked examples, which do, or do not, need to be reported.
By way of examples:
- A breach involving data which is already publicly available, where there is no likely risk to individuals would not need to be notified
- A loss of encrypted data would not need to be reported – provided that the key is held securely and that the encryption was operational when the device was lost. (Some devices have encryption which is only active when the device is turned off; others are more sophisticated). Any decision not to report due to use of encryption should be revisited if facts change – for example, if it turns out that key management was not secure.
Even breaches which are not reported must be recorded: there must be a record of the breach, its effects and the remedial action taken. This must be available to the data protection authority to verify compliance. In addition, WP29 recommends recording the reasons for decisions – for example not to notify, including reasons why the controller concluded that the breach was unlikely to pose a risk, or a high risk, to individuals.
WP29 emphasises that it is important to have measures in place to be able to detect and respond to breaches: this is part of the security principle in GDPR. This could include use of audit logs, or automated tools advising of irregularities in access, erasure or modification of data. Incident response plans are also required, including reporting to a responsible person(s). This could be the DPO – if an organisation has one. The DPO must also be named in any report to a data protection authority. Finally, organisations should ensure that employees are aware of these procedures and what to do if there is an incident.
What about service providers?
Service providers are required to notify and to assist the data controller. WP29 takes the view that as soon as the service provider is aware of the breach, the controller will be imputed with this knowledge. As a result, WP29 recommends that controllers should require service providers to notify controllers immediately they are aware of a breach – so that the controller can meet its own reporting deadline.
If the final Guidelines stay in this form, contracts with service providers will, therefore, need to reflect this. Anyone who had tried to get a head-start on GDPR by anticipating requirements in their service provider contracts, and who had merely required reporting 'without undue delay' may need to amend contracts, so as to require a report immediately that the processor has established, with a reasonable degree of certainty, that a breach has occurred.
What needs to be reported?
GDPR provides that reports must include, where possible, categories and approximate number of individuals and categories and approximate number of personal data records. Likely consequences of the breach must be described and the measures being taken or proposed to mitigate the breach. Contact details are also required.
WP29 emphasizes that the focus is on assessment of risk – so precise numbers are not needed, but factors relevant to risk should be highlighted (i.e. special categories of data, vulnerable groups). WP29 also suggests that if the breach is caused by a processor – and if the processor has caused a breach for multiple controllers – that the controller 'may find it useful to name its processor [in the report] if it is at the root cause'.
The guidelines include recommendations on how to notify individuals. There are no surprises here: local language is recommended, as is avoiding using a contact channel compromised by the breach.
GDPR allows reporting in phases, if all the required information is not available. WP29 recognises that this is particularly likely to be required for cyber security incidents, where complex forensic analysis can be necessary. However, if there is an obvious risk to individuals, then the fact that GDPR allows phased reporting should not be used to delay provision of notice to individuals. Where reports are delayed, a mea culpa should be provided along with the report.
What is a data breach in any event?
GDPR has a wide approach to this - data breaches to be reported include destruction, damage, loss and unauthorised access of personal data. Loss is interpreted as loss of control – so a ransomware attack would qualify under this head.
Security is often described in terms of confidentiality, availability and integrity of data. WP29 considers loss of availability to be less obvious than the other types of security breach and gives examples of loss of availability. The examples include:
- Accidental or unauthorised deletion of data
- Loss of a decryption key for encrypted data
- Power failure resulting in personal data unavailable.
WP29 notes that even a temporary loss of availability is a personal data breach, which should be documented. Whether or not such breaches have to be reported to authorities or individuals though will depend on the risk posed by the incident. However, even a temporary loss of power affecting personal data records should be documented.
That's quite a lot to do: is that everything?
WP29 reminds that GDPR is not the only breach reporting requirement. Depending on sector and country, controllers may also have to report data breaches to other authorities under other legal instruments – such as the NIS Directive.