What a DORA ICT asset inventory must contain and who owns it
DORA requires a financial entity to identify, classify and document its ICT-supported business functions, roles and responsibilities, the information and ICT assets that support them, and the dependencies between them, as Article 8 sets out. The per-asset fields are then detailed by Article 4 of Delegated Regulation (EU) 2024/1774, which expects a record for each asset with a unique identifier, location, classification, owner, supported business functions, recovery time and recovery point objectives, external network exposure, interdependencies and supplier end-of-support dates. The organization owns this inventory. Its management body and risk owners are accountable for it, and an implementation partner can design the data model, load existing records and set up the update process, but cannot certify that the inventory is complete. Only the competent authority supervising the entity, or an independent auditor where one is engaged, assesses it. How deep the inventory must go depends on the entity's size, the complexity of its ICT estate and the criticality of the functions it supports, so confirm the expected level of detail with your supervisor or auditor before you scope the work.
Start by deciding who holds the pen on each field. Business owners should confirm which functions an asset supports and how critical those functions are. Engineering or platform teams should supply locations, configurations, interfaces and end-of-support dates. Third-party management should link each entry to the provider contracts and subcontracting chains behind it, which Article 8(5) requires for processes that depend on ICT third-party service providers. Write down the criticality criteria Article 5 of the same delegated regulation asks for, covering the ICT risk of the supported functions and the impact of losing confidentiality, integrity or availability, before anyone scores assets. Otherwise the inventory will reflect whatever each team happened to record. Legacy systems need their own flagged records, since the policy must support specific risk assessments for them in entities other than microenterprises.
Plan for the inventory to decay unless it is tied to change. Article 8(6) requires updates at regular intervals and after every major change, and the classification itself must be reviewed at least yearly under Article 8(1). Practical controls include making a completed inventory record a precondition for approving a new system or provider, reconciling the inventory against discovery data from network and cloud scans, and reporting gaps to the management body. An open-source CMDB such as GLPI can hold these records, with its Assets module and native inventory from the GLPI Agent, but the fields DORA requires, the dependency maps and the criticality logic must be configured deliberately. Confirm with the vendor which capabilities your version provides, and treat tooling as the place where evidence is stored, not as the control itself.
How business functions, dependencies and third-party processes get mapped
DORA's asset inventory is built from several linked maps rather than one list of servers and applications. Each card below covers one layer, from the business functions that depend on technology down to the provider interconnections that carry the most supervisory attention.
Classified business functions and roles
Article 8(1) asks you to identify, classify and document the ICT-supported business functions, the roles and responsibilities behind them, and the dependencies they rely on. Start here, because every asset record later points back to a function. Confirm that each function has a named owner, a classification and a documented review date. The classification must be revisited as needed and at least yearly, so record who performs that review and how changes are logged.
Information and ICT assets behind each function
For every classified function, list the information assets and ICT assets that support it, including applications, databases, middleware, endpoints and data stores. Map the supporting assets to the function, not the other way round, so that a retired system cannot silently stay in scope. Check that shadow tools and spreadsheets used for critical steps are either recorded or explicitly excluded with a reason.
Configuration, links and remote sites
Article 8(4) requires you to identify all information and ICT assets, including those on remote sites, to map the critical ones, and to record their configuration, links and interdependencies. Branch offices, home-based staff devices, edge hardware and assets in co-located racks are common gaps. Ask whether network diagrams, configuration baselines and interface lists are generated from the inventory or maintained separately, since separate documents drift quickly.
Processes that depend on ICT providers
Article 8(5) asks you to identify and document every process that depends on an ICT third-party service provider. This covers SaaS tools, managed hosting, outsourced monitoring and cloud services, and it includes processes where the provider is only one step among several. Record the provider, the process it supports and the data it touches. A process map is easier to audit when each step names the asset it runs on.
Interconnections with critical or important providers
Where a provider supports a critical or important function, Article 8(5) expects the interconnections with that provider to be documented. Map network paths, API connections, data flows, identity federation and shared administrative access. These links are where a provider failure or breach spreads into your estate, so they feed directly into continuity scenarios and exit planning. Confirm that each link has an owner who can answer for it during an incident.
Dependency records that stay current
Article 8(6) requires inventories to be updated periodically and after every major change, so the mapping is only as good as its update trigger. Tie updates to change management, onboarding of new providers and decommissioning, and check that the change ticket cannot close until the asset and dependency records reflect the change. Ask your platform partner or internal team to show a sample change and its inventory update.
How the inventory stays current after go-live
This sequence keeps the DORA asset inventory accurate after launch by tying classification reviews, change-driven updates, lifecycle checks and legacy records to named outputs that an assessor can sample.
Set the review calendar and triggers
The asset owner and the ICT risk function agree a recurring classification review, with a fixed yearly pass at minimum, and write down the events that force an earlier update. Article 8(1) sets the yearly floor, and the policy should list the triggers the entity considers material, such as a new provider, a new hosting location or a change to a critical function. The output is a review calendar and a trigger list approved under the ICT asset management policy. Confirm the exact cadence with your competent authority and your own risk appetite before you publish it.
Capture changes at the point of change
Each planned change to a system, service or hosting location is logged in the change process before it goes live, and the inventory record is updated as part of that change. Under Article 8(6), inventories must be updated after every major change, so the change ticket should link to the affected asset identifiers. The output is a change record that names the assets touched and shows the inventory update. If a change ticket cannot be linked to an asset, the process has a gap to fix.
Refresh discovered assets and remote sites
Automated discovery, where it is in place, is compared with the register to find assets that were deployed without a record, including equipment at remote sites and temporary environments. Article 8(4) requires all information and ICT assets to be identified, so discovery results should be reconciled monthly or on the schedule the entity sets. The output is a reconciliation report listing unregistered assets, retired assets and the owner assigned to each new entry. Confirm with your tooling vendor which discovery sources are supported in your environment before you rely on them.
Re-map dependencies and third-party links
The dependency map is refreshed so that configuration links, interdependencies and interconnections with ICT third-party providers match the current estate. Article 8(4) and Article 8(5) both apply here, particularly for providers that support critical or important functions. The output is an updated dependency map and a list of processes whose third-party dependencies have changed, which feeds the register of information and the provider risk review. Ask your provider for the contractual subcontracting chain, since that is often where the map goes stale.
Re-classify assets and recheck criticality
Classification is reviewed against the documented criticality criteria, which weigh the ICT risk of the business functions an asset supports and the impact of losing confidentiality, integrity or availability. Article 5 of Delegated Regulation (EU) 2024/1774 requires this procedure to be documented and followed. The output is a re-classified asset list with the rationale recorded for each change, and a sign-off by the named owner. Assets whose criticality rose should trigger a risk assessment before the next review date.
Monitor lifecycle and supplier end-of-support dates
Lifecycle monitoring covers every asset classified under Article 8(1), recording the end-of-support date reported by each supplier and the planned replacement or extension decision. The policy requires these dates to be held in the record, so a monthly or quarterly check against vendor notices is a practical control. The output is a lifecycle report showing assets approaching end of support, each with a decision owner and a documented plan. Confirm each supplier's published support policy directly, since dates change.
Maintain legacy system records
Legacy ICT systems need their own records, because the policy requires the data needed for specific risk assessments of legacy systems for entities other than microenterprises. Each legacy system is flagged, its known gaps and compensating controls are recorded, and its risk assessment is scheduled. The output is a legacy register linked to the risk assessment and to any retirement plan. Review this register at every classification cycle so that legacy systems do not drop out of view as the estate changes.
Evidence the cycle for review
The completed review cycle is closed by a short record that states what was reviewed, which changes were made, who approved them and which open items remain. This record is what an assessor or supervisor will sample when testing whether the inventory is kept current. The output is a dated review pack containing the calendar, change records, reconciliation report, re-classified list, lifecycle report and legacy register, retained under the entity's record-keeping rules.
Setting criticality criteria that hold up under review
Article 5 of Delegated Regulation (EU) 2024/1774 requires a documented ICT asset management procedure that sets out how you assess the criticality of information and ICT assets. The test is twofold: the ICT risk of the business functions each asset supports, and the impact of a loss of confidentiality, integrity or availability. An assessor will look for criteria written down before anyone classified a single asset, and for proof that the same criteria were applied across the estate. A criterion that exists only in the head of the platform lead will not survive a supervisory review.
Illustrative example: a payments team scores each asset from 1 to 3 on three dimensions, confidentiality, integrity and availability, using the impact on the supported function if that property fails. A customer-facing payment API scores 3 on availability and integrity, so its overall rating is critical. An internal wiki that supports no regulated function scores 1 across the board. Rules that map scores to classes, such as any 3 on availability making an asset critical, should be stated in the procedure so two reviewers reach the same answer. Confirm with your competent authority and your own risk function which thresholds and tie-breakers they expect, because DORA does not prescribe a scoring model.
For each classification decision, record the rationale in the inventory: the business function, the scores, the reviewer, the date and any dependency that raised the rating. Those notes are what turn a label into evidence. Review the criteria on the same cycle as the classification review that Article 8(1) requires, and reclassify when a dependency changes, for example when a open-source component becomes part of a critical function. Ask any implementation partner to show how their scoring fields map to the inventory before work starts, and confirm who signs off changes to the criteria.
Recording legacy systems and end-of-support risk
Legacy systems and unsupported suppliers are where DORA asset records most often go stale. The cards below cover what the inventory must hold for older systems, how end-of-support dates feed risk decisions, and how those items reach the residual risk inventory.
Legacy system records for risk assessment
Article 4 of Delegated Regulation (EU) 2024/1774 requires records needed for specific risk assessments of legacy ICT systems, for entities other than microenterprises. In practice, each legacy system needs its own record that states its business functions, data, owner and the controls that still apply. Check whether your inventory flags legacy status as a field, so reviews can filter for it rather than rely on memory.
Supplier end-of-support dates
Each asset record must carry the supplier's end-of-support date, which signals when security patches stop. Pull these dates from the vendor's published lifecycle pages for every operating system, database, firmware and framework, and record the source and the date you checked it. Where a component is open source, confirm whether a maintained upstream branch exists, since the vendor date may not apply.
Lifecycle monitoring of ageing assets
The asset management policy must cover lifecycle monitoring of assets classified under Article 8(1). For legacy items, this means a scheduled check against end-of-support dates, with a named owner who decides to upgrade, isolate, replace or accept the gap. Set the review trigger in the policy and confirm it runs against the same list the inventory holds, not a separate spreadsheet.
Linking legacy items to residual risk
A legacy system that cannot be patched becomes an accepted residual risk, and that acceptance belongs in the inventory of accepted residual risks reviewed yearly. Each legacy record should carry a reference to its risk entry, the compensating controls, the approver and the review date. Ask whether your risk register and asset inventory share identifiers, so an auditor can trace one asset to its risk decision without manual matching.
Isolating and compensating legacy systems
Where a legacy system stays in service, its network exposure and interdependencies must be recorded accurately, because they determine what the compensating controls must cover. Record which segments it sits on, which external paths reach it and which services depend on it. Confirm these details in your own environment with network diagrams and firewall rules, not from the original build documentation, which is often out of date.
Who signs off legacy decisions
The records only protect the entity if someone accountable approves the continued use of a legacy system. Document who owns each legacy item, who approves its retention, and who receives the risk assessment outcome. Check that the approver's role matches the authority set in your ICT risk management framework, and that the management body sees the aggregate exposure in its periodic reporting.
What building and maintaining the inventory costs
This table compares each cost component of a DORA ICT asset inventory by who is paid, whether the cost is one-time or recurring, and what drives it up. Read it to see where internal effort ends and where outside help is worth considering. No fees or durations are given because none are supplied; ask each party for a written quote tied to your scope.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Data collection from asset owners and IT staff | Your own asset owners and IT operations staff, or contractors you engage directly | One-time for the initial build, recurring for each review | Number of ICT assets, remote sites, legacy systems and how many owners must confirm their entries |
| Tooling set-up and configuration | An implementation partner, or your internal platform team | One-time | Choice of platform, integration with discovery and cloud sources, and the depth of the field model |
| Data migration from spreadsheets and CMDBs | An implementation partner or internal engineers | One-time | Quality of existing records, duplicate entries, and how many legacy sources must be merged |
| Mapping dependencies and third-party processes | Business function owners, internal architects and, where scoped, an implementation partner | One-time, then updated after major changes | Number of business functions, interconnections with ICT providers and how many critical or important functions are involved |
| Criticality and classification workshops | Risk, business and IT leaders inside your organization | One-time, then reviewed at least yearly | Number of criteria applied and the depth of impact analysis for confidentiality, integrity and availability |
| Documentation of the asset management policy and procedure | An implementation partner or your compliance team | One-time, with periodic revision | Number of documents, approval routing to the management body and alignment with other DORA policies |
| Tooling licences or support contracts | Software vendor or support provider, if you buy support for an open-source platform | Recurring, if support is purchased; open-source licences themselves carry no fee | Support tier, number of managed endpoints or records, and hosting location |
| Ongoing inventory upkeep and change capture | Your asset owners and operations staff, with optional retainer support from a partner | Recurring | Rate of infrastructure change, automation of discovery and how quickly changes are recorded after major changes |
| Independent assessment of the inventory | An independent auditor or assessor, where you commission one | Recurring, per assessment cycle | Scope of the assessment and the sample size the assessor selects. Auditors do not build or maintain the inventory |
Choosing tooling: a CMDB, an open-source asset register or a spreadsheet
A spreadsheet is the fastest way to start an inventory, and for a small entity with a short list of systems it can hold the fields Article 4 of Delegated Regulation (EU) 2024/1774 asks for. Its weakness is maintenance. Article 8(6) of DORA expects inventories to be updated periodically and after every major change, and a file that depends on someone remembering to edit it tends to drift from the live environment. Spreadsheets also struggle with dependency mapping, version history and access control over sensitive entries.
- Field coverage: Columns can hold a unique identifier, location, owner, supported business functions, recovery objectives and end-of-support dates, but nothing enforces that they are filled in.
- Change tracking: Edits are visible only if the file is versioned in a controlled repository.
- Dependency mapping: Links between assets must be typed by hand and are easy to leave out.
- Discovery: Nothing detects assets that were never entered.
- Access: Shared files often grant broader access than an inventory of critical assets should allow.
If you choose this route, confirm with your competent authority contact or internal audit that a controlled spreadsheet is acceptable for your size and risk profile, and document the update procedure.
A configuration management database is built for relationships between configuration items, so it suits entities with many interdependent services, multiple cloud accounts and frequent change. Commercial CMDBs usually come with discovery connectors, workflow tooling and reporting, but they carry licence, implementation and administration costs that recur every year. Those costs depend on the number of records, connectors and users, and on whether the vendor requires a specialist partner to configure the data model.
- Dependency mapping: Relationship models are often the strongest part of a CMDB and are a natural fit for the interconnection mapping Article 8(5) requires.
- Discovery: Connectors can populate records automatically, which reduces reliance on manual entry.
- Process integration: Change and incident workflows can update the inventory after a major change.
- Recurring cost: Licences, hosting and administration continue for as long as the platform runs.
- Lock-in: Exporting a complete, relationship-rich dataset in a usable format can be difficult.
Before buying, ask vendors to show how their model stores the Article 4 fields, how they handle assets on remote sites and whether they can export the full dataset without loss.
GLPI is an open-source IT service management platform, licensed under GPL-3.0-or-later. Its Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. Because the platform is self-hosted, the inventory stays inside your own infrastructure, and the cost is mainly implementation, hosting and administration rather than per-seat licensing.
- Automated inventory: The GLPI Agent can push hardware and software data from endpoints and network devices into the register.
- Coverage of hardware types: Racks, network equipment and telephony sit alongside computers and software.
- Self-hosted control: Data remains in your cloud account, data center or air-gapped network.
- Gaps to confirm: Verify whether GLPI supports dependency mapping, criticality fields, business function links and the Article 4 fields without custom development.
- Licence review: Have your legal team confirm the GPL-3.0-or-later terms against how you plan to modify and distribute any customizations.
Confirm these capabilities in a proof of concept against your own asset list before committing, and ask your implementation partner to document what requires custom fields or plugins.
The right route depends on your environment and audience. A single-site entity with stable systems and a small team may be well served by a controlled register. A group with multiple legal entities, hybrid cloud and third-party-hosted services needs relationship mapping that a spreadsheet cannot provide. Air-gapped or sovereign environments often rule out SaaS CMDB products, which pushes the decision toward self-hosted tools. Auditors and supervisors will ask for the same answers regardless of route: what is in the inventory, who owns each asset, and how you know it is current.
- Single site, small estate: A controlled spreadsheet or a light register may be enough if updates are tied to change approval.
- Multi-entity or hybrid cloud: Prioritize dependency mapping and discovery.
- Air-gapped or sovereign: Favor self-hosted tools and confirm they run without external connectivity.
- Shared ownership: Assign a named owner for the inventory and for each asset class.
- Migration path: Plan how records move from a spreadsheet to a register or CMDB without losing history.
Whatever you choose, test it by picking a sample of assets and tracing their owner, dependencies and recovery objectives end to end.
Why asset inventories fail review and how to avoid it
Examiners rarely reject an inventory for being short. They reject it because the records cannot be traced to business functions, third parties, owners or current state. The cards below cover the failures that recur most and the control that closes each one.
Incomplete cloud and SaaS records
Inventories often list servers and databases but miss cloud accounts, managed services, SaaS tenants and remote sites where information assets sit. Article 8(4) expects all information and ICT assets, including those on remote sites, to be identified. Build the inventory from cloud account exports, identity provider application lists and expense or procurement records, then reconcile the two sources each quarter so unlisted tenants surface.
No mapping to third-party processes
A list of assets does not show which processes depend on an ICT provider or how interconnections support critical or important functions. Article 8(5) requires these dependencies to be identified and documented. For each asset, record the provider, the contract reference and the business process it supports, so an examiner can trace a provider outage to the functions it affects.
Classifications without written criteria
Teams often label assets critical or low without a documented method, so the labels cannot be repeated or defended. Article 5 of Delegated Regulation (EU) 2024/1774 requires a documented procedure that weighs the ICT risk of the supported business function and the impact of losing confidentiality, integrity or availability. Write the scoring scale, the decision owner and the review trigger, and attach them to the policy.
Stale records after changes
Inventories drift when systems are upgraded, moved or decommissioned without a matching record change. Article 8(6) requires updates at regular intervals and after every major change. Tie the inventory to the change management workflow so a change ticket cannot close until the affected asset, configuration and dependency fields are updated, and run a periodic sample check against live systems.
Missing or unassigned owners
An asset without a named owner has no one to approve its classification, accept its risk or confirm its recovery objectives. Article 4 of Delegated Regulation (EU) 2024/1774 lists the owner as a required field. Require a named individual, not a team alias, for every record, and escalate unowned assets to the business function head at each review cycle.
Legacy systems without lifecycle records
End-of-support dates and legacy risk records are often missing for older platforms, which leaves the specific risk assessment of legacy systems unsupported. Article 4 requires supplier end-of-support dates in the record and the records needed for legacy risk assessments for entities other than microenterprises. Track vendor support status for every asset and flag any system approaching end of support for risk treatment.
Questions buyers ask about the DORA asset inventory
Is a spreadsheet enough for a DORA ICT asset inventory?
A spreadsheet can hold the records, but DORA asks for more than a list. Article 8 of the Regulation requires you to identify and document ICT-supported business functions, the assets behind them and their dependencies, and to keep that picture current, including after every major change. Article 4 of Delegated Regulation (EU) 2024/1774 then lists the fields each asset record must carry. A spreadsheet works best when one named owner controls it, every change has a date and an approver, and the file is linked to your change and configuration processes. Once the inventory is fed by discovery tools, or must show dependencies across many systems and third parties, a spreadsheet becomes hard to keep accurate. Ask your assessor or competent authority how they expect the inventory to be produced and maintained before you choose the tool.
How much effort does a DORA asset inventory take, and what drives it?
The effort depends mainly on the size and age of your estate, how many assets are already documented, and how many functions depend on third-party providers. No supplied figure gives a duration, so treat any number you hear as something to verify. The largest drivers are the number of assets and interdependencies to map, the quality of existing configuration data, the count of legacy systems that need records, and how many critical or important functions you must trace through to providers. Recurring effort comes from keeping the inventory current after changes and from the yearly classification review that Article 8 requires. Ask any vendor or consultant to break a quote into discovery, classification, dependency mapping, tooling and ongoing maintenance, and to state which of these are one-time and which recur.
How long does a first DORA asset inventory build take?
The honest answer is that the timeline depends on your environment, and no researched duration is available to quote here. Before you commit to a date, confirm with your team or implementation partner which work is already done, such as an existing configuration management database, cloud account inventories and a documented service catalogue. Those sources can shorten discovery considerably. Dependency mapping and criticality classification usually take longer than listing hardware and software because they need input from business owners and third-party contract records. Agree milestones in writing and check whether the schedule covers the first full review cycle, not only the initial list.
What does the inventory need from our internal staff?
An inventory cannot be built from tooling alone, because several fields carry business judgement. You will need business owners to confirm which functions each asset supports and how much an outage or data loss would hurt them, and you will need asset owners to confirm responsibility for each record. Platform and operations teams supply configuration, location, network exposure and end-of-support dates. Procurement or vendor management should provide the third-party service records that link processes to providers, and the risk function should agree the criticality criteria described in Article 5 of Delegated Regulation (EU) 2024/1774. Name these people and their time commitments before the work starts, since a delayed sign-off from a business owner is one of the most common reasons an inventory stalls.
Do microenterprises need the same asset records under DORA?
Not in every respect. Article 4 of Delegated Regulation (EU) 2024/1774 requires the records needed for specific risk assessments of legacy ICT systems for entities other than microenterprises, so microenterprises are excused from that particular element. The core obligations to identify, classify and document ICT assets and their dependencies still apply to any financial entity in scope under Article 8, but the depth of detail should be proportionate to your size and risk profile. Confirm with your competent authority which records it expects from an entity of your type, and confirm how the proportionality principle in Article 4 of the Regulation applies to your business.
Who approves the ICT asset management policy?
The policy is owned by the financial entity and sits within its ICT risk management framework, so the management body is accountable for approving it as part of that framework. In practice, the policy is drafted by ICT risk or security with input from operations and business owners, then approved by the management body or the body delegated to act for it. An implementation partner can draft the policy, procedure and inventory structure, but the partner does not approve it or certify it. Keep a dated approval record, the version history and the review schedule, since an assessor will ask who signed the policy and when it was last reviewed.
What will an auditor or supervisor test in the asset inventory?
Assessors and supervisors usually test whether the inventory is complete, accurate and current, rather than whether a particular tool was used. They may sample assets and check that each record holds the fields listed in Article 4 of Delegated Regulation (EU) 2024/1774, trace a critical business function to its supporting assets and third-party providers, and compare the inventory against live discovery data to find gaps. They will also look for evidence of the yearly classification review, updates after major changes, the criticality procedure and the handling of legacy systems. Prepare evidence such as change records, review minutes, approval logs and discovery reports. Independent auditors and competent authorities issue any assessment outcome, not the implementation partner.
How DeployOpen scopes and prepares the asset inventory
DeployOpen works on the DORA ICT asset inventory as a fixed-scope engagement inside the client's own infrastructure. The written scope sets which business functions, systems and dependencies are covered, and the organization keeps ownership of the classification decisions and the policy it approves.
How we scope
- The written scope lists the business functions, ICT systems and sites to be inventoried before work starts.
- Scope confirms which platforms hold the asset fields required by the RTS, including owners, locations and recovery objectives.
- Scope names the third-party and intra-group dependencies to be mapped, so supplier records are not left to memory.
How we build
- Self-hosted asset tooling such as GLPI is configured for the records the asset management policy requires.
- Discovery and manual entry are combined so cloud, data center and remote-site assets are all recorded with unique identifiers.
- Criticality criteria and legacy system flags are set up as fields and reports the client can review and update.
How we hand over
- Deliverables include the configured inventory, the field dictionary, the dependency maps and the documented asset management procedure.
- The client receives a short runbook describing how owners update records after every major change and at least yearly reviews.
- Handover includes a walkthrough so the client's own staff can run the inventory and produce evidence for an assessor.
How we support
- Ongoing support, upgrades and periodic inventory reviews are available as a retainer after handover.
- Retainers can cover tooling maintenance so the inventory stays current as systems, providers and sites change.
- Clients should confirm with DeployOpen what the retainer includes before signing, since the scope is set in writing.
