EDPB’s case digest on Security of Processing and Data Breach Notification – all you need to know

What are the key themes and most important points? Read below to see the key takeaways.

Scope and Process

The survey draws together cases which have been dealt with by way of the One-Stop-Shop mechanism under Article 60 of the GDPR. What that means is that where there is more than one concerned supervisory authority in the EU, the authority which is deemed to be the Lead Supervisory Authority (‘LSA’) will conduct and lead the investigation but then seek views and input from all other concerned authorities. What this is designed to produce is an international consensus about the nature and severity of the breach, any appropriate penalty and any recommended remedial steps. As noted, the majority of the issues dealt with centre on compliance with A.32 which places an obligation on controllers and processors to ‘implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk’; the report confirms that the majority of the decisions cited focus on the LSA’s assessment against these criteria. Whilst the phrase ‘appropriate technical and organisational measures’ will be familiar to data protection practitioners; it has historically been more difficult to state with certainty what exactly that would amount to in practice in any given situation. The position is made more complex by the fact that one of the key factors to be taken into account in assessing whether measures are ’appropriate’ is the current ‘state of the art’ in terms of security measures. Given the rapid pace of change within computer systems and the cyber security measures put in place to protect them, and the corresponding changes in methods by those seeking to unlawfully access the data contained within those systems, the state of the art remains a constantly moving target. The value of this survey is therefore not only to provide an up to date and comprehensive snapshot of measures which are deemed to be appropriate, or not, but also that it is done within the A.60 framework meaning there is a level of consistency and agreement between different supervisory authorities.

Key areas of focus

The survey sets the scene by clarifying the obligations under A.32 as set out above and is put forward in terms of providing insights to allow Supervisory Authorities to interpret those obligations in concrete situations. Key areas include how to protect organisations against hacking, how to ensure meaningful and robust encryption and how to implement strong passwords. Implicit in this is also that regulators can use this information in order to assess when and against whom they should be taking enforcement action for failing to comply with their A.32 obligations. This in turn means that controllers and processors have concrete examples of guidance points which they can use to make sure their security measures will stand up to regulatory scrutiny if tested. A summary table of the key findings cited is set out below.

The section on Article 33, regarding notification of data breach to the competent supervisory authority focusses on where the line should properly be drawn when deciding whether notification is required or not. In turn, the section on Article 34, regarding notification of data subjects seeks to provide clarity on when notification to data subjects is required.

Article 32

A key issue identified is that raised in the CJEU case of Natsionalna agentsia za prihodite (C-340/21) which addresses, amongst other points, the question of whether the occurrence of a personal data breach, in itself, is sufficient evidence to presume that there has been a failure to implement appropriate technical and organisational measures. The general thinking on this point has been that this cannot be correct, as it would mean that where a data breach occurred through no fault of the controller/processor it would still be deemed to be a breach of GDPR, effectively imposing strict liability for such breaches. The Court endorsed that approach and confirmed that A.32 must be interpreted as meaning that unauthorised access to personal data by a ‘third party’, is not sufficient, in itself, to establish that the technical and organisational measures that were implemented were not ‘appropriate’, and indeed that an obligation to demonstrate the appropriateness of those measures would make no sense if controllers were obliged to prevent all such breaches.

The analysis is then divided into looking at three categories of causes of personal data breaches, namely

1. malicious attacks by external entities i.e., cyber-attacks
2. breaches due to insufficient company practices and systems, and
3. breaches caused by human error.

It is interesting, but perhaps unsurprising, that the majority of the cases decided under A.60 in this context relate to category one, namely malicious external attacks. This has long been an area of concern for organisations seeking to protect their businesses and the personal data they hold, not only from the serious effects of such malicious cyber-attacks but also the added regulatory risk of being penalised by data regulators for failing to do enough to guard against such attacks. Key themes in terms of measures that LSAs cite with approval include ensuring that there are robust company policies relating to data security, including those to combat phishing attacks and frequent awareness-raising for employees. Another point drawn out in a number of cases is that encryption of personal data, and the security of that encryption is a key factor in assessing the suitability of security measures. There is also particular focus in a number of cases on the importance of establishing proper access controls, to make sure that systems are locked down sufficiently and only those individuals who need to access particular data sets have the ability to do so. This is often a key problem with cyber-attacks, given that once an attacker has gained entry to one part of a system, without proper access controls they are often able to move into many other parts of the system making the negative effects much wider and more serious.

In relation to Category (2) one point of particular interest, which is likely to have practical implications for many organisations is the issue of sending out encrypted and password protected documents to company users, or in response to data subject access requests. The consensus here is clear that doing so by sending a protected email, shortly followed by another email with a (often very weak) password by the same channel is not sufficient to meet the requirements of A.32. Concrete recommendations on how to do this properly are set out in more detail but this is certainly an area that organisations should look at closely.

Regarding Category (3) the perennial errors of disclosing email addresses by the incorrect use of ‘cc’ and ‘bcc’ fields remains an issue. LSA’s recommend that technical measures are put in place to ensure as far as possible that this does not happen, and that various prompts and nudges are built into systems to minimise the possibility of it happening. There is also usefully detailed commentary on what is considered to be an appropriate level of security when setting and storing passwords, with the recognition that ensuring sufficiently strong and secure passwords are used is a key necessary measure to ensure the security of personal data.

A.33 Notification of Data Breaches to supervisory authorities

This section is less detailed, reflecting the number of cases relating to this Article. One case cited referred to the obligations under A.33(5) to document the details of a data breach and found that this had not been done sufficiently clearly for the LSA to identify whether the organisation had complied with its obligations under A.33. In another case, this being a point of particular interest, the point was clarified that where controllers experience a number of linked data breaches each breach should be notified as soon as possible after it occurs, rather than waiting to report all linked breaches together at a later date. It is apparent that such a combined approach does not find favour with regulators and doing so risks being penalised for late reporting of the earlier breaches. In that particular case the delay in notification was found not to be justified and accordingly to constitute a breach of A.33(1).

A.34 Communication of Data Breaches to data subjects

Only two cases are cited in this section. The first refers to a decision of the Bulgarian authority which includes their development of a methodology to assess the severity of the risk to the rights and freedoms of the data subjects affected. This approach is of interest as a broader consensus on this type of methodology would be valuable in assessing more objectively whether the threshold for notification of data subjects had been met in any particular case, in line with the methodology previously put forward by The European Union Agency for Network and Information Security (ENISA). The second case relates to the specific facts of a breach where the LSA agreed that it had been appropriate to notify affected employees but the threshold had not been met requiring notification to customers, as only employee data had been affected.

Conclusion

This digest of cases from across the EU is an extremely valuable resource and given that supervisory authorities are likely to use it as a reference when deciding what position to take, especially when investigating security breaches caused by malicious external actors, companies seeking to protect against such attacks would do well to do the same. One final point to consider is the UK position, given that post Brexit the UK is no longer part of the Article 60 mechanism and the ICO can take decisions independently of any European Union caselaw or guidance. Whilst that is the case, the ICO continues to cite with approval within its own guidance various pieces of EDPB guidance, including in particular that relating to personal data breach reporting. That being so it seems likely that even though not bound to do so the ICO will review and consider with approval the cases cited within this digest and will use it as a useful resource when considering cases under Articles 32, 33 and 34.

Figure 1. – Summary table of key findings re. Article 32

If you need further guidance, please do get in touch with the contributors.