IR 2024/2690 12.4 Asset inventory: requirements and evidence

What the NIS2 asset inventory requirement asks for and why it comes first

If a supervisor asks you to show your NIS2 asset inventory, you need a single, current list of the operations and services your entity provides and the network and information systems and other assets that support them. Point 12.4 of the Annex to Commission Implementing Regulation (EU) 2024/2690 asks for that list to be complete, accurate, up to date and consistent, with every change to an entry recorded in a traceable way. The granularity is left to you, so the test is whether the inventory is detailed enough to act on, not whether it lists every component by default. Confirm with your competent authority or your sector guidance how they expect this to be shown, since the regulation sets the outcome but not the template.

The inventory comes first because other requirements read from it. Point 12.1 requires every asset to carry a classification based on confidentiality, integrity, authenticity and availability, with availability tied to business continuity recovery objectives. You cannot classify what you have not listed, and you cannot decide which logging scope in point 3.2 or which patch timing in point 6.6 applies to a server if the server is missing from the list. ENISA's June 2025 guidance treats an inventory updated when a new security patch is announced as evidence for patch management, so the inventory is also the link between a vulnerability bulletin and the systems you must act on.

Three things usually make this hard. Shadow assets such as departmental SaaS subscriptions, test servers and devices connected by staff without a ticket are rarely recorded. Cloud resources are created and deleted by automation, so a list compiled quarterly is stale within days. Stale records accumulate when decommissioned systems stay in the register and when owners change without anyone updating the entry. A practical first step is to reconcile your register against cloud provider accounts, network scans and endpoint agents, then assign a named owner and classification to each entry. Open-source platforms such as GLPI and Wazuh can supply discovery data, but deciding what counts as an asset and who answers for it remains an organizational decision.

Which assets belong in a NIS2 asset inventory

Point 12.4 of the Annex to Implementing Regulation 2024/2690 asks for a complete, current inventory, so the first job is deciding what counts as an asset. The cards below cover the scoping decisions that change how much work the inventory takes and what an assessor will test.

Operations and services first

Start from the operations and services the entity delivers, not from hardware. Point 12.4.2 expects the inventory to list them, then link each one to the systems that support it. A customer-facing payment service, a patient records portal or a dispatch system each needs a named owner, its supporting systems and its recovery expectations. Check that every service in the business continuity plan appears here, because a service missing from the inventory usually has no classification or logging either.

Network and information systems

Capture every network and information system that stores, processes or transmits data for those services, including servers, databases, identity services, firewalls, routers and endpoints. Record the system's purpose, location, operating system or firmware version and administrator. Test the list by picking a production service and tracing it to each system. Gaps usually appear around shared services such as directory, DNS and backup tooling, which many teams assume belong to someone else.

Supporting assets and supplier components

Supporting assets include facilities, power and cooling equipment, network circuits, removable media and components supplied by third parties, such as managed firmware, licensed appliances and open-source libraries embedded in your own software. Decide which of these change your classification or patching work, and record them at that level. Confirm with each supplier which of their components you depend on, and request their contacts and support end dates in writing so the entry stays current.

Cloud and virtual resources

Cloud accounts, subscriptions, virtual machines, containers, managed databases, object storage and infrastructure-as-code templates are assets in their own right. Ephemeral workloads create the hardest inventory problem because they can appear and disappear between scans. Decide whether the inventory records templates and accounts as assets, or whether workloads are discovered automatically at intervals. Document that choice, because an assessor will ask how a short-lived instance that handled sensitive data was captured.

Teams and third parties to include

Capture assets owned or operated by IT, development, operations, facilities, finance systems teams, shadow IT projects and external providers. Managed service providers, hosting companies and outsourced developers often run systems that appear nowhere in internal records. Include them through contract schedules or periodic attestations, and state who keeps each entry accurate. Ask each owner which systems they bought, configured or administer, because those answers reveal assets the central team never saw.

Granularity that fits size and risk

Granularity should match the entity's size and risk: a small organization can record a system as one entry, while a larger one may need components, software versions and interfaces for critical services. Point 12.4 leaves the level to the entity, so document the rule you chose and why. Set a finer level for assets that feed classification under point 12.1 and patching under point 6.6. An assessor will test whether the level is enough to act on, not whether it matches a template.

How an assessor tests the asset inventory

This table compares the main tests an assessor runs against the point 12.4 inventory, the evidence each test requests and the gaps that most often appear. Read each row as a test the organization should rehearse before an audit, since the findings show where an inventory that looks complete on paper breaks down under sampling.

Test approach	Evidence requested	Common finding
Sample inventory entries back to the live environment	Inventory export with a random selection of entries, plus matching host, network or cloud console records for the same assets	Entries exist for decommissioned hosts, while live systems found on the network have no entry
Trace change history for a sample of entries	Audit log or versioned records showing who changed each sampled entry, when, and why	Owner or classification fields were edited with no recorded reason or approver
Check consistency with classification records	Classification register under point 12.1 cross-referenced to inventory entries and business continuity recovery objectives	Assets carry no classification level, or inventory and classification records name different owners or criticality
Test whether the review cycle actually ran	Dated review records, reconciliation reports and evidence of updates after the latest security patch announcements	Review sign-offs exist, but the underlying data was not updated, or the last full review predates recent changes
Check granularity against operations and services	Mapping from documented operations and services to the systems and supporting assets that deliver them	Supporting assets such as network devices, cloud accounts or SaaS tenants are missing from the inventory
Verify tool configuration and coverage	Configuration of the inventory tool, discovery scope and agent deployment reports	Discovery covers only part of the network, and agent coverage gaps are not measured or reported
Review inventory metrics	Metrics such as counts of unclassified, unowned or stale entries, with trend over time	Metrics are not produced at all, or they are produced but no one acts on the exceptions

Building an asset inventory that stays current

The sequence below turns point 12.4 into a working register: scope and granularity are set first, sources are reconciled into one list, owners and classifications are assigned, and change recording and reviews keep the inventory accurate over time.

Define scope and granularity
Start by stating which operations, services and systems the inventory covers, and how fine the entries should be. Point 12.4.2 asks for granularity appropriate to the entity, so the team agrees on what counts as one asset (a server, a virtual machine, a database, a service account, a cloud subscription) and which business services each asset supports. Management or the risk owner signs off the scope. The output is a short scope statement with an entry definition, a list of in-scope business services and the boundaries of the inventory, such as which cloud accounts, data centers and remote sites are included.
Discover assets from every source
Collect candidate assets from all the places they can appear: network discovery, endpoint agents, hypervisor and cloud provider consoles, configuration management databases, procurement and license records, identity directories and application owners' lists. No single source is complete, and shadow systems often appear only in one of them. Record each source, when it was pulled and who ran the pull. Keep the raw exports, because they are evidence of how the inventory was built. The output is a set of raw discovery exports with source and date recorded for each.
Reconcile sources into one register
Merge the raw exports into a single register and resolve conflicts. Duplicates are matched on stable identifiers such as hostname, serial number, MAC address or cloud resource ID. Each asset that appears in one source but not another is either confirmed, corrected or flagged as unknown and investigated. Unknown assets are not left out of the register. The output is one reconciled register in which every entry has a unique identifier, a record of the sources that confirmed it and a list of open discrepancies with an owner for each.
Assign owners and classification
Each asset needs a named business owner and a technical custodian. Point 12.1 then requires a classification level based on confidentiality, integrity, authenticity and availability requirements, with availability tied to the business continuity recovery objectives in the entity's plans. Owners confirm the classification, and the people responsible for continuity confirm the availability values. The output is a register in which every entry carries an owner, a custodian and a classification record, with the date and approver of each classification.
Set change-recording rules
Point 12.4.3 requires changes to entries to be recorded in a traceable manner. Write rules that state what counts as a change (new asset, retirement, owner change, software or firmware change, reclassification, network move), who may make it, which system holds the history and how long history is kept. Where the inventory tool supports change logging, configure it and keep the configuration. Where it does not, use a controlled change log linked to tickets. The output is a written change-recording procedure and a working change history that can be sampled by an assessor.
Connect the inventory to patching and logging
Link the register to the processes that depend on it. Patch management under point 6.6 relies on knowing which assets run affected software, and ENISA's June 2025 guidance lists an inventory updated when a new security patch is announced as evidence. Logging decisions under point 3.2 also depend on the classification. Test this link with a sample: pick a recent vendor patch and show that the affected assets were identified from the register. The output is a documented dependency map and a dated example showing the register used in a real patch cycle.
Schedule regular reviews and record them
Point 12.4.3 requires regular review and update of the inventory and its assets. Set a review cycle that the entity can keep, with triggers that force an earlier review, such as a major change, an incident or an acquisition. Each review checks for missing assets, stale owners, outdated classifications and entries that no longer exist. Track inventory metrics such as the share of assets with a confirmed owner, which ENISA lists as evidence. The output is a signed review record for each cycle, with findings, corrections and a list of actions carried forward.

Which evidence passes an asset inventory review

ENISA's June 2025 guidance names a small set of artifacts that show an asset inventory is complete, current and traceable. Each artifact needs an owner and a routine that keeps it accurate between audits, not a one-time export produced the week before an assessment.

Inventory documentation

This is the written procedure that defines what counts as an asset, which sources feed the inventory, who owns each entry, and how often reviews happen. Include the granularity rule required by point 12.4.2, so an assessor can see why a router is listed individually while a fleet of identical workstations may be grouped. Between audits, review the document at a fixed interval and whenever the operating model changes, and record the approval date and approver.

Up-to-date inventory with change history

The inventory itself must be complete and consistent, and every change to an entry must be recorded in a traceable way. Ask whether each change keeps the previous value, who made it, and when, and whether automated discovery updates are logged as changes rather than silent overwrites. Spot-check a sample of new, retired and reclassified assets against their source tickets or discovery records.

Inventory metrics

Metrics show whether the inventory is trending toward completeness. Useful measures include the share of discovered hosts that have an owner, the number of assets without a classification level under point 12.1, and the count of entries not seen by discovery within an agreed window. Keep the metric definitions and the monthly values, so the trend can be shown to an assessor rather than a single snapshot.

Inventory tool configuration

Assessors test the tool as well as its output. Keep the configuration of each discovery source, including scan scope, agent deployment coverage, collection schedules and the fields collected for hardware, software, network interfaces and services. For example, an illustrative Wazuh deployment should show which endpoints run the collection module and which do not, and any gap should have a documented reason. Export the configuration with each audit cycle and note its version.

Inventory updated on patch announcement

ENISA lists an inventory updated when a new security patch is announced as evidence for patch management under point 6.6. Keep a record that links each vendor advisory to the affected inventory entries, the date the list was checked, and the resulting patch decision. Confirm that the process still works when a patch affects software that discovery tools report under a different product name, because a mismatch leaves an affected asset unpatched without anyone noticing.

What keeping an asset inventory costs

This table breaks the cost of a point 12.4 asset inventory into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Read the license row first, because self-hosted open source removes that spend, then check the recurring rows, which usually decide the total effort over time.

Cost component	One-time or recurring	What drives it up or down
Tooling or licenses	Recurring where proprietary; GLPI and Wazuh are open source with no license fee	Self-hosted GLPI (GPL-3.0-or-later) and Wazuh (GPL-2.0-only) remove license spend; confirm hosting, storage and support needs with each vendor and your own environment
Engineering time for discovery and integration	One-time, with later rework when new asset types appear	Number of asset sources, network segments, cloud accounts and OT devices; agent deployment method; quality of existing CMDB data
Owner time for reviews	Recurring	Number of named asset owners, how often reviews run, and whether owners can confirm entries through a tool instead of by email
Change history and evidence upkeep	Recurring	Frequency of asset changes, whether the tool records change history automatically, and how often inventory exports are archived as evidence
Classification and patch linkage	One-time setup, recurring upkeep	Number of assets needing a confidentiality, integrity, authenticity and availability level under point 12.1; how fast new patch announcements are matched to affected entries
External review and assessor sampling	Recurring at each assessment cycle	Scope of the assessment, number of entries an assessor samples, and whether the change log can be produced without manual reconstruction
Implementation partner support	One-time for fixed-scope work, optional recurring retainer	Written scope, number of sites and platforms, and whether knowledge transfer to internal staff is included; request a quote built from that scope

GLPI or Wazuh Syscollector for NIS2 asset inventory evidence

GLPI is an IT service management platform. Its Assets module works as a configuration register: it holds computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be created and edited by staff, or populated automatically by the GLPI Agent, which uses the native inventory built into GLPI since version 10. The project is licensed under GPL-3.0-or-later.

Manual and automated entry: Staff can record assets that cannot run an agent, such as racks, cabling or physical devices, while the GLPI Agent fills in hardware and software details for supported endpoints.
Ownership and lifecycle fields: Assets can carry location, owner, status and linked tickets, which helps show who is responsible for each entry.
Change history: Edits to asset records can be traced in the platform, which supports the traceable change requirement in point 12.4.3 once you confirm how history is retained and exported.
Classification fields: You can attach your point 12.1 classification to each asset as a custom field or linked attribute, so the inventory and classification stay in one place.
Inventory configuration: The agent configuration and inventory task settings are evidence in their own right, so document them.

Confirm that GLPI covers your network devices, cloud resources and operational technology, since agent support differs by asset type.

Where asset inventories fail the assessor

Most inventories that fail review are not missing entirely. They are incomplete in predictable places, undated, or never checked against what is actually running. Each card below names one gap, why it matters for point 12.4, and a concrete way to close it.

Cloud and container resources missing

Virtual machines, managed databases, Kubernetes clusters, container images and serverless functions often get created by teams outside the change process and never reach the register. Point 12.4 expects the inventory to cover the network and information systems that support each service, so an entry-level gap here undermines everything downstream. Close it by pulling resource lists directly from each cloud account and cluster on a schedule, then reconciling the result against the register. Ask who can create resources without a ticket and whether those paths feed the inventory.

No traceable change history

An entry that shows only its current state cannot demonstrate what changed, when, or who approved it. Point 12.4.3 requires the entity to document the history of changes to entries, and ENISA's June 2025 guidance lists an up-to-date inventory with change history as evidence. Store every edit with a timestamp, the actor and the reason, or keep the register in version-controlled storage. Test it by picking an asset retired last year and tracing its full record.

Classifications absent from entries

Entries that list hostnames and owners but no classification leave the assessor unable to see how confidentiality, integrity, authenticity and availability requirements were applied. Point 12.1 requires a classification level for every asset, and availability should align with the recovery objectives set for business continuity. Add classification as a required field that cannot be left blank, and check that the recovery objective on each high-availability system matches the backup plan.

Unowned assets

An asset without a named owner has no one to approve patches, confirm its configuration or decide whether it can be retired. Orphaned virtual machines and legacy appliances are common in this group, and they tend to be the systems that miss security updates. Require an accountable owner for every entry, assign ownership of orphans during each review, and flag any entry whose owner has left the organization.

Inventory not reconciled with discovery

A register maintained by hand drifts away from the network. Discovery tools such as endpoint agents and network scans reveal devices and software the register does not show, and the gap between the two is itself a finding. Schedule a reconciliation that compares scanner or agent output with the register, records each difference, and assigns a disposition to every unmatched item. The Wazuh Syscollector module and GLPI native inventory can both feed this comparison, but confirm coverage on your own endpoints before relying on either.

Reviews that never happen

Point 12.4.3 requires regular review and update of both the inventory and the assets it lists. Many programs write a review procedure and then skip it, so the register looks current on paper but is months out of date in practice. Set a review cadence in the policy, record each review with its date, reviewer and outcome, and keep the record as evidence. Ask for the last three review records during an internal check, since missing ones are easy for an assessor to spot.

Who does what: your team, a partner and the auditor

Your organization owns the asset inventory and remains accountable for every entry in it. Under point 12.4 the inventory must list your operations, services, network and information systems and other supporting assets at a granularity that fits your entity, and it must stay complete, accurate, up to date and consistent. Nobody outside your organization can decide what counts as a business service or who is accountable for a system, so these decisions stay internal.

Scope decisions: Decide which operations and services are in the inventory and at what level of detail, and record the rationale.
Classification input: Supply the confidentiality, integrity, authenticity and availability requirements that feed the classification under point 12.1, including recovery objectives from business continuity.
Ownership and review: Name an accountable owner for each asset and set the review cycle, including reviews triggered by new security patches.
Change discipline: Route onboarding, decommissioning and configuration changes through a process that records each change in the inventory.
Quarterly-style checks: Reconcile the inventory against cloud accounts, network scans and procurement records to find gaps.

Before accepting any partner's work, confirm that your own staff can explain each inventory entry and the history of its changes.

Common questions about the NIS2 asset inventory

What drives the cost of building a NIS2 asset inventory?

The cost is driven mainly by how many systems, sites and services you run, how scattered their records are today, and how much discovery work is needed before anyone can trust a list. Point 12.4 asks for an inventory of operations, services and the systems that support them, at a granularity suited to your entity, so a small estate with clean records is far cheaper to document than a multi-site group with shadow IT and several cloud accounts. Costs fall into three parts: internal staff time for owners to confirm their assets, licensing or hosting for any tooling, and any external help you buy to run discovery and set up the process. Ask any quote to separate one-time discovery and setup from recurring review, agent maintenance and reporting, and to state which assumptions about system count and sites it relies on.

How long does it take to build the first asset inventory?

The first inventory usually takes longer than any later update, because it involves discovery, owner confirmation and classification together. The duration depends on the number of sites, the state of existing configuration management databases and spreadsheets, and how quickly system owners respond. Point 12.1 also requires each asset to carry a classification based on confidentiality, integrity, authenticity and availability, and availability must reflect business continuity recovery objectives, so the work cannot stop at a list of hostnames. Ask any provider to commit to a written timeline tied to a defined scope and to name the milestones at which owners sign off their entries. No duration is set by the regulation itself, so treat any published estimate as something to verify against your own environment.

What does the internal team need to provide for the inventory?

The inventory cannot be built by an outside team alone, because only your staff know which business services depend on which systems and who owns each one. You will need named owners for operations and services, system administrators who can confirm hardware, software and network details, and a business or risk representative who can set the availability requirements that feed classification. Management must approve the scope and accept the inventory as an accountable record. Outside help can run discovery, configure tooling, draft the process and prepare evidence, but the organization keeps ownership of the entries and the decisions behind them. Confirm these roles in writing before work starts so that accountability does not fall between teams.

Can we build a NIS2 asset inventory in-house with open-source tools?

Yes, a self-hosted inventory can be built in-house with open-source tools, provided the team has the time, skills and discipline to keep it current. GLPI's Assets module can hold computers, monitors, software, network equipment, peripherals, printers, phones and racks, with entries made manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint, and stores them for inventory views and reports. Tools do not replace the process: you still need owner confirmation, classification, a documented change history and a configured record of how the tool was set up, which ENISA's June 2025 guidance lists as evidence. Confirm that each tool covers your asset types, including OT and cloud resources, before you rely on it.

How should cloud assets be handled in a NIS2 inventory?

Cloud assets belong in the inventory when they support your operations or services, even though no one physically owns the hardware. Virtual machines, containers, managed databases, storage buckets, identity configurations and network components should be recorded with their account or subscription, region, owner and classification, and the record should show when they were created, changed or retired. Endpoint agents such as Wazuh's Syscollector only see systems where they are installed, so cloud resources usually need a separate source, such as the provider's own inventory or infrastructure-as-code state, reconciled into the same record. Ask any provider how it will detect resources created outside the normal pipeline, because those are the assets most likely to be missing from the list.

How often must the asset inventory be reviewed and updated?

Point 12.4.3 requires entities to review and update the inventory and their assets regularly and to document the history of changes, so the inventory must be treated as a living record rather than a one-time deliverable. The review frequency is not fixed by the regulation, so set it in your own risk assessment and procedures and justify it to your supervisor. Practical triggers include new systems going live, decommissioning, a new security patch announcement that affects listed assets (ENISA's guidance cites an inventory updated when a patch is announced as evidence), and changes to owners or classification. Ask your provider how the inventory is reconciled with discovery data, how changes are logged, and what recurring review tasks are included in any retainer.

How DeployOpen scopes and prepares the asset inventory

DeployOpen plans, builds and documents an asset inventory for self-hosted open-source platforms inside your own infrastructure, so the inventory covers the operations, services and systems that point 12.4 requires. Your organization owns the inventory and its classification decisions, and we prepare the system and the evidence that an independent assessor or the competent authority can review.

How we scope

We agree in writing which operations, services, networks and asset types the inventory covers before work starts.
The scope names the discovery sources, such as endpoints, network devices and cloud accounts, and who owns each source.
We confirm the granularity your organization needs, and record which asset data fields are required for each asset class.

How we build

We configure GLPI Assets for manual and agent-based records, and Wazuh Syscollector for endpoint hardware, software and open ports where in scope.
We set up the change history so every edit to an inventory entry is recorded in a traceable way.
We link each asset to a classification level and a recovery objective, so logging and patching can rely on the inventory.

How we hand over

We document the inventory procedure, the review cadence, the owners of each record and the configuration of each tool.
We deliver sample exports and the change log so your team can show an inventory that is current, complete and consistent.
We hand over the inventory metrics and the configuration files used, so reviewers can trace how the records were produced.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which keeps the inventory current as systems change.
We can review the inventory against each patch cycle, so newly announced security patches map to the affected assets.
Your organization decides whether to engage an independent auditor or assessor, and we support their evidence requests without issuing any report.