What is NIS2 and why is it important?

NIS2, or more formally the Directive [...] on measures for a high common level of cybersecurity across the Union [...], is a recent high level directive on information, or cyber-, security in the European Union. At its core it is a directive, which means that it is implemented in member states rather than the EU level (as regulation such as GDPR is). This directive concerns measures, that is processes and things which should be done, for cybersecurity, that is the set of activities necessary to protect network and information systems and their users. 

NIS2 is also an updated version of the current NIS(1) directive, with similar goals and provisions in mind. In practical terms, the biggest difference between NIS1 and NIS2 is the selection of actors covered by the provisions, not the measures themselves. 

While NIS1 had a clear focus on actors of an infrastructure-like character such as energy, health, transport and financial services; NIS2 has a much broader target and includes all NIS1 actors and adds postal services, space, research, manufacturing, food, waste management and so forth. You should consult your national NIS2 implementation to find out if your organisation falls under the NIS2 measures and possibly where you are established and therefore under governmental oversight. As a rule of thumb, NIS2 considers your place of establishment in the following order: 1) the location where you make information security related decisions, 2) the location where you have your information security related operations, 3) the location with the most employees in the Union [1]. In the context of classification, infrastructure-like entities are essential entities, and other entities are important entities, with different fines and governmental oversight for each. We will look at this in more detail in a later section. 

The general timeline for NIS2 was set in late 2022, when the directive passed the European Parliament. Technically, member state implementation should be entered into national legislation by October of 2024, but it is quite likely that most member states will be a bit delayed. For example, the Swedish NIS2 legislation is undergoing public consultation until 28 May 2024 and is expected to enter force by 1 January 2025.

The current cyber- and security context

In the larger EU context there are other frameworks which concern (cyber-) security as well, most notably the Cyber Resilience Act (CRA) and the Product Liability Directive (PLD). Where CRA roughly concerns a digital version of CE-marking, that is the product affirmation stamp for product compliance; the PLD concerns strict liability for all products, probably including digital and software products in this draft. It should be noted that the PLD currently only exists in draft form and one should be very cautious to draw far reaching conclusions based on the draft. 

As far as measures in NIS2 are concerned, they seem to be picked from frameworks such as the ISO 27001 standard and System and Organization Controls (SOC) 2 audits, with a clear focus on systematic information security processes, proportional risk management, and incident management and reporting. Actors already covered by NIS1 or similar regulatory frameworks, such as national implementations of the European Electronic Code of Communications, are likely to be almost NIS2-compliant already. As noted earlier, the increased scope of covered actors of NIS2 compared to NIS1 is one of the major differences. Another major difference is the guidelines of NIS2, intended for increased harmonisation of the directive across the union. This was since the implementation of NIS1 differed quite substantially between member states, in particular concerning health care institutions (hospitals, local health centres, etc).

These measures are high level, that is they concern the information security management system (often abbreviated as ISMS) rather than the operational cybersecurity capabilities of covered actors. Fines are likely to be issued for not reporting incidents, or for not being systematic or proportional enough in selection of risk management measures, rather than actual incidents. For essential entities the maximum fine is 10 000 000 EUR, or 2% of global turnover, whichever is higher, so the fines are potentially quite substantial. The figures are 7 000 000 EUR and 1.4% for important entities. 

In regards to government supervision, the competent authority can conduct event based (i.e., ex post) supervision for both essential and important entities, but can only conduct planned supervision prior to any indication (i.e., ex ante) for essential entities.

Netnod, NIS1 and NIS2

Netnod has been covered by NIS1 since it first came into force in August  2018 with regard to some of our DNS-services. NIS2 is broader and will also include several of our IX- and transport related services. Netnod will be NIS2 compliant from the start.

We were active lobbyists at EU level for the non-inclusion of DNS root name servers in NIS2, where we were successful. The issue with the original inclusion of root name servers in the directive was that the EU would have direct extra-territorial regulatory oversight of services currently provided at no cost at a global scale for the good of all Internet users.

We also suggested that the current approach might not be optimal for finding the important services and components everyone depends on. We argued that it is very likely that there exist components of services which are more important than the services covered by NIS2 themselves. This is neatly illustrated by the figure below:

Figure 1: xkcd.com figure illustrating critical component dependencies. Illustrative of how large sets of infrastructure or services might depend on the same critical component. Image source: https://xkcd.com/2347/ 
Reproduced under Creative Commons Attribution-NonCommercial 2.5 License.

In other words, components are likely to exist which are more important than any individual essential service on its own. Take for example the recent xz-backdoor [2] where a sophisticated, possibly state sanctioned, backdoor was added to a widely used library on common Linux distributions. This backdoor could single-handedly have been used to bring down large server infrastructures if allowed to propagate fully. Imagine if more widespread libraries were successfully backdoored in a similar fashion?

Processes, operational security and the applicability paradox 

As noted above, NIS2 targets provisions for processes concerning security, rather than operational security itself. This has the interesting side effect that it is possible to be NIS2 compliant without having a high level of operational cybersecurity. And vice versa, it is possible to not be NIS2 compliant while having a high operational level of cybersecurity. 

Now, this does not have to be a problem, but it is problematic that NIS2 is toted in broad terms as concerning cybersecurity and especially improving the level of cybersecurity, without recognizing that operational cybersecurity is (mostly) out of scope of NIS2.

What is the context in which to view NIS2 then? Like almost all legislation, NIS2 assumes there exists an intrinsic need for order. More specifically, NIS2 is based on the assumption that a system cannot be secure without someone stating that the system is secure. In reality, both high-level order and operational effectiveness are necessary. While the NIS2 directive is not per se wrong, it’s worth noting that it is not focused enough on operational effects to properly handle and incentivize a high level of operational cybersecurity. 

My view is that some form of ex-post liability for incidents and damages is necessary to properly incentivize a high level of operational cybersecurity. If organisations were liable for the damage caused by poor operational cybersecurity, it would seem that operational cybersecurity would improve. Currently, a resource strapped organisation is likely to focus on the short term aspects of NIS2, such as reallocating resources to the ex-ante provisions regarding information security management, rather than focus on operational capabilities. 

NIS2 - what should you do now?

My current, and it is current as the landscape is changing rapidly, best advice is to take a step back and reflect. Most member state implementations are still in the draft stage. If you have the competence in-house make sure to comment on the draft if possible. When the time comes to ensure compliance with NIS2, remember that cybersecurity is part of virtually everything today. You cannot handle cybersecurity as a separate vertical in your organisation. 

In addition, find out how you should report incidents. That is, make sure you understand the practical process of sending in an incident report. Do you need a special PGP-key? Do you need to prepare a certain kind of document? Do you have the instructions for sending in an incident report available off-line? Can you report via landline? Do you know what web page or email address to use for reporting?

And lastly, do not forget to allocate resources for operational cybersecurity as well. A well designed NIS2 implementation is likely to produce actions for improvements, and you should not only design these actions, you must also implement and conduct them.

In terms of operational improvements, I suggest looking at your real dependencies. What are you dependent on for maintaining your level of service or function? Which dependencies can be replaced in an emergency situation, and which can’t?

Get in touch with the relevant competent agency in your member state for more information regarding NIS2, as the implementations vary by member state. And if you are not established in the EU but offer services there, make sure to determine which national NIS2 implementation covers your services and follow the relevant processes and procedures.

Endnotes

1.  See provision 114 of the directive for further information.

2.  See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 

You can watch Fredrik’s NIS2 presentation from the recent Netnod Meeting here.