NIS2 and Enterprise Architecture: Mapping the Systems and Dependencies Risk Management Touches

What NIS2 actually asks of essential and important entities

NIS2 widened the net. Where its predecessor reached a relatively narrow set of operators, NIS2 brings a much larger population of essential and important entities into scope — across sectors such as energy, transport, banking and financial market infrastructure, health, digital infrastructure, public administration and more. If you are a regulated financial or critical-entity organisation in the EU, the realistic starting assumption is that some part of NIS2 touches you, and the precise determination is one to confirm with qualified counsel.

Underneath the legal text, the substance is recognisable: take appropriate and proportionate technical, operational and organisational measures to manage the risks to your network and information systems; secure your supply chain; handle incidents, including reporting significant ones within defined timelines; and be able to demonstrate that you do all of this. This article is a preparation and documentation aid, not legal advice. What it shows is where enterprise architecture gives those measures a backbone — because almost every one of them presupposes that you can actually see your systems and how they connect.

Every NIS2 expectation rests on a prior question: do you know your systems?

Risk management, supply-chain security and incident handling all sound like separate workstreams. They share a hidden prerequisite. You cannot assess the risk to a system you have not inventoried. You cannot secure a supply chain whose providers you cannot trace to the services they support. You cannot scope an incident if you do not know what the affected component depends on. The prior question — do you know your systems and their dependencies — sits underneath the whole regime.

For most organisations that knowledge exists, but scattered: a CMDB that drifted, network diagrams in a wiki, supplier lists in finance, criticality assessments in a slide deck from last year. None of it joins up, and the join is exactly what NIS2 conversations need. An enterprise architecture repository is, at heart, the place where those threads become one connected model — systems, the business services they support, the dependencies between them, and the third parties behind them.

• Risk management presupposes a real inventory of network and information systems
• Supply-chain security presupposes you can trace services to their providers
• Incident handling presupposes you know what an affected component depends on
• The common prerequisite is a connected, current view — not four disconnected lists

Mapping systems and dependencies for cyber risk management

The core NIS2 risk-management expectation is to identify and treat the risks to your network and information systems with measures proportionate to the exposure. Proportionality needs a denominator: which systems support which essential services, how critical each is, and what would be affected if one failed. A flat asset list cannot tell you that; a dependency model can.

In an EA repository each system carries attributes that make it analysable — owner, criticality, hosting, the technology it runs on — and points to the business services it supports and the systems it depends on. With that in place you can ask the questions risk management really turns on: if this component is compromised, which essential services degrade? Where does a single weakness propagate furthest? The honest caveat applies as always — the model is only as good as the data you put in it, and risk treatment decisions stay with your security and risk functions. The repository gives them sight, not a verdict.

• System register with owner, criticality, hosting and technology footprint
• Each system linked to the business services it supports
• Dependencies mapped so you can follow propagation paths
• A queryable model that makes proportionality assessable, not guessed

Supply-chain and ICT third-party relationships, made visible

Supply-chain security is one of the places NIS2 most clearly raised the bar. Entities are expected to take into account the security of their supply chain, including the relationships with direct suppliers and service providers, and the quality of those parties' security practices. You cannot manage an exposure you cannot see, and supplier exposure is precisely the kind that accretes invisibly: each individual dependency on a provider looked reasonable when it was made.

A mapped model turns that invisible accretion into something you can count. Link each application to the suppliers and service providers behind it, then trace each essential service down to those third parties. The clusters appear: the provider sitting behind a disproportionate share of what matters, the dependency you would not have chosen deliberately but inherited. This is also exactly the analysis that overlaps with DORA's ICT third-party and concentration-risk work — one model, two regulatory conversations. To be clear about the boundary: the repository surfaces and documents the relationships; the security evaluation of any supplier, and the contractual posture around it, remain yours.

Incident handling: scoping the blast radius from a living map

When something breaks, speed of comprehension matters as much as speed of response. NIS2's incident-handling and reporting expectations assume you can quickly understand what an incident affects and communicate it within defined timelines. The slowest part of that is often not the technical fix but the scoping — working out, under pressure, which services are touched and what they depend on.

A current architecture model collapses that step. Trace the affected component upward to the business and essential services it supports, and downward to the systems and suppliers it relies on, and the blast radius is on screen rather than in someone's head. The same model makes the post-incident account defensible: you can show, from a versioned source, what was in scope and why. We are precise about the limit — an EA repository supports incident handling by providing the dependency context; it does not detect incidents or perform response. Detection, containment and recovery live in your security operations, and the architecture model feeds them rather than replaces them.

• Trace the affected component to the essential services it supports
• Trace it down to the systems and suppliers it depends on
• Scope the blast radius from a model, not from memory under pressure
• Show, from a versioned source, what was in scope — defensible after the fact

Why a sovereign, EU-hostable repository fits this specifically

Three properties of ArchiLU matter more in a NIS2 context than almost anywhere else. It can be hosted in the EU or on-premise, so the sensitive map of which systems support which essential services — close to a blueprint of where you are most vulnerable — does not leave a boundary you control. It is available natively in French and English, which matters when the same model has to serve a French-speaking security committee and an English-language audit or authority exchange. And it is licensed for unlimited users, so the risk, security and architecture people who all need to read the same dependency map are not gated by a seat count; the commercial detail lives on the pricing page rather than here.

The honest boundary, restated because it matters: ArchiLU is an enterprise architecture repository that produces documentation and evidence and makes it easier to assemble. It is not a NIS2 certification, not a control library, and we are transparent about certifications we do not yet hold. What it gives a regulated EU institution is a sovereign, multilingual, connected model of its systems and dependencies — the groundwork NIS2, DORA and the EU AI Act conversations all rest on. For the fastest read on where your own practice stands across portfolio, governance and risk dimensions, the free EA Maturity Assessment scores ten dimensions and returns a prioritised plan in about ten minutes.