NIS2 Asset Management in Practice: Build Your CIR Annex 12 Inventory in 5 Steps

Last verified: May 2026. This guide covers NIS2 Article 21(2)(i) and Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex Section 12. It does not constitute legal advice — consult a qualified practitioner for organisation-specific guidance.

Asset management failures are rarely dramatic. They are quiet — an unpatched server that nobody knew existed, a cloud storage bucket provisioned by a developer three years ago, a contractor account that was never closed after the project ended. These gaps do not announce themselves until an incident occurs or a supervisory authority walks in with a checklist.

Commission Implementing Regulation (EU) 2024/2690 (the CIR) makes asset management a structural prerequisite, not an optional baseline. Annex Section 12 specifies five distinct obligations: classification, handling, removable media, inventory, and termination procedures. Every downstream control — access rights reviews, incident response, backup scoping, risk assessments — assumes a reliable inventory as its foundation. Without it, those controls rest on an unknown surface area.

This guide walks through all five CIR Annex 12 sub-sections, presents a four-tier asset classification method mapped to NIS2 proportionality, and provides a step-by-step implementation workflow including shadow IT discovery and the evidence auditors will request.

Who Must Comply? Article 21(2)(i) Scope

Article 21(2)(i) of Directive (EU) 2022/2555 requires all essential and important entities to implement measures covering “human resources security, access control policies and asset management.” The CIR translates this obligation into binding technical requirements for specific entity types:

Entity Type	CIR 2024/2690 Applies Directly?	Benchmark
DNS service providers, TLD registries	Yes	CIR Annex 12 binding
Cloud computing, data centre, CDN providers	Yes	CIR Annex 12 binding
Managed service / security providers (MSP/MSSP)	Yes	CIR Annex 12 binding
Online marketplaces, search engines, social platforms	Yes	CIR Annex 12 binding
Trust service providers	Yes	CIR Annex 12 binding
Other essential entities (energy, health, transport, water, finance)	No — national transposition	CIR Annex 12 as best-practice benchmark
Important entities (manufacturing, waste, chemicals, food, postal)	No — national transposition	CIR Annex 12 as best-practice benchmark
Micro-enterprises (<10 employees, <€2m turnover)	Check national NCA guidance	Proportionality may reduce scope

For entities not directly covered by the CIR, ENISA’s Technical Implementation Guidance (June 2025) treats Annex 12 as the reference standard across all NIS2 entities. Supervisory authorities in multiple member states use it as their inspection benchmark regardless of whether the CIR binds an entity directly.

The full picture of all ten Article 21 obligations is in the NIS2 requirements guide. This article focuses on the asset management dimension of Measure 9.

What CIR Annex 12 Actually Requires

Annex Section 12 contains five sub-sections. They are not independent — inventory (12.4) cannot be meaningful without classification (12.1), and termination procedures (12.5) depend on both. The table below maps each sub-section to its core obligation and the primary template that addresses it.

Sub-section	Obligation	Key “shall”	Template
12.1 Asset classification	Define classification levels for all in-scope assets	Associate all assets with a level based on CIA + availability; align availability to BC/DR recovery objectives	Template 16 — Information Classification Policy
12.2 Asset handling	Policy for safe use, storage, transport, and disposal across the full lifecycle	Cover acquisition, use, storage, transportation, and irretrievable deletion/destruction	Template 17 — Asset Management Procedure
12.3 Removable media	Technical and procedural controls for removable storage devices	Technically prohibit unauthorised media; scan before use; encrypt where appropriate	Templates 13 + 17
12.4 Asset inventory	Complete, accurate, up-to-date, consistent inventory with traceable change records	Include operations/services list and network/IS asset list; record changes traceably	Template 18 — IT Asset Register (XLSX)
12.5 Termination procedures	Assets returned, deposited, or deleted when employment ends	Document deposit/return/deletion; or ensure assets cannot access network/IS systems	Templates 17 + 33 HR Security

The proportionality principle in CIR Recital 4 applies here: inventory granularity should be “appropriate for entity needs” (CIR 12.4.2). A 50-person professional services firm does not need enterprise CMDB depth. The test is whether your inventory is sufficient to support your risk assessment and demonstrate appropriate controls per classification tier.

The 5 Asset Domains Your Inventory Must Cover

CIR 12.4.2 specifies that the inventory must include (a) a list of operations and services with descriptions, and (b) a list of network and information systems and associated assets supporting those operations. In practice, this translates to five asset domains.

1. Hardware assets
Physical devices: servers, workstations, laptops, network appliances (routers, switches, firewalls, access points), mobile devices, printers, and storage arrays. For manufacturing, energy, and transport entities, operational technology (OT) assets — PLCs, RTUs, SCADA systems, industrial control systems — belong here. Most organisations discover 20–30% more devices than their IT team believed existed when they run a first comprehensive network scan. Those unknown devices are the compliance gap.

2. Software assets
Operating systems, enterprise applications, SaaS subscriptions, open-source libraries, developer tools, and firmware versions. The software inventory directly supports CIR Section 6.1 (ICT acquisition security) and Section 6.6 (patch management). A gap in the software register creates cascading compliance failures across multiple CIR sections — you cannot patch what you do not know you have.

3. Network and information systems
The CIR uses “network and information systems” as a distinct category. This includes documented network architecture — CIR 6.7.2(a) separately requires that network documentation be “comprehensible and up-to-date.” Segmentation diagrams, data flow maps, and interconnection records are not optional supporting documents; they are independently required and feed into the asset inventory as system-level entries.

4. Cloud and virtual assets
Cloud infrastructure (IaaS, PaaS) and SaaS applications are assets under NIS2 regardless of whether your organisation owns the underlying hardware. Cloud asset tracking must capture: provider name, service type, data classification of processed data, contractual security obligations, and shared responsibility demarcation. This is where most compliance gaps emerge — teams that manage cloud costs often operate outside the ITSM system feeding the central asset inventory.

5. Data assets
Registers of sensitive data repositories, databases, backup stores, and data processing locations. Asset classification under 12.1 applies to data assets as much as hardware: a database containing healthcare records requires different controls from an internal project wiki. Backup scoping under CIR Section 4.2 references the asset inventory to determine which data assets require protection and at what recovery tier.

4-Tier Asset Classification: Mapping to NIS2 Proportionality

CIR 12.1.2 requires that all assets be associated with a classification level indicating “protection per sensitivity, criticality, risk and business value.” The following four-tier framework maps directly to NIS2’s risk management structure and drives downstream control decisions.

Tier	Definition	Examples	Access Control (CIR 11)	Logging (CIR 3.2)
1 — Critical	Failure or compromise directly disrupts essential services or triggers NIS2 significant incident notification	Production SCADA, authentication servers, core routing, primary backup systems	MFA mandatory (CIR 11.7), privileged account separation (CIR 11.3), network isolation (CIR 6.8.2(c))	Continuous or high-frequency automated monitoring (CIR 3.2.2)
2 — Important	Failure significantly degrades — but does not immediately halt — essential service delivery	Secondary business applications, internal communication platforms, development environments with production data	RBAC with quarterly access review; MFA for remote access	Standard SIEM ingestion, alert thresholds defined
3 — Standard	Supports operational efficiency; not directly linked to essential service delivery	Productivity tools, internal portals, non-production test systems	Role-based access, annual access review	Log retention per defined period; no real-time alerting required
4 — Non-critical	No significant security impact if compromised	Standalone presentation machines, decommissioned assets awaiting disposal, training devices	Basic physical security and controlled disposal	Basic endpoint logging only

A practical shortcut for initial classification: map assets to the operations and services list first (CIR 12.4.2(a)), then inherit classification from the criticality of the service the asset supports. A standard workstation becomes Tier 2 if it is the only device with access to a Tier 1 system’s admin interface. Classification must reflect the dependency chain, not just the device type in isolation. Document the justification for each classification decision — CIR 12.1.2(b) requires this explicitly.

CIR 12.1.3 requires periodic reviews of classification levels. Mark each asset record with a next-review date. Classification drift — assets changing function without classification update — is the most common finding when an inventory exists but is not actively maintained.

5-Step Implementation Workflow

Step 1: Discovery — Find Everything, Including What IT Doesn’t Know About

Start with network scanning before updating spreadsheets. Passive scanning (monitoring network traffic without active probing) discovers assets that active scanning misses, particularly OT devices and legacy systems that do not tolerate scanning traffic. Run both: passive scanning covers the breadth, active scanning confirms configuration detail.

Shadow IT requires a separate discovery track because it does not appear in network scans. Shadow IT — technology acquired or deployed by business units without central IT involvement — is the most common source of inventory gaps. It does not imply malicious intent: the marketing team’s Dropbox subscription or the developer’s personal AWS account are typical examples. Four practical methods:

1. DNS query analysis: Your firewall or DNS resolver logs will show requests to cloud storage, collaboration, and SaaS providers. A weekly review of new domains contacted identifies services in active use outside the approved list.
2. Expense and procurement audit: Filter company card records and expense reports for software subscriptions, cloud provider invoices, and tool purchases. Cross-reference against approved procurement.
3. Endpoint management survey: Endpoint management tools can identify installed browser extensions and local software connected to external services.
4. Quarterly department survey: A five-question form asking team leads to list tools their team uses outside central IT catches the remainder. Keep it simple — compliance requires the information, not a lengthy process.

CIR 12.4.1 requires that changes to the inventory be recorded “in a traceable manner.” Your discovery process must produce timestamped records, not just an updated spreadsheet. Any asset that appears or disappears requires an audit trail: who discovered it, when, and what action was taken.

Step 2: Classify Using the 4-Tier Method

Apply the Critical/Important/Standard/Non-critical framework above. For each asset, document: the assigned tier, the justification based on CIA and availability requirements (CIR 12.1.2(b)), the operation or service it supports, and the named owner. Do not classify devices in isolation — a single asset’s tier may rise because of its dependency relationship with a Critical service. Classification decisions drive which authentication controls, logging levels, and review frequencies apply under the rest of the CIR. Getting classification right is more important than completing it fast.

Step 3: Assign Named Owners

Every asset must have a named individual owner — not a team, not a department. The owner is accountable for keeping the asset’s classification current, approving access changes, and ensuring the asset is handled per the asset handling policy (CIR 12.2). Shadow assets without individual owners are the primary NIS2 audit failure point: during an inspection, “the cloud storage account is owned by the marketing team” is not an acceptable answer. Auditors expect a person’s name and evidence that the person actively manages the asset’s access and classification.

Step 4: Map Controls to Classification Tier

For each asset, document which controls apply based on its tier. CIR 12.1.2(b) requires indicating “protection per sensitivity, criticality, risk and business value.” Your access control framework (CIR Section 11) and logging requirements (CIR Section 3.2) both reference asset classification. A simple mapping column in Template 18 (IT Asset Register) is sufficient: tier → applicable policies → assigned controls → review date. Without this linkage, downstream controls cannot be verified during audit because the connection between asset risk and applied protection is not documented.

Step 5: Establish the Review Cycle

CIR 12.4.3 requires regular review with change history documented. CIR 12.1.3 requires periodic classification review. In practice, three review triggers apply:

• Annual review (minimum): Full inventory reconciliation, re-classification of changed assets, removal of decommissioned assets from active register, update of ownership records.
• Trigger-based review: Required after significant incidents, major operational changes, significant procurement events, and terminations (CIR 12.5 — asset return/deletion on departure).
• Continuous update: New assets must be registered before operational deployment. CIR 12.2.2(a) covers the full lifecycle from acquisition — an asset that goes live without a register entry is a CIR violation from day one of its operation.

The secure development and acquisition guide covers how CIR Section 6.1 links software asset registration to the ICT procurement process, ensuring new software assets enter the inventory at the point of approval rather than after deployment.

Shadow IT and Cloud Assets: Where Auditors Look First

Shadow IT constitutes the most reliable audit finding in asset management reviews because it is structurally invisible to standard inventory processes. An unregistered SaaS application that processes operational data is a double exposure: it fails CIR 12.4 (absent from inventory), fails CIR 12.1 (unclassified), and may trigger parallel GDPR obligations if it processes personal data without a lawful basis registered in your data processing records.

The risk compounds during incidents. If a shadow IT asset is exploited as the initial access vector, it may not appear in your incident response plan, slowing containment and extending notification timelines. Under NIS2 Article 23’s 24-hour early warning obligation, every hour of delayed identification costs compliance exposure.

Cloud asset tracking requires specific procedural controls beyond general IT asset management. For each cloud service in scope, the inventory record should capture:

• Provider and service type (IaaS/PaaS/SaaS)
• Data classification of information processed or stored
• Shared responsibility boundary — which security controls the provider manages vs. your organisation’s responsibility
• Contractual security obligations from the MSA or DPA — relevant to CIR Section 5 (supply chain security) as well as Section 12
• Named owner in your organisation accountable for configuration and access reviews
• Last access review date and next scheduled review

Once discovered, shadow IT assets require a formal decision: bring into register and apply appropriate controls, or formally decommission and document the decision with justification. Both outcomes are compliant. The only non-compliant outcome is continued operation outside the register.

Evidence Checklist: What Auditors Will Request

When a national competent authority or third-party auditor reviews your CIR Section 12 compliance, these are the specific evidence items they will request. Paper-based registers are insufficient for demonstrating “traceable” changes (CIR 12.4.1) — a register that cannot produce a version history or change log will fail this criterion regardless of its completeness.

Evidence Item	CIR Reference	Minimum Format
Complete asset inventory with tier classification	12.1, 12.4	Live register export filterable by tier, with date of last update
Named individual owners for all entries	12.2, 12.4	Dedicated owner column in asset register; names traceable to organisational records
Lifecycle records from acquisition to current state	12.2	Timestamped entries in ITSM or asset register; no gaps in chain
Current network architecture diagram	6.7.2(a)	Diagram file with creation/update date; separate from the inventory but cross-referenced
Classification review records	12.1.3	Review log with date, reviewer name, and outcome for each reviewed asset
Shadow IT discovery process documentation	12.4.1	Scan reports, DNS review logs, or survey records showing active discovery activity
Asset return/deletion records on termination	12.5	Off-boarding checklist entries with named approver and completion timestamp
Removable media policy and technical controls evidence	12.3	Policy document plus evidence of technical enforcement (endpoint management config logs)
Change log for inventory modifications	12.4.1	Version history or audit trail showing who changed what and when

Role Responsibilities for CIR Section 12 Compliance

Activity	CISO / IT Security	IT Operations	Compliance Officer	Department Head	HR
Approve classification policy	Own	Contribute	Review	—	—
Run discovery scans	Own	Execute	—	—	—
Shadow IT surveys	Design	Collate results	Track completion	Complete and submit	—
Assign asset owners	Oversee	Execute (IT assets)	Verify completeness	Own (dept. assets)	—
Annual inventory review	Oversee	Execute	Verify and report	Confirm dept. assets	—
Trigger review after incident	Own	Execute	Notify stakeholders	—	—
Asset return on termination	Verify completion	Execute revocation	—	—	Initiate process
Shadow IT remediation decisions	Decide	Execute	Track and close	Report findings	—

Frequently Asked Questions

Does CIR Annex 12 apply to all NIS2 entities or only CIR-scope entities?

CIR 2024/2690 applies directly to DNS providers, TLD registries, cloud computing services, CDN and data centre providers, MSPs, MSSPs, online platforms, and trust service providers. For other NIS2 entities, equivalent requirements flow through national law. ENISA’s Technical Implementation Guidance (June 2025) uses Annex 12 as the reference framework across all NIS2 entity types, and supervisory authorities treat it as the inspection benchmark regardless of direct CIR applicability.

How granular does the NIS2 asset inventory need to be?

CIR 12.4.2 states that inventory granularity “shall be appropriate for entity needs.” This is a proportionality qualifier. A 50-person important entity does not need enterprise CMDB depth. The standard: granularity sufficient to support your risk assessment and demonstrate appropriate controls per classification tier. For most organisations, individual device and application records with owner, classification, and control references is sufficient.

What counts as shadow IT under NIS2?

Shadow IT is any technology deployed by business units without central IT involvement. Under NIS2, any asset that supports your operations and is absent from the inventory constitutes a compliance gap regardless of how it was acquired. CIR 12.4 requires a “complete, accurate, up-to-date and consistent” inventory — completeness is the operative word. Shadow IT must be discovered, registered, classified, and brought under the same control framework as centrally managed assets.

Are cloud services in scope for the NIS2 asset inventory?

Yes. CIR 12.4.2(b) requires the inventory to cover “network and information systems and other associated assets” supporting your operations. SaaS, IaaS, and PaaS services are all in scope. The shared responsibility model does not remove the obligation — it changes which controls are your responsibility versus the provider’s, but the asset must still appear in your inventory with owner, classification, and applicable controls documented.

What happens when an auditor finds unregistered assets?

An unregistered asset that supports operations constitutes a failure of CIR 12.4 (completeness) and 12.1 (classification). Under NIS2 Articles 32 and 33, this supports enforcement action by the national competent authority. The practical risk is larger: unregistered assets are typically unpatched and unmonitored, making them likely initial access vectors in incidents.

For the full Article 21 compliance programme, see the NIS2 requirements overview. For the access control obligations that depend on asset classification, see the NIS2 access control guide. For how software asset registration connects to procurement security, see the secure development and acquisition guide.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Commission Implementing Regulation (EU) 2024/2690, Annex Section 12: Asset Management — EUR-Lex
2. Directive (EU) 2022/2555 (NIS2 Directive), Article 21 — EUR-Lex
3. ENISA Technical Implementation Guidance on NIS2 Cybersecurity Risk Management Measures, Version 1.0 — ENISA, June 2025
4. NIS 2 Asset Handling: Real-Time Mapping, ISO 27001 Controls, and Audit Evidence — ISMS.online