NIS2 and Enterprise Architecture: Documenting Systems, Dependencies and Suppliers
NIS2 requires risk-management measures, attention to the supply chain and notification of significant incidents. This work assumes that an entity knows its systems and their dependencies. The architecture repository holds that documentation; it is not a certificate of compliance.
Updated on
What NIS2 requires of essential and important entities
Directive (EU) 2022/2555, known as NIS2, covers far more entities than the directive it replaced. It applies to essential and important entities in sectors such as energy, transport, banking, financial market infrastructure, health, digital infrastructure and public administration. Member States had until 17 October 2024 to transpose it.
The entities concerned take appropriate and proportionate technical, operational and organisational measures to manage the risks to their network and information systems. They address the security of their supply chain and notify significant incidents within set deadlines. Whether an entity is in scope, and what exactly it must do, should be confirmed with qualified counsel.
For a financial entity identified as essential or important, DORA is the sector-specific legal act for the purposes of Article 4 of NIS2, as Article 1(2) of DORA provides. ICT risk management and incident reporting then follow DORA, to the extent set out in that article.
A prior question: knowing your systems and their dependencies
Risk management, supply chain security and incident handling share a prerequisite. The risk to a system missing from the inventory cannot be assessed. A provider can be traced to the services it supports only if that link is documented. The scope of an incident depends on what relies on the affected component.
This knowledge often exists, but in scattered form: a CMDB that has drifted, network diagrams in a wiki, supplier lists in procurement, a criticality assessment in a slide deck. The architecture repository connects these elements: business services, applications, technologies, dependencies and suppliers, each with its owner.
- Risk management assumes an inventory of network and information systems.
- Supply chain security assumes each service is linked to its providers.
- Incident handling assumes you know what depends on the affected component.
Systems, services and propagation
Whether measures are proportionate depends on what each system supports. An asset list does not show which service stops when a system fails; a dependency model does.
In ArchiLU, each application carries its owner, criticality, lifecycle and supplier. It is linked to capabilities, processes, interfaces and technologies. The 360 view centred on an application shows its flows, interfaces, the processes it serves and the capabilities it realises. Risk treatment decisions remain with the security and risk functions.
- Each application with its owner, criticality and technologies.
- The processes and capabilities it serves.
- Interfaces, their protocol and the data they carry.
- Technologies and their end-of-support date, known or unknown.
Suppliers and the supply chain
NIS2 requires entities to take into account the security of their supply chain, including relationships with direct suppliers and service providers. This exposure builds up contract by contract, each one reasonable when it was signed.
In ArchiLU, the chain links functions to applications, then to ICT services, suppliers and contracts. The exposure analysis starts from a provider, works up to the functions that depend on it and flags concentration. It is the same chain that is maintained for DORA. The security assessment of a supplier and the contractual position remain with the entity.
Incident handling: scoping what is affected
After an incident, the affected services, what they depend on and who needs to be informed must be established quickly. This scoping often takes longer than the technical fix, especially when diagrams are scattered.
A current architecture speeds it up: from the affected component to the processes and functions it supports, then to the technologies and suppliers it depends on. Each object names its owner. ArchiLU does not detect incidents or carry out the response; those tasks belong to security tools and teams, which the dependency map informs.
Hosting and access
A map of the systems that support essential services shows where the organisation is most exposed. In ArchiLU, each organisation has its own dedicated instance, hosted in the European Union; deployment on your infrastructure is an optional service, quoted separately.
Access follows each user’s permissions. An auditor enters through their engagement and reads the chain in read-only mode, limited to its scope and period. The audit trail is chained, verifiable and exportable by the administrator.
In ArchiLU
Start with the function. Find the provider.
In ArchiLU: Payments → Payment Engine → Maelis Paiements. Four screens in the same application, connected through the same objects.
Identify what must keep running.
The function catalogue shows criticality, ownership and documented links. Critical or important functions are distinguished from supporting functions.
Understand why it is critical and what supports it.
The Payments record explains the impact of an interruption, names its owner and links to the Payment Engine application. Missing relationships remain visible.
Identify the provider: Maelis Paiements.
The actor registry opens the Maelis Paiements provider record, with its identity, status and role. The dependency chain links this same provider to the Payment Engine application and the ICT maintenance service.
See the dependency. Spot what is missing.
The dedicated view links Payments to its application, ICT services and documented providers. Contracts appear when they cover these services; missing links are identified for each object.
Frequently asked questions
- Does an architecture repository make an organisation NIS2 compliant?
- No. Compliance is assessed by the competent authority against the entity’s organisational, technical and procedural measures. The repository documents systems, their dependencies and their suppliers, which makes the files easier to prepare and keep current.
- How does mapping help with the supply chain?
- Each application is linked to its ICT services, suppliers and their contracts. The entity can follow a service to the third parties behind it and identify the providers on which several functions depend. The security assessment of a supplier remains work for the entity and its advisers.
- Does a bank subject to DORA also apply NIS2?
- For a financial entity identified as essential or important, DORA is the sector-specific act for the purposes of Article 4 of NIS2. ICT risk management and incident reporting then follow DORA, to the extent set out in that article. Legal counsel should confirm how the two fit together; the dependency chain serves both files.
- What does the map provide during an incident?
- The starting scope: the processes and functions that rely on the affected component, the technologies and suppliers it depends on, and the owner of each object. Detection, containment and recovery remain in security tools and processes.