Key takeaway: Article 21 references asset management almost in passing, but every other measure depends on it. Without a maintained inventory of the assets that support the entity's essential or important services, risk analysis is speculation, incident handling is improvisation, business continuity is wishful thinking, and supply chain security is a spreadsheet of suppliers with no context. Most NIS2 programmes skip this step because it feels too basic. That is exactly why it produces findings.
Ask a security leader where they keep their critical asset inventory, and you will hear one of three answers. "In the CMDB." "In a spreadsheet somewhere." "We are working on it." All three of those answers tend to fail under supervision, because the inventory that satisfies NIS2 is not an IT catalogue. It is a business-aligned list of what matters to the service, with a clear link from each asset to the service it supports and the owner accountable for it.
This piece walks through how to scope the inventory, what to include, what to leave out, and how to keep it current. It finishes with a template that is simple enough to start filling in today.
Why the inventory is the first real step
NIS2 starts with scoping: are you in? Then with classification: essential or important? After those two, the directive gets operational quickly. Article 21 requires risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, training, cryptography, access control and asset management, and MFA. Six of those ten measures cannot be properly executed without a working inventory.
- Risk analysis. A risk register without named assets is a wishlist. Risks must attach to something the entity owns or relies on.
- Incident handling. When an incident hits, the inventory is what tells the responder which systems support the affected service and who owns them.
- Business continuity. A business impact analysis needs an asset inventory to tie recovery objectives to the actual systems that must come back online.
- Supply chain security. The supplier register is a sister list to the asset inventory. Each critical supplier should map to the assets or services they support.
- Access control. Access reviews rely on knowing which resources are in scope. Unmapped systems end up unmanaged.
- Cryptography. The cryptographic inventory required by Article 21(2)(h) is a specific slice of the general asset inventory.
How to scope the inventory without getting lost
The trap in asset inventory work is universe size. An enterprise has tens of thousands of endpoints, hundreds of applications, dozens of cloud accounts, and thousands of suppliers. Trying to list all of them at the same depth produces a project that never finishes. The NIS2-aligned approach narrows the field in a predictable order.
Step 1: list the essential and important services
Start at the top. What are the services in scope under NIS2? For a hospital, this is usually clinical care plus supporting digital systems. For a cloud provider, this is the specific service for which they are regulated. For a manufacturer, this might be industrial control of production lines. Most entities have fewer than 10 services in scope. Write them down first.
Step 2: list the systems that support each service
For each service, list the applications and systems that support it, at the business-application level. Not every server, not every container. This usually yields 20 to 200 entries for a typical in-scope entity. Each entry has a name, a business owner, a technical owner, and a primary service linkage.
Step 3: expand into data, identity, and third parties
For each system, capture the sensitive data categories it processes, the identity provider that controls access to it, and the third-party services it depends on (cloud provider, SaaS vendor, managed service). This produces the dependency graph that drives the rest of Article 21.
Step 4: reconcile with discovery tooling
Now use your CMDB, EDR, cloud inventory, and SaaS discovery tools to find hardware, software, and services that do not map to any row in the inventory. Each unmapped asset is either added (with a service link) or retired. The reconciliation finds shadow IT, orphaned systems, and forgotten test environments that are common sources of incidents.
Start top-down, not bottom-up: The programmes that succeed start from the services and work down. The ones that get stuck start by exporting the CMDB and trying to categorise 20,000 rows. The top-down approach usually produces a usable first version in four to six weeks. Bottom-up projects rarely produce anything usable.
What each inventory row should contain
A minimum set of fields that will satisfy supervision and support the rest of the Article 21 programme. More fields are useful, but these are the load-bearing ones.
Minimum fields for the critical asset inventory
- Asset ID. A stable internal identifier, ideally one that survives renames and tooling changes.
- Name and short description. What the asset is, in plain language.
- Category. One of: application, infrastructure, data, identity service, cloud service, third-party service, operational technology.
- Supports service(s). The essential or important service(s) this asset supports. One to many.
- Business owner. The named person in the business accountable for the asset's role.
- Technical owner. The named person in IT or security accountable for operating it.
- Criticality tier. A simple three-tier scale (tier 1 mission-critical, tier 2 important, tier 3 standard) applied consistently.
- Data classification. The highest classification of data the asset processes.
- Hosting. On-premises, named cloud provider, or third-party SaaS.
- Key dependencies. Other asset IDs, suppliers, or shared services this asset depends on.
- Recovery objectives. RTO and RPO, at least for tier 1 and tier 2 assets.
- Last review date. When the entry was last verified, and by whom.
What to leave out
An inventory that tries to be everything loses its usefulness. Three categories are worth deliberately leaving out of the critical asset inventory and managing in their own registers or tooling.
- Individual endpoints. Laptops and workstations belong in the endpoint management system and the EDR console. Including them in the critical inventory creates noise without adding signal. Track them in aggregate.
- Office-productivity peripherals. Printers, meeting room systems, and similar equipment are managed elsewhere. Only include them if they sit in a network path that matters for a tier 1 service.
- Non-production environments below tier 2. Test and development systems often have lower security. They belong in a separate register flagged for segmentation review, rather than in the critical inventory itself.
Keeping the inventory current
The inventory that ships with a NIS2 programme kickoff is rarely the inventory that is current a year later. Three mechanisms keep it honest.
- Annual owner attestation. Business and technical owners confirm or update their entries once a year. An attestation campaign produces documented review dates, which supervisors look for.
- Event-triggered update. New procurement, major releases, decommissioning, and supplier changes must flow into the inventory. A change-control gate that requires an inventory update before deployment is the simplest way to enforce this.
- Monthly reconciliation. Automated comparison of the inventory against discovery tooling (cloud APIs, SaaS discovery, network scans) flags drift. Drift that is not resolved becomes an audit finding.
A starter template you can copy
The fastest way to start is a single spreadsheet with the 12 fields above. Do not pick a tool yet. A working spreadsheet with 50 genuine rows is more valuable than a perfect CMDB with zero rows. Tooling can come later, once the data model has been tested against real questions.
A practical week-one pattern: sit with the CIO or CISO for two hours. List the essential and important services. For each service, sketch the top 10 systems that support it. Assign a business and technical owner to each row. That output is already more than most organisations can produce under supervision. Weeks two to four expand, reconcile, and refine.
Frequently asked questions
Does NIS2 explicitly require an asset inventory?
Yes, indirectly. Article 21(2)(i) lists asset management as a required measure. Risk analysis, incident handling, business continuity, and supply chain management all depend on a working inventory of the assets in scope. Supervisors ask for it on day one of an inspection.
What counts as a critical asset under NIS2?
Any asset whose loss, compromise, or unavailability would materially affect delivery of the entity's essential or important services. This includes hardware, software, data, cloud resources, identities, and third-party services that support those services. Non-IT assets such as SCADA devices and physical facilities can also qualify.
How granular should the NIS2 asset inventory be?
Granular enough that each entry has a named owner, a classification, and a clear link to the service it supports. A row per workstation is usually too granular; a row per business service is usually too coarse. The system or application level is the practical unit for most entities.
How often should the NIS2 asset inventory be reviewed?
At minimum annually, with event-triggered updates for major procurement, decommissioning, mergers, and new supplier onboarding. Monthly reconciliation against discovery tooling is good practice for the hardware and software layers. Each review cycle needs a dated sign-off from the asset owner to stand up under inspection.
Do we need a dedicated tool for the NIS2 asset inventory?
No, not initially. A maintained spreadsheet with the right columns and clear ownership beats an empty CMDB. Tool selection is easier once the data model has been tested against real risk and incident questions for a few months. What supervisors check is accuracy and ownership, not the software used.
Who should own the NIS2 asset inventory inside the organisation?
A single named role, usually the CISO or head of IT risk, owns the master inventory. Each row has a named business owner accountable for the service the asset supports, and a technical owner accountable for operation. This dual-ownership model is what auditors look for on sample rows.
Does the NIS2 asset inventory need to include suppliers and cloud services?
Yes. Article 21(2)(d) on supply chain security means the inventory must flag each asset's dependencies on suppliers, managed service providers, and cloud platforms. A SaaS platform supporting an essential service is in scope even though the entity does not operate it directly. Without this, supply chain risk analysis has no foundation.
Want a critical asset inventory in four weeks, not four quarters?
We help in-scope organisations build a service-aligned inventory that feeds risk analysis, incident handling, and supply chain mapping. Starter template, workshop-led scoping, owner attestation process, and reconciliation with your existing tooling.
Book an inventory workshop