DORA Article 8 requires financial entities to identify, classify and document all ICT supported business functions and the information and ICT assets behind them, map critical assets and their interdependencies, and keep inventories updated, including after every major change. The inventory is the base for risk assessment, testing and third-party management.
What the article asks for
Paraphrasing Article 8:
- Identify, classify and document functions, roles, the information assets and ICT assets supporting them, and their dependencies. Review the adequacy of this at least yearly (8(1)).
- Continuously identify sources of ICT risk, assess cyber threats and ICT vulnerabilities relevant to those assets, and review risk scenarios at least yearly (8(2)).
- Perform a risk assessment upon each major change in infrastructure, processes or procedures, for entities other than microenterprises (8(3)).
- Identify all information and ICT assets, including remote sites, network resources and hardware, map the critical ones, and map their configuration, links and interdependencies (8(4)).
- Identify processes that depend on ICT third-party providers and interconnections with providers supporting critical or important functions (8(5)).
- Maintain inventories and update them periodically and after every major change (8(6)).
- Run a specific ICT risk assessment on all legacy ICT systems at least yearly, and before and after connecting technologies, applications or systems (8(7)).
DORA defines an ICT asset as a software or hardware asset in the network and information systems, and a legacy ICT system as one that has reached end of life or is no longer supported by its supplier but is still in use.
What this means for software teams
"Software asset" is broader than a server list. A practical inventory has layers:
- Business functions and which are critical or important.
- Services and applications supporting each function, with an owner.
- Components inside them: open source libraries, container base images, runtime versions. A software bill of materials per service is a good form for this.
- Infrastructure: hosts, clusters, network paths, cloud accounts.
- External dependencies: SaaS tools and ICT providers, linked to the register of information.
- Legacy items: unsupported runtimes or frameworks with a yearly risk assessment note.
Keep it current
An inventory goes stale in weeks. Tie updates to events that already happen: a deploy regenerates the SBOM, an infrastructure change triggers a record update, a new vendor triggers a register entry. Article 8(6) asks for updates "every time" a major change occurs, which is hard to meet by hand.
Link inventory to other duties
- Vulnerability handling needs the inventory to answer "are we exposed?".
- Testing scope (Article 24) starts from critical systems in the inventory.
- Incident classification needs to know which clients and functions an asset supports.
- Exit planning needs the dependency map.
Click through it at your own pace, or open it full screen.
Safeguard includes asset discovery and SBOM and dependency scanning, which can supply the component and asset layers of such an inventory. Business function mapping still needs your own judgement.
Quick check
Is an SBOM required by DORA?
DORA does not name SBOMs. It requires inventories of ICT assets, including software, kept current. An SBOM is one practical way to document software components.
How often must the inventory be reviewed?
At least yearly for classification and documentation, and upon each major change for inventories and risk assessments.
Sources
Last reviewed: 19 October 2026.
