NIS2 Article 21 and information system mapping

The NIS2 Directive does not say “buy a mapping tool”. It requires in-scope entities to take appropriate and proportionate technical, operational and organisational measures to manage risks to network and information systems and reduce the impact of incidents.1

Article 21 covers areas including risk analysis, incident handling, business continuity, supply-chain security, secure acquisition/development/maintenance, assessment of control effectiveness, cyber hygiene, cryptography, access control, asset management and, where appropriate, multi-factor authentication and secured communications.1

Information system mapping therefore plays an indirect but important role: it helps teams know the perimeter, connect dependencies and contextualise assets. It does not prove compliance on its own.

FIG. 01What mapping can contribute — and what it cannot prove alone

NIS2 topic	Contribution from mapping	Evidence kept elsewhere
Asset management	Scope, ownership, dependencies	Controlled inventories, procedures
Continuity	Dependency chains	Plans, backups, recovery tests
Incidents	Potential impact in context	Logs, tickets, chronology
Access control	Zones and roles documented	IAM, access reviews, logs

What Article 21 actually asks for

The overall principle is risk management appropriate to the entity’s context.1 This matters for mapping in two ways.

First, technical scope cannot be separated from the services being delivered. A component matters because it supports an activity, stores information, provides access or creates a dependency.

Second, a measure is not assessed only by whether it exists. Organisations need to be able to show that the measure applies to the correct perimeter, is appropriate to risk and, for relevant requirements, is tested or evaluated.

Commission Implementing Regulation (EU) 2024/2690 sets technical and methodological requirements for specific categories of digital entities covered by NIS2, including several cloud, data-centre, managed-service and online-service providers.2 It should therefore not be applied mechanically to every NIS2 entity. ENISA published implementation guidance in 2025 to help the entities covered by that regulation interpret the requirements.3

That scope distinction matters: the Directive, the Implementing Regulation and ENISA guidance do not have exactly the same reach.

Asset management: mapping helps define what is being protected

Asset management is explicitly included in Article 21.1 An inventory can list equipment and applications. A map adds relationships: which process depends on which application? Which cloud service hosts which data? Which third party provides a critical component?

This structure keeps criticality connected to reality. A server is not inherently critical; it becomes critical because one or more service chains depend on it.

ANSSI describes information system mapping as a tool contributing to system mastery, protection, defence and resilience.4

Continuity: visualise the chain before testing recovery

NIS2 cites business continuity, including backup management, disaster recovery and crisis management.1

A map can answer the first question: which components must work for this service to exist? It can build a chain from process to application, identity, data, infrastructure and third party.

But the map does not prove recovery works. Evidence lives elsewhere: test reports, restore logs, exercise results, procedures and recovery metrics. Mapping provides the context used to decide what to test and in which order.

Incident handling: reduce the time needed to understand impact

During an incident, a list of assets rarely answers the urgent question. Teams need to know what the affected component supports, which systems communicate with it and which data or business activities might be affected.

A maintained map can shorten that understanding phase and help identify owners or stakeholders. It does not detect the incident, replace logs or become the investigation timeline.

Supply-chain security: make third-party dependency visible

Supply-chain security and supplier relationships are part of the Article 21 measures.1

An ecosystem view can document SaaS providers, hosting companies, operators, technical subcontractors, interconnections and external services. The useful part is not another supplier list; it is showing which internal services depend on each third party.

That view can guide a supplier review or risk assessment. It does not replace contracts, questionnaires, audits or attestations used as evidence.

Secure development and change: connect components to ownership

NIS2 also addresses the security of acquisition, development and maintenance of network and information systems, including vulnerability handling.1

Mapping can support attribution: who owns the application? Which repository, pipeline or provider is associated with it? Which service is exposed? Which dependencies could be affected by a change?

It does not replace vulnerability management or patching. It provides the context needed to turn “CVE on a component” into “risk to a service”.

Access control and identity: documenting zones does not prove permissions

A map can represent directories, identity providers, administrative zones and trust relationships. That helps teams understand concentration points and common dependencies.

Evidence for access control still sits in IAM configurations, entitlement reviews, logs, MFA mechanisms and account lifecycle procedures. Mapping should remain an index to context, not a substitute for evidence systems.

Measuring effectiveness: mapping helps select what to test

Article 21 includes policies and procedures for assessing the effectiveness of cybersecurity risk-management measures.1 Mapping can support coherent sampling: critical services, shared dependencies, sensitive zones or important providers.

If ten services depend on the same identity provider, testing that dependency’s resilience and controls is likely more informative than selecting ten random assets. That is an audit decision made possible by dependency knowledge.

Three layers that should never be confused

To avoid turning the map into a “NIS2 file”, separate:

structural facts: assets, flows, owners, third parties, dependencies;
controls: MFA, encryption, backups, filtering, monitoring, procedures;
evidence: configurations, logs, test reports, minutes, tickets and risk-acceptance decisions.

A requirement can involve all three layers, but none replaces the other two.

A practical evidence chain

Consider a critical business service hosted in the cloud.

The map shows that it depends on an application, an identity provider, a database and a SaaS provider. The control repository states that MFA, backups and logging are required. Operational systems then provide evidence: MFA configuration, the latest restore-test result, access logs and a supplier review.

Compliance is not “inside the map”. The map makes evidence navigable and contextual.

Checklist: what mapping should be able to contribute to NIS2 work

Without claiming to cover compliance as a whole, a useful repository should make it possible to find quickly:

critical services and activities;
the applications and infrastructure supporting them;
owners;
major technical and external dependencies;
significant flows;
relevant third parties and suppliers;
important data or information categories;
concentration points such as IAM, network, cloud and backup;
the date and perimeter of the latest verification.

When those facts are reliable, they become a shared foundation for risk analysis, continuity, incident handling and evidence preparation. That is where mapping provides the most value: it connects the subjects without pretending to replace them.