Personal data breach reporting: Article 29 Working Party issues final guidelines

The General Data Protection Regulation introduces obligations for:

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:

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. If the controller has any doubt as to which authority is the lead, then it should notify the authority in the member state where the breach has taken place. 

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.

Documentation

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. 

Be prepared

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 notes that service providers should notify the controller of all breaches, irrespective of risk: it is for the controller to determine if the risk presented by the breach means that the controller should notify the breach to data protection authorities. The processor should notify the controller 'without undue delay'. WP29's original guidelines suggested that, in practice, should notification should take place immediately: the final guidelines replace this with an obligation for 'prompt' reporting. 

According to WP29, the controller will be aware of the breach once the processor has reported it to it.

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. 

Phased reporting

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.