Keywords

1 Introduction

The NIS Directive (NISD)Footnote 1 has been the first horizontal legislative measure at EU level to increase the level of the security of network and information systems (NIS). A central element of the NISD to improve cyberresilience is the introduction of security measures and incident reporting obligations for key operators of essential services (OESs) and certain digital service providers (DSPs). The NISD had to be transposed into national law by 9 May 2018, meaning that today all Member States have implemented respective legislation. However, the improvements of cybersecurity capabilities at national level and cyberresilience of entities within the sectors encompassed by the NISD seem to be no longer sufficient. The number, magnitude, sophistication, frequency and impact of cybersecurity incidents are increasing and present a major threat to the functioning of NIS, [4, 6]. In response to the increased digitization of the internal market and evolving threat landscape, which both have amplified during the COVID-19 crisis, the European Commission published a proposal for a NISD 2.0 [8] as early as 16 December 2020. While the fast handling of the legislative process has in general received positive acclaim, concerns have been raised inter alia regarding the extension of existing obligations to report security incidents. In response to a fragmented reporting landscape across Member States, the proposal seeks to eliminate divergences in incident reporting thresholds by more precise provisions, including a tiered plan, on the incident reporting process.

2 Reporting Obligations from NIS Directive to NIS 2.0 Proposal

In order to increase the cyberresilience of operators of essential services (OESs)Footnote 2 and digital service providers (DSPs),Footnote 3 the NISD introduced the obligation to report security breaches, which is along with incident reporting in other sectors deemed a ‘hallmark of EU cybersecurity legislation’ [7]. The following sections outline the status quo and the envisaged expansion of the existing reporting obligations for IT security incidents affecting NIS.

2.1 Reporting Framework Under the NIS Directive

Reporting under the NISD is limited to ‘incidents having a significant impact on the continuity of essential services’ (for OESs, Art. 14(3) NISD) and ‘incidents that have a substantial impact on the provision of a service’ (for DSPs, Art. 16(3) NISD). An incident in turn is defined as ‘any event having an actual adverse effect on the security of’ NIS (Art. 4(1) NISD).

Already the concept of ‘adverse effect’ is not further outlined in the Directive, however, since the adverse effect must be on the security, this does not imply that there must be a service disruption or an interference with the performance of the service provided. As regards the significance (for OESs) of the incident, Art. 14(4) NISD enlists specific parameters that have to be taken into account when determining the significance,Footnote 4 while similar criteria for determining whether an incident has a substantial impact for DSPs can be found in a binding and directly applicable Commission Implementing Regulation.Footnote 5 Where national legislation does not provide further guidance, OESs and DSPs are put in a position where they have to translate damages to their services to actual users affected [14]. Incidents must be reported to the relevant competent NIS authority without undue delay. The notion of ‘undue delay’ is not further specified and national implementations range from ‘immediately’ to ‘24 h’ or replicate the undue delay standard which may even be interpreted much longer since there is also no guidance whether the entity must be fully aware of the dimension of the incident.

With the NISD only setting a minimum standard, Member States introduced not only varying reporting timeframes, but also varying reporting thresholds, resulting in significant discrepancies regarding the reports received under the mandatory reporting scheme [10]. The first Annual NISD incident report published by the NIS Cooperation Group (2019) aggregated a total of 432 NISD-relevant cybersecurity incidents from competent authorities across the EU Member States, whereas Germany alone lists 419 NISD incidents in 2020 and the French NIS authority received 2,287 reports [1, 3]. Both, France and Germany, require the reporting of incidents that only may have a substantial impact and where harm has not necessarily materialized, which may explain why the number of reports received is rather high in contrast to the accumulated data presented by the NIS Cooperation Group. However, most incident statistics that are accessible do not differentiate between mandatory and voluntary reporting.

2.2 Reporting Framework Under the NISD 2.0 Proposal

The European Commission’s Proposal for a NISD 2.0 seeks to respond to the criticism of fragmentation by not only specifying the notion of incident, but also introducing a new understanding of ‘significance’.

Art. 4(5) NISD 2.0 Proposal defines an incident as ‘any event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the related services offered by, or accessible via, network and information systems’. A reportable incident must pass the threshold of significance irrespective of whether the entity concerned is an important or essential entity.Footnote 6 The notion of ‘significant’ incidents shall encompass also incidents that only have ‘the potential to cause substantial operational disruption or financial losses for the entity concerned’, or have ‘the potential to affect other natural or legal persons by causing considerable material or non-material losses’ (Art. 20(3) NISD 2.0 Proposal). This means that first of all, an incident must be established. Secondly, it is not necessary that damage or harm has materialized, but the incident must have the potential to cause substantial harm or considerable loss. In addition, Art. 20(2) NISD 2.0 Proposal foresees the mandatory reporting of ‘significant cyberthreats’ to allow national authorities, and subsequently other Member States, to acquire a full picture of the threat landscape. According to the European Commission’ NISD 2.0 Proposal, a ‘cyberthreat’ shall include ‘any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact NIS, the users of such systems and other persons’.Footnote 7 Since this would encompass all kinds of scenarios including phishing mails and simple scam mails, the Commission limits reporting to ‘significant cyber threat[s] that those entities identify that could potentially resulted in a significant incident’ (Art. 20(2) NISD 2.0 Proposal). The aim of including cyberthreats in the mandatory reporting scheme is outlined in the recitals of the Proposal: since cyberthreats are becoming more complex and sophisticated, good detection and prevention measures depend to a large extent on regular threat and vulnerability intelligence sharing between entities.Footnote 8 Ultimately, awareness ‘enhances the entities’ capacity to prevent threats from materialising into real incidents and enables the entities to better contain the effects of incidents and recover more efficiently’.Footnote 9

Insufficient reporting, and thus limited sharing of information, is interlinked with little guidance in the NISD on reporting formats and timelines since the Directive only required reporting ‘without undue delay’ and most Member States introduced equally vague requirements. Under the Commission’s NISD 2.0 Proposal, a tiered plan foresees an initial notification within 24 h, an intermediate report upon request and a final report within one month following the initial notification.

In consideration of sector-specific EU legislation as well as the GDPRFootnote 10 also requiring the reporting of incidents, or personal data breaches, respectively, the Commission Proposal encourages Member States to establish a single entry point for all notifications required under these acts.Footnote 11

2.3 The European Parliament’s Position on the Reporting Framework Envisaged Under the NISD 2.0 Proposal

The European Parliament [12] opposes the proposed extension of reportable events and seeks to align incident reporting obligations with those under GDPR (and in fact industry policy documents such as [13] in terms of timeframes. An exclusive focus on actual security incidents and specific threats should relieve entities and authorities alike to allow them to limit security resources to incident responses. Accordingly, the European Parliament proposes to limit mandatory incident reporting to significant incidents that have caused actual harm.

The European Parliament’s Rapporteur not only considers an extended obligation unrealistic, but also questions any of the envisaged positive effects [11]. Instead the Parliament favours a voluntary reporting of ‘near misses’, i.e. events which could have compromised the availability, authenticity, integrity or confidentiality of data, or could have caused harm, but were successfully prevented from producing their negative impact,Footnote 12 as well as cyberthreats for entities falling inside and outside the scope of the Directive. As regards the time window for the initial incident notification, the Parliament seeks an extension from the proposed 24 h to 72 h with regard to those incidents that have a significant impact on the entity other than on the availability of the service provided by the entity. The Parliament further suggests extending the deadline for the final comprehensive incident report for scenarios where the incident is still ongoing after  one month; in that case, a full report shall be submitted one month after the incident has been resolved.

Interestingly, the Parliament also addresses the need for standardized notifications in a proposed amendment to recital 23. Along the recognition of the necessity to align the format of notifications, the Parliament proposes in a new Art. 20(1a) the simplification of reporting obligations by a single entry point for all notifications required under the NISD and also under other Union law such as the GDPR and ePrivacy Directive.Footnote 13

2.4 The European Council’s Compromise on the Reporting Framework Envisaged Under the NISD 2.0 Proposal

The Council Approach [5] does not strictly follow the European Parliament’s Draft in terms of restricting reporting obligations: while the idea of mandatory reporting of significant cyberthreats is abandoned, the Council Approach retains the obligation to report incidents that have the potential to cause ‘severe’ operational service disruption, or financial losses, or have the potential to affect other natural or legal persons by causing considerable material or non-material losses. Seeking a compromise, the Council Approach replicates the Parliament’s position on voluntary reporting of near misses and cyberthreats for all actors employing NIS.

2.5 How the NISD 2.0 Proposal Responds to the Flaws of the NISD

Although neither the Commission nor Parliament or Council present robust evidence on an under-reporting under the current mandatory reporting scheme, Commission and Council are pushing for an extension of reporting obligations. Considering the definition of ‘incident’ in the NISD 2.0 Proposal as encompassing ‘any event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the related services offered by, or accessible via, NIS’, the extension of reporting obligations to incidents where no harm has materialized is unlikely to challenge the reporting system: Still, only the most severe incidents must be reported. These are incidents where most likely the entity will anyway issue an early warning to a CSIRT or an Information Sharing and Analysis Center (ISAC). The definition of incident clearly requires as a first step that some interreference with the entity’s NIS has to be established. This has to be distinguished from a reportable cyberthreat that is defined in the Commission’s NIS 2.0 Proposal as ‘any significant cyber threat that those entities identify that could have potentially resulted in a significant incident’ with a cyberthreat defined as ‘any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons’.Footnote 14 Obviously, the NISD 2.0 Proposal makes reporting easier and seeks to prevent that resources have to be shifted away from incident handling to reporting when only an initial notification with basic information about the presumed cause is required. In that regard, however, much depends on the national implementations of this requirement which must not reach beyond the aim of making the regulatory authority ‘aware’ that an incident is taking or took place. Under this presumption, the extension of reporting obligations to incidents that have the potential to cause harm makes sense: at the time of the initial warning, the scope of the incident and whether the harm materializes above the threshold of ‘significance’ will in most cases not be clear. Thus, the timeframe of 24 h for reporting seems to be not overly burdensome.

Whether ‘cyberthreats’ should be included in the mandatory reporting is questionable since the definition of cyberthreat is rather broad, which in turn leads to legal uncertainty. Legal uncertainty not only is a challenge in terms of compliance but also leaves discretion to the Member States as regards the interpretation of the notion. Thus, diverging interpretations across the EU are likely, leading again to the fragmentation, which the NISD 2.0 Proposal seeks to avoid. In terms of reporting of cyberthreats, voluntary reporting—as foreseen in the Parliament Draft and the Council Compromise—is therefore favourable. In that regard, one has to bear in mind that good detection and prevention measures depend to a large extent on regular threat and vulnerability intelligence sharing. From a technical point of view, the non-materialization of harm is likely to be the result of appropriate security mechanisms and reporting complements the evaluation of the overall threat landscape which in turn helps to prevent, detect and defend attacks on third parties.

Besides the scope of reporting, the NISD 2.0 Proposal also addresses the format and procedure. With the time window specified, the idea to eliminate the often redundant reporting of a single incident to different public authorities or institutions while having to comply with distinct processes, a single entry point for all notifications of cybersecurity incidents and data breaches will certainly ease compliance for the entities concerned. A similar solution is envisaged for the reporting of major ICT-related incident reporting by financial entities under Art. 19 DORA Proposal [9]. Often entities see themselves confronted to report to more than one regulatory authority/institution under different reporting schemes [16]. There may be sectoral reporting schemes that are not considered lex specialis to the NISD, or mandatory reporting under an instrument with a different protection goal, such as the GDPR, that protects personal data. Although the different reporting schemes still require different time frames for reporting, the single entry point will alleviate the burden to identify the correct recipient for a notification. A single entry hub would necessarily require the alignment of the content of a report since otherwise entities will again be confronted with the question what to report under which scheme. Nobody wants to report too much, but too little may be punishable [2]. Ultimately, the standardized format suggested by the European Parliament would also help information sharing where no single entry point is established. Although this is only part of the recitals and not of the operative provisions, and thus not considered to have independent legal value, the mention of ‘standardized’ formats supports an alignment of reporting formats along with reporting procedures. The heterogeneity of reporting formats certainly is a challenge for information sharing within a Member State and across borders. In addition to the standardized format, the legislator should envisage an improvement of reporting formats by requiring a machine- and human-readable format which would also facilitate an automated workflow. The latter is of particular importance because the NISD 2.0 Proposal will definitely result in an increase of reporting. Whether this will be based on the extension of reporting obligations as feared by the Parliament [11] remains to be seen. Without doubt the enlarged scope of the NISD 2.0, which not only will apply to more sectors, but - by the introduction of a size-cap rule - also to more entities in existing sectors, will significantly lead to an overall increase in reporting. Further, raised awareness of the obligations under the NISD and the reformed sanctioning regime with fines up to EUR 2 M are likely to incentivize reporting.

3 Conclusion

Clearly the NISD 2.0 Proposal responds to the deficits stemming from the various, diverging implementations of the NISD and unclear requirements for incident reports. Within the ongoing trilogue negotiations the co-legislators need to focus on the original ratio of the Directive, namely, making Europe fit for the digital age where the cybersecurity threat landscape constantly evolves. This also requires a full picture of the threat landscape and trends, rendering an extension of reporting obligations necessary and at the same time calling for a clearly defined and efficient reporting process. The latter is important to facilitate compliance, since in light of the severe sanctioning regime entities need to know what to report, when and to whom.