A common mistake is treating inventories as a one-time project rather than a living control. Teams also miss remote sites, network resources, hardware, and third-party interconnections, or they update records too slowly after major changes. Manual processes are especially prone to drift, which is why continuous review and automation matter for accuracy and auditability.
What DORA Actually Expects from an ICT Inventory
DORA treats an ICT inventory as evidence that an organisation can see its operational dependencies, not as a static spreadsheet to satisfy an audit request. The inventory has to support resilience, impact analysis, and control oversight, so it needs to reflect systems, locations, network resources, suppliers, and interconnections with enough accuracy to guide decisions. The official EU Digital Operational Resilience Act (DORA) makes that governance expectation clear.
Teams often get this wrong by defining “asset inventory” too narrowly, then discovering that the items most relevant to service continuity sit outside the original scope. Remote infrastructure, third-party links, and supporting hardware are easy to miss because they are not always owned by the same team as the application. That creates a false sense of control: the register exists, but it does not yet tell the business what depends on what. In practice, many compliance failures begin when organisations can name their systems but cannot explain their operational relationships.
How Inventory Drift Happens in Live Operations
The practical challenge is that ICT inventories fail gradually. Change records, CMDB entries, cloud resources, and supplier records rarely move at the same speed, so the inventory becomes a lagging view of the environment unless there is a disciplined update process. The result is not only incomplete records but also weak traceability between an asset and the service, owner, control set, or recovery plan that depends on it.
For DORA purposes, the inventory needs to be useful across several operational questions: what exists, where it is, who owns it, what it connects to, and what business service it supports. A strong inventory therefore needs to cover both technical and governance attributes. At minimum, teams should be able to identify:
- hardware, software, and cloud resources that support ICT services
- remote sites and edge locations that affect continuity or recovery
- third-party and intra-group interconnections that expand the dependency map
- service ownership and lifecycle status, including decommissioned or shadow assets
- change events that require inventory updates before the next review cycle
This is where manual tracking usually breaks down. Manual processes struggle to keep pace with provisioning, patching, migrations, and supplier changes, especially when responsibility is split across infrastructure, application, risk, and procurement teams. Automation helps, but only if the tooling is tied to authoritative sources and there is a clear rule for when an item becomes inventory-visible. The most reliable inventories are not the biggest ones; they are the ones that can be reconciled, explained, and acted on. Where inventories feed resilience testing, incident response, or dependency mapping, stale records can mislead the business about what will fail first.
For readers comparing DORA with broader control models, the NIST Cybersecurity Framework 2.0 is useful because it frames inventory as part of broader governance and risk visibility, while DORA is more explicit about operational resilience outcomes.
Where organisations usually fall short is in treating inventory quality as a one-off clean-up rather than a control that depends on change management, ownership, and reconciliation. Once the environment becomes multi-cloud, outsourced, or highly dynamic, the inventory only stays trustworthy if it is continuously refreshed from the systems that actually change the estate.
Where the Edge Cases Break the Simple Answer
Tighter inventory governance often increases operational overhead, so organisations have to balance completeness against the cost of maintaining high-quality records across fast-changing environments.
Some edge cases are easy to underestimate. Shared platforms, ephemeral cloud resources, temporary supplier connections, and geographically dispersed infrastructure can all be operationally important even when they do not look like “core assets” in a traditional register. The compliance question is not whether every item is neatly classified, but whether the inventory is sufficiently complete to support resilience decisions and audit evidence. That is why there is no useful consensus on a purely manual approach for modern environments: the more dynamic the estate, the less credible a static inventory becomes.
Another common trap is over-indexing on software assets while ignoring supporting infrastructure and relationships. DORA inventory expectations are broader than application cataloguing, so a register that omits network components, hosting dependencies, or supplier connections may still look organised while failing the real test. Teams should also be careful not to confuse ownership with visibility. An item can be owned by one team, maintained by another, and depended on by several business services; if those links are missing, the inventory may pass a document check but fail an operational one.
Practitioner Guidance: Focus first on the inventory fields that determine recovery and dependency visibility: ownership, location, service linkage, supplier linkage, and change recency. If those fields are unreliable, any broader assurance claim is premature.
Practitioner Guidance: Treat reconciliation as the real control, not data entry. The useful question is whether the inventory can be matched against source systems, change events, and service maps without material gaps.
Practitioner takeaway: A DORA inventory is only credible when it behaves like a living control that can withstand change, not when it merely documents what the organisation once believed to be true.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while DORA and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT-asset and third-party dependency management — ICT Asset and Dependency Oversight | The question is directly about DORA-compliant ICT inventory practice. |
| Recommendation — Maintain a continuously reconciled ICT inventory that captures assets, dependencies, and ownership. | ||
| NIST CSF 2.0 | ID.AM-01 — Inventory of Assets | Asset inventory discipline directly addresses drift, scope gaps, and visibility. |
| Recommendation — Keep an authoritative asset inventory and reconcile it against actual environment changes. | ||
| CIS Controls v8 | 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory | Inventory completeness and ongoing maintenance are the core control issues here. |
| Recommendation — Build and continuously maintain a detailed enterprise asset inventory with ownership and lifecycle status. | ||
| ISO/IEC 42001:2023 | Organisational AI governance | Not directly relevant to an ICT inventory compliance question. |
| Recommendation — N/A | ||
