The EU’s Draft NIS2 Regulations: Appropriate ICT Security Measures and Serious Incident Reporting

The European Commission has published a draft regulation containing further detail on the “technical and methodological” security measures, and cybersecurity incident reporting threshold triggers, under the incoming NIS2 directive (the “NIS2 Regulation”). Once finalised, the regulation will apply from 18 October 2024 in line with member states’ deadline for NIS2 implementation.

NIS2: a recap

The second Network and Information Systems Directive (“NIS2”) is a new EU cybersecurity law that significantly builds upon, and expands the scope of, the previous NIS1 directive. In particular, it requires EU member states to impose heightened cybersecurity obligations – including security measures on covered entities and their supply chains, and new incident reporting requirements – on a wide range of essential and important infrastructure sectors. See our previous NIS2 blog post here.

NIS2 came into force on 16 January 2023, and each EU Member State has until 18 October 2024 to transpose the legislation into their local law, and start enforcing its requirements.

NIS2 vs DORA

The EU’s Digital Operational Resilience Act (“DORA”), which comes into force on 17 January 2025, imposes far-reaching operational resilience requirements and management oversight requirements on financial services firms – including banks, insurers and private equity firms – and their critical service providers. There is, therefore, a certain amount of thematic and scope overlap between DORA and NIS2 (for example, certain cloud computing and trust service providers may fall within the scope of both laws) albeit NIS2 comes into effect before DORA.

Once both laws are in force, DORA will take priority over any overlapping NIS2-related requirements. Consequently, it will be important for entities that are subject to both regimes to understand the areas of overlap (where DORA will take priority) and any areas that are covered only by NIS2 (which covered entities must still comply with).

Who does the NIS2 Regulation apply to?

The proposed NIS2 Regulation applies to only a sub-group of NIS2-covered entities. Specifically:

• cloud computing service providers;
• managed service providers;
• providers of online search engines and social networking services platforms;
• providers of online market places;
• DNS service providers;
• TLD name registries; and
• trust service providers (collectively, the “Covered Entities”).

Technical and methodological security measures

NIS2 implementing legislation will require Covered Entities to “take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems […] and to prevent or minimise the impact of incidents on recipients of their services and on other services.” (Art.21(1) of NIS2)

The NIS2 Regulation Annex providers further colour on what such technical and methodological requirements could be, based on existing European and international standards. Annex I contains detailed, highly prescriptive requirements on the scope and content of the following measures:

• network and information systems security policies, including the roles and responsibilities of IT staff and the management they report to.
• cybersecurity risk management frameworks, including sections on monitoring for compliance with company policies and procedures, and independent reviews of their security posture.
• incident handling policies, including documenting activity monitoring and logging procedures, incident reporting procedures, incident assessment and classification processes, incident response procedures, and post-incident reviews.
• business continuity and disaster recovery plans, including implementing effective backup processes and crisis management plans.
• supply chain security policies, including processes to review suppliers prior to their engagement, and contractual clauses that should be included in the supply agreements, as well as maintaining directories of all direct suppliers and service providers.
• ICT procurement, development and maintenance policies, including processes and procedures to manage the risks stemming from the acquisition and/or development of ICT services and products throughout their lifecycle, configuration management procedures, procedures to manage changes, repairs and maintenance to ICT systems, and policies and procedures relating to security testing, patch management, network security, network segmentation, protection against malicious and unauthorised software, and vulnerability handling and disclosure.
• policies and procedures to assess the effectiveness of cybersecurity risk-management measures. These should determine, for example: what cybersecurity risk-management measures are to be monitored; the methods by which they will be monitored, measured, analysed and evaluated to ensure valid results; who will perform the monitoring and when it will take place; and who is responsible for analysing the results.
• cybersecurity training, and processes to raise awareness of basic cyber hygiene practices.
• cryptography policies and procedures. For example, these should establish: the type, strength and quality of cryptographic measures required; the protocols to be adopted; the cryptographic algorithms, cipher strength, cryptographic solutions and usage practices to be implemented; and the approach to key management.
• workforce security policies and procedures, including processes to conduct background checks on staff and suppliers, check that the workforce is appropriately qualified for their roles (for qualified personnel), ensure that the workforce is aware of their roles and security obligations, and implement appropriate disciplinary processes for violation of the requirements.
• access control policies, including managing staff access rights.
• policies and procedures on the environmental and physical security of IT infrastructure and its supporting utilities, including perimeter and physical access controls.

Notwithstanding the granular measures outlined, the NIS2 Regulation emphasises the importance of proportionality, noting that Covered Entities should implement measures that are appropriate in light of their own level of risk exposure, taking into account the criticality of their services, their size and structure, the likelihood of them experiencing cyber incidents and the severity of those incidents, and the entity’s wider societal and economic impact. Where it would be disproportionate to adopt all of the listed measures, Covered Entities should adopt alternative compensating measures, such as targeted management oversight of cybersecurity matters, or increased monitoring and logging.

Member State regulators may issue further guidance on these topics, and a multi-stakeholder forum will be established to identify the best security standards and deployment techniques to help Covered Entities meet their obligations.

Incident reporting triggers

NIS2 implementing legislation will impose an obligation on Covered Entities to notify relevant authorities of any incident that has a significant impact on the provision of their services, i.e., where it has caused (or is capable of causing): (i) severe operational disruption or financial loss to the entity; or (ii) considerable material or non-material damage to affected persons. (Art.23(3) of NIS2)

The NIS2 Regulation provides guidance on what constitutes “significant impact”. An incident meets the threshold where it has met, or is capable of meeting, one or more of the following criteria:

• there has been a successful, suspectedly malicious, and unauthorised access to network and information systems.
• the incident caused financial loss that exceeds €100,000 or 5% of the Covered Entity’s annual turnover (whichever is lower).
• the incident caused considerable reputational damage – consideration should be given to whether the incident: (i) has been reported in the media; (ii) has resulted in complaints from users or critical business relationships; (iii) means that the entity (likely) will not be able to meet regulatory requirements as a result of the incident; or (iv) will lose customers as a result of the incident, with a material impact on its business.
• the incident resulted in the exfiltration of trade secrets (as set out in the EU Trade Secrets Directive).
• the incident caused death or considerable damage to health.
• the incident is a reoccurring incidente., there are at least two incidents within a six-month period that have the same apparent root cause.
• the incident meets any of the additional criteria set out in Articles 5 to 14 that apply to specific types of Covered Entities.

The NIS2 Regulation also contains guidance on calculating the number of users affected by an incident, assessing whether network and information systems have been compromised, determining the duration of the incident and unavailability of a service, and assessing whether the incident has caused a large delay in response time (factors that are relevant for some of the additional criteria for specific types of Covered Entities). Further, it confirms that the planned consequences of maintenance operations are not considered significant incidents under NIS2.

Steps to take now

Four steps Covered Entities may want to consider taking now to prepare for the NIS2 Regulation’s implementation are:

1. Compare the NIS2 Regulation’s content against your current ICT policies and procedures. NIS2 contains highly preceptive, detailed ICT-related requirements. Given the enforcement date is only a few months away, many businesses will likely be in the middle of executing workplans to ensure their policies and procedures comply with these new prescriptive requirements. Covered Entities should review the draft NIS2 Regulations, with a view to making any necessary adjustments to their policies and procedures, including their incident response plans.
2. For Covered Entities subject to NIS2 and DORA, compare your obligations under the two regimes. All Covered Entities are required to comply with NIS2’s requirements from 18 October 2024. However, once DORA comes into force on 17 January 2025, any Covered Entities will need to continue complying with any NIS2 requirements that are not also contained in DORA. Covered Entities should, therefore, analyse the two laws to identity any areas of divergence, and update their compliance policies and procedures accordingly.
3. Educate your Incident Response team on these new serious incident notification triggers. Members of a Covered Entity’s incident response team should familiarise themselves with the NIS2 Regulation’s “serious” incident reporting triggers to ensure they are incorporated into internal processes. This is particularly important given the short deadlines for notifying incidents; in particular, an initial report within 24 hours of a Covered Entity becoming aware of a notifiable incident.
4. Monitor for changes to the NIS2 Regulations. The current NIS2 Regulations are in draft form, and are open for public comment. While they are unlikely to materially change at this stage, especially given that the implementation deadline is only a few months away, Covered Entities should nonetheless monitor for any changes to the requirements once they are finalised.

****

To subscribe to the Data Blog, please click here.

The cover art used in this blog post was generated by Microsoft Copilot.