4

The NISD establishes an incident reporting framework covering the notification of significant incidents as well as requiring the implementation of security measures. As regards the obligation to report an incident, i.e. “any event having an actual adverse effect on the security of” NIS [10], the NISD differentiates between operators of essential services (OESs) [11] and digital service providers (DSPs) [12]. Member States shall ensure that OESs and DSPs notify, “without undue delay”, the National Competent Authority (NCA) [13] or the computer security incident response team (CSIRT) [14] of incidents having a significant impact on the continuity of the essential services they provide (in case of an OES), or incidents having a substantial impact on the provision of a digital service (in case of a DSP). [15] The NISD does not foresee mandatory notification of the individuals concerned by a security incident. [16] After consultation with the notifying entity, the NCA or the CSIRT may inform the public about individual incidents where public awareness is necessary in order to prevent an incident or to deal with an ongoing incident, or in the case of a DSP disclosure of the incident that is otherwise in the public interest. [17] As the NISD is a Directive, results that must be achieved are laid down, but Member States are free to decide how to achieve these aims. The amount of leeway as to the exact rules to be adopted may result in varying determination of what constitutes a “significant impact” or “undue delay”. Notification requirements may not only vary depending on the Member State but also within sectors. Only with regard to DSPs, the determination of substantial impact has been harmonised by Commission Implementing Regulation (EU) 2018/151 [18], which specifies the relevant factors to be taken into account. [19] The different level of harmonisation for treatment of OESs and DSPs is directly linked to the different services provided (with OES directly linked to physical infrastructure) and also respects that Member States are tasked with the identification of national OES. [20] Supervision of OESs and DSPs at national level may be centralised [21] or decentralised [22], resulting in a variety of National Competent Authorities (NCAs).

5

Articles 33 and 34 GDPR require data controllers to notify a personal data breach to the supervisory authority, i.e. the Data Protection Authority (DPA), within 72 hours after becoming aware of it and communicate the personal data breach to the data subject without undue delay. As a ‘Regulation’, the GDPR has binding legal force throughout every Member State and is directly applicable. The GDPR defines a ‘personal data breach’ 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”. [23] Reporting of data breaches to the competent DPA is not necessary where the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. [24] The same applies where the controller has taken steps to ensure that the high risk posed to individuals’ rights and freedoms is no longer likely to materialise. [25] Where notification of the DPA cannot be achieved within 72 hrs, information may be provided in phases without undue further delay. [26] In contrast to the NISD, data controllers must also communicate a breach to the affected individual without undue delay if there is a ‘high risk’ for the rights and freedoms of the affected individual. [27] This notice allows the controller to inform about the risks and advise individuals on how to protect themselves from the potential consequences of the breach. [28] Where direct communication to the individuals concerned would involve disproportionate effort, Article 34(3)(c) GDPR permits public communication. No guidance is provided as to when a delay is ‘undue’; Recital 86 refers to “as soon as reasonably feasible”. From a privacy perspective, this may be as soon as the data controller has determined that the prerequisites for notification foreseen in Article 34 GDPR are fulfilled. Since recital 86 also appeals for “close cooperation with the supervisory authority, respecting guidance provided by it or by other relevant authorities such as law-enforcement authorities", the determination of ‘undue delay’ depends as well on the guidance provided by the national authorities involved. [29]

6

A lex specialis provision within the NISD foresees that where a sector-specific union act foresees security or notification requirements of at least equivalent effect, these provisions shall prevail. [30] The same applies regarding pre-existing sector-specific legislation, namely, the reporting schemes of the Telecoms Framework (now: EECC) and the eIDAS Regulation.

7

The GDPR does not constitute a lex specialis to the NISD as it does not regulate the notification of a significant disruption to the provision of NIS but introduces a notification obligation where personal data is at stake. Breaches of personal data are problems in and of themselves, but a breach may indicate a vulnerability in the underlying security regime. [31] Thus, although the notification obligations are very similar, they are no duplications, and do not exclude one another. [32] While from a legal perspective, it is possible to differentiate between incidents falling under the GDPR and such falling under the NISD, in practice, most security incidents will involve some sort of personal data, meaning that the data controller will have to report these incidents to the NISD NCA and the DPA. Cooperation of these authorities in the sense of co-ordination and information-sharing is only recommended under the NISD and the GDPR framework (‘should’/‘shall’ cooperate) when dealing with an incident/data breach. They operate independently. The lack of formal cooperation may result in different advice by the NIS NCA and competent DPA to the reporting entity surrounding public disclosure of an incident. From a privacy perspective, the DPA may request instant information of the data subjects concerned, although the entity concerned has a basic interest in delaying notification to investigate an attack. In terms of delaying notification of the data subject, recital 86 GDPR requires that guidance be respected when provided by the DPA or by other relevant authorities such as law-enforcement authorities. This may suggest that guidance by a NIS NCA to delay going public may justify a delay in notifying data subjects. However, since the operative provisions of the GDPR do not require cooperation and information-sharing by the DPAs and NIS NCAs, the initiation of such cooperation may in the worst case lay at the hand of the reporting entity. The fact that cooperation is only mentioned in a recital requires to recall the nature of recitals: The recitals of an EU legal act are not in themselves legally binding in the same way that the operative articles are. In principle, recitals “state concisely the reasons for the main provisions of the enacting terms of the act”. [33] The function of recitals as an interpretative legal tool has been developed in the case law of the CJEU to resolve ambiguities where an operative provision is not clear [34] or to help to explain the purpose and intent behind a normative instrument. [35] Obviously, recital 86 goes further than explaining purpose or intent, or the reasons for Article 34 GDPR, when it appeals for “close cooperation with” authorities when determining the lawfulness of a deviation from the obligation to inform “without undue delay”. Other than the operative provisions of the GDPR, recital 86 further recognises that “the need to implement appropriate measures against continuing or similar personal data breaches may justify more time for communication”. Considering that early disclosure of an incident may interfere with the containment and recovery of an incident, it seems that the GDPR recognises this risk as a reason for delay. When the recital uses the notion ‘may’ instead of ‘must’ in relation to the justification for more time, it remains unclear which “need to implement appropriate measures against continuing or similar breaches” justifies a delay. [36] Also, the justification seems to be restricted to an ongoing attack (and ‘similar breaches’), which leads to the further question as to when an attack is still ongoing. An attack may be terminated, but the fixture of a vulnerability may be ongoing. Therefore, an entity may have a keen interest in further delaying the notification of data subjects opposed to what the GDPR requires. Considering that there are also scenarios, where the same incident is notified by two different entities to two different authorities (for instance where a DSP reports an incident to the NIS NCA, and the data controller (using a service provided by the DSP) to the competent DPA under the GDPR), there is a likelihood that an early disclosure to the public by the data controller hampers the incident response of the DSP. Instead of specifying when delay is not ‘undue’, the legislator limits its focus on legitimate suspension of notification in the following recitals on law enforcement interests. Accordingly, recital 88 GDPR sets forth that in setting detailed rules concerning the format and procedures applicable to the notification of personal data breaches, such rules and procedures should “take into account the legitimate interests of law enforcement authorities where early disclosure could unnecessarily hamper the investigation of the circumstances of a personal data breach”. In that line, the guidance on personal data breach notification issued by the Article 29 WP [37] solely addresses interests of law enforcement authorities as justifying delay. Consequently, early disclosure is primarily considered as potentially hampering criminal investigations. As of date, little attention is paid to the interests of the entity encountering a security incident. One reason for this may be the fact, that national case law in which fines have been imposed upon data controllers primarily relate to failures in implementing technical and organisational measures to ensure secure processing, right to access or right to erasure. [38] Many of the cases outlined in the EDPB 2019 annual report highlighted a lack of proper technical and organisational measures for ensuring data protection that resulted in data breaches without an outside attack. [39]

8

The question remains as to which legal consequences a data controller faces when—in order to not hamper their containment and recovery strategy—they delay notification of data subjects concerned of a data breach. Pursuant to Art. 82 (1) GDPR, they will be liable for the damage caused by the suspended or delayed notification of the subject. [40] Accordingly, this liability is limited to damage that occurs from the point of time where a delay is considered undue. The DPA may use its investigative and corrective powers (Article 58 GDPR), and, once an infringement of the obligation under Article 34 GDPR is established, may issue an administrative fine of up to EUR 10 million, or in the case of an undertaking, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher. [41] When deciding whether to impose an administrative fine and deciding on the amount of the fine due regard has to be given to a number of factors enshrined in Article 83 (2) GDPR. These factors include inter alia actions taken to mitigate the damage suffered by data subjects (lit. c), the degree of cooperation with the supervisory authority to remedy the infringement and mitigate the possible adverse effects of the infringement (lit. f), and to what extent the controller notified the infringement to the controller (lit. h). Article 83 (2) GDPR also provides for a catch-all element when “any other mitigating factor” needs to be taken into consideration, which must—in light of the aforementioned factors—also include the containment and recovery of an incident to identify an attacker, vulnerability or certain modus operandi. It remains to be seen how much weight national DPAs attribute to an effective NIS response—either as a justification or at least as an important factor when deciding upon and setting the amount of a fine.

9

At a first glance, the aforementioned lack of mandatory cooperation may account for an early incident disclosure. Where the DPA treats an incident independently from the NIS NCA, privacy may prevail over an investigation into the roots and causes of an incident from a technical perspective. As DPAs advise on when data subjects should be notified, an entity may feel obliged to disclose an incident instantly, whereas from a cybersecurity perspective delay is required. This theoretical risk is rooted in the different aims of the legal instruments. The GDPR concerns the protection of personal data and publicity of a data breach should put the data subjects concerned in a position to mitigate immediate risks of damage. Guidance on data breach notification by the EDPB European Data Protection Board [42] thus solely focuses on the data protection position and addresses issues in relation to the timing of notification from a mere privacy viewpoint. Other than protecting the rights and freedoms of a natural person, publicity of incidents under the NISD aims at (re-)establishing information security, i.e. confidentiality, integrity and availability of NIS. As a consequence, the individual affected by a mere security incident may only be informed of the incident, where public awareness is necessary in order to prevent an incident, to deal with an ongoing incident, or limited to DSPs, disclosure is in the public interest. [43] Recital 86 GDPR addresses the dilemma of early disclosure by recognising that “the need to mitigate an immediate risk of damage would call for prompt communication with data subjects whereas the need to implement appropriate measures against continuing or similar personal data breaches may justify more time for communication”. The wording of the justification suggests that it should be limited to continuing and ongoing data breaches; it does not encompass ongoing security incidents as such. Hence, it would for instance fall short in an incident which incidentally compromised consumer data, but leads to an ongoing attack targeted at other vital systems of the OES or DSP. [44] However, since the justification is ‘only’ part of the recital, this supports the interpretation of ‘undue delay’ in the operating provision, but does not provide legally binding limits to the scope of Article 34 GDPR. Also, mitigation of an incident and an effective NIS response are factors to be considered when deciding upon the imposition of an administrative fine for infringing Article 34 GDPR.

13

In its Guidelines 01/2021 the EDPB outlines 18 fictional cases that shall support and guide data controllers and processors to better understand reporting obligations under the GDPR. Two of these exemplary cases will be analysed that demonstrate risks of being in conflict with general controlled vulnerability disclosure guidelines. Due to the sample cases being of a very general nature, further details have been added by the authors to highlight potential conflicts.

14

Since the issue of hampering investigations by early disclosure in particular arises in ransomware and data exfiltration attacks, the subsequent analysis focuses on these attacks. Attacks of this kind are largely based on software vulnerabilities as opposed to human error, natural disaster or traditional crime.

15

Ransomware Attacks. Ransomware is a type of malware attack which attacks the availability of data of the victim in order to extort money from the victim.

16

EDPB Case no. 03: “The information system of a hospital/healthcare centre was exposed to a ransomware attack and a significant proportion of its data was encrypted by the attacker. The company is using the expertise of an external cybersecurity company to monitor their network. Logs tracing all data flows leaving the company (including outbound email) are available. After analysing the logs and the data the other detection systems have collected the internal investigation aided by the cybersecurity company determined that the perpetrator only encrypted the data without exfiltrating it. The logs show no outward data flow in the timeframe of the attack. The personal data affected by the breach relates to the employees and patients, which represented thousands of individuals. Backups were available in an electronic form. Most of the data was restored but this operation lasted 2 working days and led to major delays in treating the patients with surgery cancelled / postponed, and to a lowering the level of service due to the unavailability of the systems.” The EDPB concludes that this sort of attack might lead to reporting obligations to the general public if a sever interruption of the service for many customers is observed and the involved data amounts to special categories of data. [48]

17

The case seems to be inspired by a Ransomware attack which largely effected the NHS [49] in 2017. [50] It needs to be pointed out that the malware WannaCry [51] was epidemic. Hence, it was most likely not targeted at the NHS as such. Its large spread was possible since it was based on the so called EternalBlue exploit which made use of the vulnerability CVE-2017-014. [52] This exploit targeted a certain implementation of Microsoft’s smb protocol. [53] Although a related vulnerability a patch was available, many systems remained unpatched. [54]

18

Beside the direct effect of the attack, the large spread of the malware also demonstrated the vast number of unpatched systems and in particular the vast number of systems which are likely hard to patch due to legacy system support. In such a case, one might advise against informing the general public immediately to avoid copycat attacks. [55] In simple terms, publicity should be avoided until a patch for the software vulnerability is released in order to prevent further personal data to be interfered with.

19

In contrast to this, is EDPB Case no. 04: “The server of a public transportation company was exposed to a ransomware attack and its data was encrypted. According to the findings of the internal investigation the perpetrator not only encrypted the data, but also exfiltrated it. The type of breached data was the personal data of clients and employees, and of the several thousand people using the services of the company (e.g., buying tickets online). Beyond basic identity data, identity card numbers and financial data such as credit card details are involved in the breach. A backup database existed, but it was also encrypted by the attacker.”

20

Assuming, contra to Case no. 3, that no public knowledge of the mechanics of the attack can be derived nor was the underlying malware as widespread or at least would not expose vulnerabilities in widespread systems, informing the general public is unlikely to trigger more attacks. However, the leaked information poses high risks for the affected individuals, so it is advisable to inform victims and the public as soon as possible.

21

Extending the EDPB’s fictional cases magnifies the root cause of the conflict among GDPR and NISD with regard to incident reporting, namely, the different protection goals. On one hand, the NISD aims at the protection of the underlying (vital) infrastructure. That is, its focus is on availability, though confidentiality and integrity might be needed to ensure the former. Further, the NISD operates under the assumption that OESs and DSPs use similar systems for their operation. That means in turn, knowledge of an incident might help to uncover ongoing incidents with other providers. Lastly, the analysis of incidents might unveil vulnerabilities that are shared with other providers. In short, incident reporting aims at the discovery of large-scale attacks and identification of underlying vulnerabilities in order to allow coordinated incidence response (short term) and an improved level of cyber security/preparedness (long term). On the other hand, the GDPR aims at the protection of users’ rights with focus on confidentiality (of the users’ data). Here, incident reporting to the DPAs has the same aims as reporting under the NISD. However, regarding the duty to inform affected users, it goes further: it shall allow users to take personal mitigation actions, e.g., changing passwords, blocking payment cards etc. and thereby, prevent the harm from materialising.

23

Remedying the causes of NIS vulnerabilities is identified as an important factor in reducing cybersecurity risks. The proposal recognises that the reporting entities are often third parties relying on a particular ICT product or service, and thus, the manufacturer or provider of ICT products or services should also receive vulnerability information. In that regard, the NIS 2.0 proposal introduces a framework for coordinated vulnerability disclosure [57] and requires Member States to designate CSIRTs to act as trusted intermediaries and facilitate the interaction between the reporting entities and the manufacturers or providers of ICT products and services. [58] Coordinated vulnerability disclosure, as described in the proposal, specifies a structured process through which vulnerabilities are reported in a manner allowing the diagnosis and remedy of the vulnerability before vulnerable information is disclosed to third parties or to the general public. Where entities become aware of an incident, they are required to submit an initial notification without undue delay and not later than 24 hours, followed by a final report not later than one month after. [59] While the initial notification is limited to the information strictly necessary to make the competent authorities aware of the incident and allow the reporting entity to seek assistance, the final report must contain a (i) detailed description of the incident, its severity and impact; (ii) the type of threat or root cause that likely triggered the incident; (iii) applied and ongoing mitigation measures. This two-stage approach is similar to the reporting in stages under the GDPR, where information may be provided in phases if full notification of the DPA cannot be achieved within 72 hrs.

24

The aim of the two-stage approach becomes clear in the recitals: the reporting entity’s resources should not be diverted from activities related to incident handling, which should be prioritised. [60] Coordinated vulnerability disclosure also takes into account coordination between the reporting entity and the manufacturers or providers of ICT products and services as regards the timing of remediation and publication of vulnerabilities. [61] The role of the CSIRT as the coordinator in that process should include the identification and contact of further entities concerned, support of reporting entities including negotiations with regard to disclosure timelines, and the management of vulnerabilities that affect multiple organisations (so called multi-party vulnerability disclosure). [62] ENISA is required to develop and maintain a European vulnerability registry for the discovered vulnerabilities. [63] Although cooperation under the NIS 2.0 proposal is still attached to cross-border incidents, there is a clear request to strengthen information sharing of national authorities, [64] e.g. by establishing cooperation rules between the NIS NCAs and DPAs to deal with infringements related to personal data. [65] However, cooperation of NIS NCAs and DPAs as required in Article 32 NIS 2.0 Proposal focuses on NCAs notifying DPAs when they have an indication of a personal data breach infringement by important or essential services (prieviously known as OES and DSP) of the security and notification obligations enshrined in Articles 18 and 20. Since NCAs are obliged to notify indications of a personal data breach to the DPA ‘within a reasonable period of time’, [66] yet another timeframe is introduced, adding to the complexity of determining ‘undue delay’ under GDPR and suggesting that the NCA may withhold information where the data controller would be obliged to notify the DPA ‘without undue delay’.  [67]

25

While at first glance, the introduction of a coordinated vulnerability disclosure suggests a strengthening of control in the sense of responsible disclosure—i.e. it respects the interest of an entity to delay information of the public—this may not be the case. It is merely that the Proposal lays down a two-stage approach to incident reporting to strike a balance between, on the one hand, swift reporting to NCAs that helps mitigating the potential spread of incidents and allows entities to seek support, and, on the other hand, detailed reporting that draws valuable lessons from individual incidents and improves over time the resilience to cyber threats of individual companies and entire sectors. [68]

26

The clear commitment to put the incident response ahead of detailed reporting, does not eliminate the conflict with swift reporting to data subjects under GDPR since this remains predominantly an issue of GDPR compliance and does not concern obligations under the NISD. The delay granted for detailed reporting may tempt entities even more to depart from the ‘without undue delay’ reporting to individuals under the GDPR. The reporting in phases of a NIS incident to NIS NCAs may become the default reporting mechanism in light of prioritizing the incident response. As publicity may hamper an incident response, data controllers may give priority to the technical incident response over informing data subjects. Even when Article 20(1) and (2) NIS 2.0 Proposal introduce a GDPR-like obligation to inform service recipients of incidents that are inter alia likely to adversely affect the provision of that service ‘without undue delay’, the ratio of the NISD remains an effective incident response. Accordingly, this third-party notification is only required ‘where appropriate’, suggesting that this is only necessary where measures are available to the service recipients to mitigate the resulting risk themselves,  [69] and where incident publicity does not interfere with effective incident response in a whole.

27

During the consultation process various stakeholders [70] addressed a necessity to align reporting authorities, thresholds, timeframes and penalties in EU legislation to eliminate “persisting redundancies in terms of incident reporting and double notification requirements under different legal regimes”. [71] The proposal suggests that for the purposes of simplifying the reporting of security incidents, Member States should establish a single entry point for all notifications required under NISD and also under other Union law such as the GDPR. [72] Whether a single entry point may alleviate issues in relation to early disclosure to the public in form of individual data subjects remains to be seen as a single entry point does not mean that notified authorities will treat a reported incident in the same way. A single entry point for reporting to regulators is also not related to obligations to inform the public. However, there was also no necessity from the legislator to address this issue in the NIS 2.0 proposal since the risk of early disclosure is merely an issue of GDPR compliance. As long as the GDPR does not address the containment and recovery of an incident along with further interests such as law enforcement as a justification to delay notification of data subjects, the conflict persists. The sole conflict that the NIS 2.0 Proposal eliminates are the legal consequences for non-compliance under the GDPR and NIS instrument: Article 32(2) NIS 2.0 Proposal clarifies that where a DPA imposes an administrative fine, a NCA shall not impose an administrative fine for the same infringement. Again, failure to comply with notification obligations towards the regulatory authority, and failure to comply with the notification obligation towards the data subject/service recipient are different infringements. An entity that informs the DPA and NCA of a security incident involving personal data but does not inform the data subject without undue delay to deal with an incident is potentially subject to legal sanction under the GDPR.

28

In sum, the coordinated vulnerability disclosure and strengthening of cooperation do not provide a solid framework for responsible disclosure since every data controller has the sword of Damocles hanging over their head in the form of mandatory disclosure of data breaches to data subjects without undue delay.