NIS2-ready CMDB: the minimum asset data model for cyber-resilience (EU)

Estimated reading time: 15 minutes

Key takeaways

• A NIS2‑aligned CMDB is a central control for EU cyber resilience, not a “nice‑to‑have” inventory.
• NIS2 expectations around asset management, incident reporting and supply‑chain risk translate into very concrete CMDB data model and process requirements.
• Robust ITAM feeding your CMDB is essential to achieve complete asset visibility, ownership and supplier traceability.
• National guidance from ANSSI and CCB Belgium reinforces the need for structured, current, and security‑oriented asset data.
• A pragmatic roadmap—covering data model design, discovery, ITAM integration and governance—lets you build a NIS2‑aligned CMDB in practice.

How NIS2 reshapes asset and configuration management

NIS2 dramatically broadens who falls in scope. It applies to essential entities such as large organisations in energy, transport, banking, digital infrastructure, healthcare, drinking water, wastewater and public administration, typically with at least 250 employees or €50M turnover. It also covers important entities like medium‑sized firms in postal services, waste management, digital providers, food production and various manufacturing sectors, usually with at least 50 employees or €10M turnover, as summarised in the official NIS2 Directive (EUR-Lex). Additionally, guidance from other commentators confirms this expanded reach and obligations around risk management and reporting across these sectors, as outlined by industry observers.

Under NIS2, both essential and important entities must implement “appropriate and proportionate” cyber risk management measures, report significant incidents under tight timelines, ensure business continuity and crisis management, and manage supply chain risks. To satisfy these duties in practice, you need structured asset and configuration management. You must be able to answer, clearly and quickly:

• Which IT, OT, cloud and SaaS assets support each essential or important service.
• How those assets are interconnected, to understand impacts and propagation.
• Which changes have been made, by whom, and under which approvals.
• Where third‑party providers sit in each critical service chain.

These expectations directly drive NIS2 CMDB requirements. A traditional, “best effort” inventory is no longer sufficient. Instead, you need a CMDB data model that can:

• Capture every relevant configuration item (CI) across IT and OT.
• Link CIs to services, criticality levels, and regulatory context.
• Support asset visibility cybersecurity by exposing attack surface and dependencies.
• Provide reliable, auditable evidence for regulators and supervisory authorities.

Without a maintained CMDB, you struggle to map vulnerabilities to services, understand incident impact, or visualise supply‑chain dependencies. With a NIS2‑aware CMDB, you can instantly see which essential services rely on an exposed component, which suppliers are involved, and what the business impact looks like for your regulator.

What does NIS2 require for asset management?

NIS2 expects organisations to:

• Maintain a complete inventory of assets supporting essential and important services.
• Classify assets by business criticality and service.
• Map technical and business dependencies between services and components.
• Track changes and configurations over time.
• Monitor third‑party and supply chain dependencies tied to each service.

Defining NIS2 CMDB requirements in practical terms

In practice, NIS2 CMDB requirements are the minimum capabilities your CMDB must provide so you can prove compliance with the directive’s asset, configuration, and risk‑management obligations. The law rarely uses the word “CMDB”, yet its insistence on structured inventories, traceability, and documentation points to very specific CMDB features, as several industry analyses of NIS2’s operational impact highlight.

A NIS2‑aligned CMDB must address at least five capability areas.

1) Coverage

Your CMDB should register configuration items that cover:

• IT assets: servers, virtual machines, containers, applications, databases, network devices, endpoints.
• OT assets: SCADA components, PLCs, sensors and industrial controllers where they support essential or important services.
• Cloud and SaaS: IaaS, PaaS and SaaS services, mapped by cloud account, subscription, and region.
• Identities and roles: user accounts, privileged and service accounts, and groups.
• Data stores: databases, data lakes, file shares, and platforms that hold personal, confidential or critical operational data.

Partial coverage, such as documenting only on‑prem servers, is not enough for NIS2. You must demonstrate visibility across your full digital and physical attack surface.

2) Classification

Every CI needs attributes that support NIS2 obligations:

• Criticality level (e.g., high/medium/low based on business impact).
• Link to business services, identifying which essential or important service each CI supports.
• Legal entity and jurisdiction for that service.
• Sector classification (energy, transport, banking, healthcare, etc.).

This classification underpins risk‑based prioritisation and correct routing of incident reports to the relevant national authority once the directive is transposed.

3) Security attributes

To support asset visibility cybersecurity, the CMDB must hold security‑relevant data, for example:

• Asset owner and service owner.
• Data sensitivity (public, internal, confidential, secret; presence of personal data).
• Exposure (internet‑facing, internal, OT network, partner network).
• Simple attack surface indicators, such as external endpoints or open management ports.
• Links to known vulnerabilities via integration with vulnerability management tools.

These attributes help risk teams and CISOs focus on the assets that truly matter for NIS2 reporting and mitigation.

4) Change and configuration history

NIS2 emphasises proactive risk management and incident investigation. Therefore your CMDB should maintain:

• Versioned configuration details where relevant (OS version, application version, key settings).
• A history of changes to each CI: when it was created, modified, or retired.
• Links to change tickets, approvals and implemented security controls for critical changes.

This level of traceability supports both internal investigations and evidence for supervisory authorities after incidents.

5) Automation and continuous updates

Manual CMDB maintenance alone cannot cope with modern, hybrid environments. For NIS2, your CMDB must be fed by:

• Automated discovery tools for networks, endpoints, and cloud resources.
• Integrations with platforms such as Microsoft Azure for cloud inventory.
• Reconciliation rules to merge data from multiple sources, avoid duplicates, and keep records fresh.

Regulators, including national authorities like ANSSI in France and CCB in Belgium, will expect you to demonstrate not only that you have a CMDB, but that it is accurate and current. While there may be no public “ANSSI CMDB” or “CCB Belgium CMDB” template, their NIS2‑aligned guidance clearly points towards structured asset management supported by automation.

What should a CMDB include to comply with NIS2?

To align with NIS2 CMDB requirements, your CMDB should include:

• Full coverage of IT, OT, cloud and SaaS assets.
• Service‑based classification and business criticality.
• Security attributes such as owner, data sensitivity and exposure.
• Dependency mappings between services and assets.
• Change and configuration history for critical components.
• Automated discovery and reconciliation mechanisms.
• Links to incident, change and risk records.

ITAM for NIS2: how asset management powers your CMDB

IT asset management (ITAM) focuses on the financial, contractual and lifecycle aspects of IT assets, from purchase to retirement. CMDB, by contrast, focuses on configuration, dependencies and operational context. Meeting NIS2 CMDB requirements demands both disciplines working together within a single governance model.

ITAM for NIS2 means using ITAM’s lifecycle and vendor intelligence to enrich your CMDB so you can address the directive’s expectations around risk management, supply‑chain oversight, and accountability. ITAM typically provides:

• Lifecycle data: purchase dates, warranty and support coverage, end‑of‑life timelines.
• Licence and contract data: which supplier provides which service, what SLAs apply, where data is processed.
• Financial and organisational details: cost centres, budget owners, asset and service owners.

When this information flows into the CMDB, asset visibility cybersecurity improves significantly. Discovery shows what is running, while ITAM confirms what should be running and under which contract.

ITAM also improves supply‑chain and vendor risk management. A single supplier entry in ITAM can be linked to many CIs in the CMDB, revealing where a cloud provider, MSP, or software vendor underpins multiple essential services. Consequently, you can identify concentration risk, prioritise due diligence, and align with NIS2 expectations on third‑party risk.

Governance and accountability also benefit. Owners defined in ITAM can be surfaced in CMDB views so every critical CI and business service has a clearly assigned accountable person. During incidents, this speeds decision‑making and improves communication with regulators.

Technically, integration between ITAM and CMDB usually follows one of two patterns:

• CMDB as consumer: CMDB imports asset identifiers, owners, and supplier references from ITAM while maintaining configuration and relationship details.
• Bi‑directional synchronisation: ITAM pulls status and location from CMDB; CMDB pulls financial and vendor data from ITAM. Shared keys, such as asset tags, maintain alignment.

In both cases, it is vital to define which system is the “source of truth” for each attribute, and to control updates through clear governance.

How does ITAM help with NIS2 compliance?

ITAM helps NIS2 compliance by supplying lifecycle, vendor and financial data that, once integrated into the CMDB, ensures complete asset visibility, stronger supply‑chain oversight, and clear ownership. Together, these capabilities let you prove that essential and important services are supported by managed, accountable assets under appropriate contracts.

Designing a NIS2‑ready CMDB data model

A CMDB data model defines the classes of configuration items you track, the attributes you store about them, and the relationships that link them together. For NIS2, this model must evolve from generic IT service views to a richer, regulation‑aware structure.

Traditionally, many CMDBs focused on mapping applications to servers and network devices. Under NIS2, however, you must explicitly model:

• Essential and important services as defined in national transposition.
• Regulatory context such as sector, jurisdiction and supervisory authority.
• Security posture and supplier dependencies for each critical component.

Industry best‑practice frameworks such as ITIL encourage clear service and CI definitions. NIS2 adds requirements for specific attributes and relationships tied to cyber risk and compliance.

Core CI classes

A NIS2‑ready CMDB data model will typically include at least:

• Business services (including essential and important services).
• Applications (line‑of‑business systems, core platforms, SaaS).
• Infrastructure (servers, VMs, containers, middleware).
• Network components (routers, firewalls, switches, load balancers).
• Data stores (databases, warehouses, file repositories).
• Identities and groups (user accounts, privileged accounts, IAM groups).
• Locations (data centres, OT sites, offices, cloud regions).
• Third‑parties and suppliers (vendors, MSPs, cloud providers).

Key relationships might include:

• Business service → supported by → applications.
• Application → hosted on → infrastructure.
• Infrastructure → connected via → network devices.
• Application/data store → used by → identities and groups.
• Business service/application → depends on → supplier.

NIS2‑specific attributes

For business service CIs, add attributes such as:

• NIS2 classification: essential / important / other.
• Sector: energy, transport, healthcare, banking, etc.
• Supervisory authority or regulator.
• Jurisdiction or country.
• Criticality rating (e.g., impact if unavailable).
• Recovery parameters (RTO, RPO).

For technical CIs (applications, infrastructure, network, data stores):

• Linked NIS2‑classified services.
• Criticality rating aligned with service impact.
• Security posture: patch level, last patch date, number and severity of known vulnerabilities, key security controls in place (EDR, encryption, MFA, logging).
• Data attributes for data stores: data classification and subject categories (customers, employees, suppliers).
• Supplier dependency: supplier name, contract reference, SLA level.

For identities:

• Role (admin, standard user, service account).
• Privilege level.
• Linked services and assets.

Normalisation and governance

To keep this model usable, enforce:

• Normalisation: consistent naming of software, platforms and vendors.
• Naming standards: predictable CI naming patterns by type, environment and region.
• Governance: a CMDB owner, data stewards for each CI class, and controlled change processes for altering the data model.

By linking these design choices back to NIS2 CMDB requirements, you get a CMDB that directly supports EU cyber resilience: fast incident impact analysis, clear regulatory reporting routes, and visibility of cross‑border supplier dependencies.

What should a NIS2‑ready CMDB data model look like?

A NIS2‑ready CMDB data model includes CI classes for business services, applications, infrastructure, network devices, data stores, identities, locations and suppliers. Each CI holds NIS2‑relevant attributes such as classification (essential/important), sector, regulator, criticality, recovery targets, security posture, and supplier references, and all are linked by clear service‑to‑asset relationships.

Achieving asset visibility for cybersecurity under NIS2

Asset visibility cybersecurity means having a complete, accurate, and current view of all assets that make up your attack surface and how they relate to critical services. Under NIS2, this visibility is essential for mapping exposure, scoping incidents and vulnerabilities rapidly, and meeting demanding reporting deadlines.

To achieve this, the CMDB must ingest data from multiple discovery and inventory sources. Typical inputs include:

• Network discovery tools that identify IP‑based devices.
• Endpoint agents that collect OS, software and configuration details.
• Cloud provider APIs for platforms such as Azure, AWS and GCP.
• SaaS admin portals, which reveal applications in use and associated identities.
• EDR/XDR platforms that combine inventory and security telemetry.
• Identity platforms (AD, Azure AD, other IAM systems).
• ITAM repositories that list procured and licensed assets.

Each source sees the environment from a different angle. Consequently, CMDB reconciliation logic must merge overlapping data into a single CI per asset. Attributes from more authoritative sources (for example, cloud APIs for cloud resource IDs) should override others.

Hybrid environments complicate this picture. On‑prem systems, public cloud workloads and private cloud or edge deployments all need to appear in one logical inventory. OT and IoT devices add further complexity because they often sit on separate networks, are managed by different teams, and may require specialised scanning tools. Yet, where they underpin essential services, NIS2 still expects them to be captured and managed.

Shadow IT is another challenge. Unapproved SaaS tools or rogue hardware can appear in expense reports, authentication logs, or outbound network traffic. Processes should be in place to:

• Detect these assets.
• Register them in ITAM and CMDB.
• Decide whether to regularise or retire them.

Finally, continuous reconciliation is vital. Discovery scans and API synchronisations should run on a schedule appropriate to the environment: perhaps daily or even more frequently for critical networks and cloud accounts. Reconciliation rules must:

• Match records by hostname, IP, serial number, asset tag or cloud resource ID.
• Merge attributes while respecting each source’s authority.
• Flag unknown or unmanaged assets for review.

The outcome is a living CMDB that reflects your real‑world attack surface and can be used directly to support NIS2 CMDB requirements, vulnerability prioritisation and incident reporting.

How do you achieve asset visibility for NIS2?

To achieve asset visibility cybersecurity under NIS2:

• Integrate automated discovery tools and cloud APIs with your CMDB.
• Reconcile data from ITAM, security platforms and identity systems.
• Include OT/IoT and shadow IT in the asset inventory.
• Continuously update records and flag unknown or non‑compliant assets.
• Map every asset to the essential or important services it supports.

Using the CyFun framework with a NIS2‑aligned CMDB

The CyFun framework is referenced as an EU‑oriented or sector‑specific cyber resilience framework structured around the familiar cybersecurity lifecycle: know, protect, detect, respond and recover. While detailed public specifications are limited, its orientation clearly aligns with NIS2 CMDB requirements for structured asset knowledge and operational resilience.

In this context, you can treat CyFun as an overlay that helps you operationalise NIS2 controls. A strong CMDB is central to that effort because it provides the data CyFun functions depend on.

• Know: The CMDB offers a consolidated map of services, systems and data, fulfilling the “know your estate” requirement.
• Protect: Security attributes and criticality ratings in the CMDB guide where to apply stronger controls and monitoring.
• Detect: Integrating CMDB with SIEM and XDR tools allows security alerts to be tied back to specific services and business impacts.
• Respond: CI relationships help teams plan containment, understand dependencies, and avoid collateral damage.
• Recover: CMDB records of RTO/RPO, configurations and dependencies support structured, compliant recovery.

You can align CMDB fields and reports with CyFun control areas. For example:

• CyFun “Know”: a CMDB report listing all essential and important services, their supporting CIs, and associated suppliers.
• CyFun “Protect”: attributes on CIs indicating which security controls (EDR, backups, encryption) are in place.
• CyFun “Detect”: mapped links between monitoring tools and CIs, so alerts can be enriched with service criticality.
• CyFun “Respond”: incident playbooks that query CMDB dependencies when an asset is compromised.
• CyFun “Recover”: referencing CMDB recovery targets and configuration baselines when rebuilding systems.

Through this mapping, NIS2 CMDB requirements become the foundation for implementing CyFun in a measurable, auditable way.

What is the CyFun framework and how does it relate to NIS2?

The CyFun framework is an EU‑oriented cyber resilience approach that structures activities around knowing, protecting, detecting, responding to and recovering from incidents. A NIS2‑aligned CMDB supplies the asset, service and dependency data CyFun needs to deliver each of these functions effectively.

From ANSSI CMDB expectations to CCB Belgium compliance

Although NIS2 is an EU‑wide directive, each Member State transposes it into national law and guidance. Two influential examples in the CMDB and asset‑management space are ANSSI in France and the Centre for Cybersecurity Belgium (CCB).

ANSSI, the French National Cybersecurity Agency, promotes robust asset cartography, risk‑based classification and change traceability. Its guidance emphasises that organisations should maintain:

• A current map of information systems (“urbanisation”), including applications, infrastructure, networks and significant data flows.
• A clear identification of critical systems and their dependencies.
• Controlled, documented, and auditable changes to critical assets.

A well‑structured CMDB that aligns with these principles and meets NIS2 CMDB requirements effectively becomes an “ANSSI CMDB,” enabling organisations to satisfy both EU‑level and national obligations through the same asset‑management practices.

CCB Belgium serves as the national competent authority for cybersecurity and leads the country’s NIS2 transposition. Its expectations, as reflected in broader tracking of national implementations across the EU by the ECS NIS2 transposition tracker, include:

• Detailed inventories of systems and infrastructures that support essential services designated under Belgian law.
• Capability to meet strict timelines for incident notifications, which requires accurate asset and dependency data.
• The possibility of additional, Belgium‑specific obligations around critical infrastructure and data handling.

Designing your CMDB to meet NIS2 CMDB requirements therefore positions you well for both ANSSI CMDB‑style expectations and CCB Belgium compliance. The common themes are:

• Centralised, well‑governed CMDB and ITAM repositories.
• Rich classification and dependency mapping.
• Reliable traceability and evidence generation.

How do ANSSI and CCB Belgium influence NIS2 CMDB requirements?

ANSSI and CCB Belgium implement NIS2 at national level and stress structured asset cartography, risk‑based classification and robust incident reporting. The primary way to satisfy these expectations is to maintain a well‑governed CMDB and integrated ITAM practice that deliver accurate, auditable asset and configuration data.

Implementation roadmap: building a NIS2‑aligned CMDB

Turning NIS2 CMDB requirements into practice requires a structured implementation roadmap. The following steps provide a pragmatic path from today’s CMDB to a fully NIS2‑aligned environment.

Step 1: Assess current state

Begin with a frank assessment of your current position:

• CMDB coverage: which CI types are modelled, which services are mapped, and where the gaps lie.
• Data quality: completeness, accuracy and timeliness of CI records.
• ITAM maturity: which assets and contracts are tracked, how reliable the data is, and how (or if) it links to CMDB.
• Discovery tooling: what network, endpoint, cloud and SaaS discovery tools you use, and how outputs are consumed.

Compare your findings against NIS2 CMDB requirements and any applicable national guidance such as ANSSI principles or CCB Belgium expectations, noting gaps and priorities.

Step 2: Redesign or enhance the CMDB data model

Using the earlier blueprint:

• Add NIS2‑specific attributes for essential/important classification, sector, regulator, criticality, RTO/RPO and security posture.
• Align the CMDB schema with ITAM, ensuring shared identifiers and referencing of suppliers and contracts.
• Map CyFun framework areas (know, protect, detect, respond, recover) to CMDB attributes and reports.

Document the updated data model, publish it internally, and establish change‑control procedures so it remains stable and maintained.

Step 3: Improve asset discovery and reconciliation

Next, strengthen discovery:

• Implement or tune network and endpoint discovery, cloud API integrations, and SaaS inventory collection.
• Define reconciliation rules that specify attribute precedence and duplicate resolution.
• Configure monitoring and alerts for new, unknown or unmanaged assets emerging from discovery.

The result is more comprehensive asset visibility cybersecurity and a more trustworthy CMDB baseline.

Step 4: Integrate ITAM for NIS2

With a solid CMDB structure and discovery in place, connect ITAM:

• Decide which system is authoritative for ownership, procurement, warranty, licence and supplier data (commonly ITAM), and which for configuration and relationships (CMDB).
• Build integration jobs that synchronise data regularly, often nightly.
• Define RACI so it is clear who owns ITAM data accuracy, who owns CMDB data quality, and who consumes the combined information.

You now have a single, coherent view of each asset’s financial, contractual, operational and security context.

Step 5: Embed CMDB in security and risk workflows

To make the CMDB matter for NIS2, embed it into key workflows:

• Incident management: use CMDB to identify affected services, owners and dependencies for each incident.
• Vulnerability management: drive remediation priorities based on service criticality, NIS2 classification and supplier involvement.
• Change management: ensure every change to critical CIs is linked to CMDB entries and follows formal approval paths.
• Reporting: pre‑define NIS2 incident report templates that pull from CMDB (impacted assets, services, locations, suppliers).

Integrating with established ITSM tools that support strong CMDB and workflow capabilities, such as ServiceNow or Atlassian’s ITSM platform, can accelerate this step.

Step 6: Ongoing governance and audit readiness

Finally, establish continuous governance:

• Define KPIs such as CI completeness, data freshness and the percentage of incidents correctly linked to services/CIs.
• Perform regular internal audits to sample CI records and verify accuracy.
• Track changes in NIS2 guidance and national transposition rules, updating your data model and processes accordingly.
• Use lessons from incidents and audits to refine discovery, classification and workflows.

This governance loop turns the CMDB into a living control framework rather than a static documentation exercise.

How do I implement a NIS2‑aligned CMDB?

To implement a NIS2‑aligned CMDB:

• Assess current CMDB, ITAM and discovery capabilities against NIS2.
• Redesign your CMDB data model with NIS2‑specific attributes and relationships.
• Strengthen automated discovery and reconciliation across IT, OT, cloud and SaaS.
• Integrate ITAM for ownership, vendor and lifecycle data.
• Embed CMDB into security, risk and reporting workflows.
• Establish governance, KPIs and regular internal audits.

How a NIS2‑aligned CMDB boosts EU cyber resilience

Building a CMDB that satisfies NIS2 CMDB requirements delivers benefits far beyond compliance paperwork. At EU level, regulators and supervisory authorities aim to improve cyber resilience across sectors and borders. A mature CMDB, backed by strong ITAM, supports these goals in several ways.

First, it improves situational awareness. With a near‑real‑time view of assets, dependencies and criticality, you can better anticipate systemic risks, such as heavy dependence on a single cloud region or supplier. This clarity helps you plan mitigations before incidents occur.

Second, it reduces systemic and supply‑chain risk. Visibility of which suppliers support which essential or important services makes it easier to spot concentration risks and coordinate responses to vendor‑level incidents. Information can be shared and understood more easily between operators and regulators.

Third, it creates a robust evidence base. A CMDB and ITAM repository designed with NIS2 and frameworks like ITIL best practices in mind gives boards, auditors and regulators the data needed to understand risk posture, incident impact and remediation progress. Decisions become more data‑driven and less reliant on ad‑hoc spreadsheets or tribal knowledge.

Finally, such a CMDB improves operational performance. Once you have clear service‑to‑asset mappings, change and incident management can be more targeted, reducing outages and speeding up recovery. Compliance with NIS2 then becomes a natural by‑product of good practice rather than a separate, burdensome project.

How does a CMDB contribute to EU cyber resilience?

A well‑governed CMDB contributes to EU cyber resilience by giving organisations and regulators a real‑time, accurate picture of assets, dependencies and risks. This shared understanding is essential to prevent incidents, contain their impact when they occur, and coordinate responses across sectors and borders.

Conclusion: Turning NIS2 CMDB requirements into a resilience advantage

NIS2 CMDB requirements push organisations to rethink how they manage asset and configuration data. A NIS2‑ready CMDB combines a tailored CMDB data model, integrated ITAM for NIS2, and strong asset visibility cybersecurity through automated discovery and reconciliation. It embeds NIS2‑specific attributes such as essential/important classifications, sector and regulator details, criticality, recovery targets and security posture into daily operations.

When aligned with frameworks like the CyFun framework and informed by national guidance such as ANSSI CMDB expectations and CCB Belgium compliance, this CMDB becomes more than a registry. It becomes a strategic control point that supports EU cyber resilience, shortens incident response times and improves change success rates.

To move from theory to reality, organisations should start with a focused CMDB/ITAM maturity assessment against NIS2 CMDB requirements, then design and execute a realistic roadmap covering data model redesign, discovery, ITAM integration, workflow embedding and governance. For organisations that want to translate NIS2 CMDB requirements into concrete tooling, one practical option is to implement configuration management in HaloITSM, using its CMDB & configuration management capabilities together with integrated IT asset management in HaloITSM and broader IT service management foundations. If you want expert support to accelerate that journey, from strategy to hands‑on implementation, consider partnering with specialised ITSM and ITAM consultants like SMC Consulting, who can help you build a NIS2‑aligned CMDB in 30 days following proven CMDB best practices and automation guidance.

About the author

Frequently asked questions