Design for the exception, not the rule: NIS2 Implications for Application Design and Avoiding Penalties in High-Criticality Sectors

As I wrote recently, the NIS2 directive (and later, in two or three years, the DLP directive) will significantly influence the IT market, primarily in the European Union (EU). Organizations outside the EU with "substantial business" (what this means is not clear to me yet) in the region will also be affected. This will impact the application design/landscape of many new and existing enterprise architectures, particularly in terms of incident robustness.

It is advisable to avoid the GDPR mess, when a lot of companies have been, despite warnings, unprepared and paid millions in fines to the regulators. Act strategic and be prepared beforehand.

Why it is important to educate yourself now and to act (if you have not done so)

The most important reason to act now, if you haven’t already, lies in the shift in compliance checks compared to the original NIS directive. Previously, compliance checks were typically conducted only after a significant incident occurred within a company classified as part of the "Sectors of High Criticality" (see Annex I of the NIS Directive). In most cases, organizations were sufficiently robust to withstand common threats and could adopt an approach like:

As long as nothing happens we are safe from regulatory compliance checks.

This has now changed / will further change when NIS2 is implemented in the remaining countries, such as Germany, the Netherlands, and others, by early 2025 (as the deadline passed over a month ago), as it becomes binding national law there as well. Under the new directive, compliance checks will occur proactively, even if no incidents happened.

Compared to the previous directive, this represents a significant shift, as organizations can now be proactively audited and fined if violations are identified. In terms of penalties the European Comission seperates for "Essential" and "Important" entities (See number 15 of the introduction points made in the beginning of NIS2 directive).

Details are laid out in Article 3 "Essential and important entitites": Without repeating the whole article here we can outline some important factors (for a comprehensive overview read the article 3) that determine "Essential" entities:

• These include entities from specific sectors listed in Annex I, which exceed the size threshold for medium-sized enterprises as defined in Recommendation 2003/361/EC
• Certain entities, such as trust service providers, DNS service providers, and top-level domain name registries, are classified as essential regardless of size.
• EU states can also add (not remove!) entities if they are relevant for this respective state. A list of those entitites are given (as of end of 2024) already.

In terms of "important" entities its basically an exclusion:

• Entities from sectors listed in Annex I and Annex II that do not meet the criteria for essential entities (for example size or designation).

Just for sake of reference I will a list couple of examples from Annex I here - Be aware this is for illustration. For the full list check NIS2 directive.

1. Energy sector: Production, Transmission & Distribution (so network/ grid companies) of electricity, Oil & Gas, Hydrogen and so on. Geopolitical impact for the EU is very high here, so watch out if you work there.
2. Transportation: Air carriers - although not all entities are included as there are special regulation for this industry already (see #66 of introduction points & EU 2018/1139 for more information). Many human lifes are affected therefore very critical.
3. Banking & Financial Industry: See Article 4 and EU 757/2013. A big one , but banking has many specialized directives way stricter than NIS2, for example DORA. The financial industry ensures the stability of whole continents and societies.
4. Health: Health care providers as in Article 3 and directive 2011/24/EU are for sure affected. Critical as here its about human life.

Important companies have slightly lighter regulations than essential ones, but still will face fines if they violate NIS2 directives. Potential fines that, again, can also occur from an audit without incident are as follows, could be imposed (see Article 34 of NIS2):

So this sums up why acting now might be important if you are in one of those affected areas. No acting and hoping nothing happens does not work anymore and might cost your organization millions of Euros in penalties and potential reputational damage.

Prepare your lead team, as management could/will be personally held accountable

Now in the past, there have been massive discussions about accountability of the top management. There have been severe outcries when a company did something terrible wrong and the respective managers were "fired" and got a couple of millions of dollars "to go". Now, NIS2 will not prevent this of course but top management does face some personal liability under NIS2. This is written in Rectictal 137, Article 20 -01 and in Article 20 of NIS2. There we can read

"(...) ensure a high level of responsibility for the cybersecurity risk management measures (...) management bodies should approve the cybersecurity ris-management measures and oversee their implementation" Recital 137 NIS2

Article 20 - 1& Article 21 goes a bit further then in explaining this:

"Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article." Article 20 -1 NIS2

All this is a bit cryptic, but what it means in the end (in plain English is): The CIO, as a/the responsible board member, signs off on internal guidelines and oversees their implementation. If something goes wrong, they might be personally ('as a natural person') held accountable. How this plays out in court in the respective countries is still open, but its for sure a big shift compared to past levels of responsibilities.

We are not yet at US standards, where top management of listed corporations is always with one leg in prison, but an increased liability for sure will add the needed attention of top management.

How to make your architecture more robust - concrete guidance

According to Article 21 of the NIS2 directive, you must design your systems with incidents in mind. This means 'design for the incident, not the rule.' This approach goes far beyond the typical areas like networks, physical infrastructure (if you still have any), and other components. It also applies to cloud services, including SaaS platforms like the Power Platform, PaaS solutions like Logic Apps and Functions, and IaaS—if you're still running VMs in the cloud. In all these cases, you need to design for the incident, not just for "normal operations"

But how do we actually do that you might ask? Of course there is no ultimate truth to this question but you can start with a couple of practical steps:

1. Risk Assessment and Threat modeling: Check your Azure, or other cloud infrastructure (do not forget connected on-premises components!) and check for continuity. Unterstand failover, recovery periods and compliance risks. SaaS solutions have planned downtimes (by SLA). If you need a high SLA construct it with the "most possible 9s" and duplicate to min. 1 region is (as John Savill would put it) "multiple of hundreds of miles away"
2. Build your architecture with resilience in mind: Availability Zones, Geo-redundant options etc. Avoid Power Platform for mission critical workloads at all. Sounds obvious but a lot of people use a SaaS service like Power Platform for things they should never use it.
3. Use the monitoring possibilities of Azure: Use SIEM tools whenever possible to track and monitor non typical behavior. Microsoft Sentinel is a good starting point here.
4. Design for incident response: Configure (for example) Logic Apps that trigger certain events if something weird happens, use playbooks and other tools.
5. Design for immutability of Logs: Use appropriate Blobs where you can only add files but never remove them, and other types of secure logging, so that you have, whatever happens, a clear audit track (event sourcing design pattern is your friend here) regardless what happens.
6. Pay attention for supply chain: NIS2 explicitly mentions supply chain risks.
7. Leverage Cloud Design patterns: I cannot repeat this often enough - Use Cloud Design patterns. There are a time proven way of how to solve problems and avoid you need to reinvent the wheel. In terms of NIS2 you could make use of the following:

• Retry and Circuit Breaker Patterns: Different forms of retries that in the later option avoid that your system gets flooded with retries if a service is offline.
• Bulkhead Design Pattern: Break down your infrastructure in some compartments, same as in ships. So if one part gets "flooded" not the entire (ideally loosely coupled) architecture gets down, as you can close the "Bulkhead"

Those parts are only a couple of points but should get your thinking process started to make a step towards becoming NIS2 compliant.

Disclaimer: This is not legal advice. I am not a lawyer, and this article is intended as general guidance only. If you require professional advice, I recommend consulting one of the Big Four auditors or a law firm specializing in IT regulations.