DORA ICT Asset Mapping - A Practical Guide for Financial Entities

ICT asset identification and dependency mapping form the foundation of DORA compliance. Article 8 of EU Regulation 2022/2554 requires financial entities to identify, classify, and adequately document all ICT assets and their interdependencies. Without a complete and accurate asset inventory, every other DORA requirement - from risk assessment to incident reporting - operates on incomplete information.

What DORA requires for ICT asset management

Article 8 sets out specific requirements across several dimensions. Financial entities must identify and document all information assets and ICT assets, including those on remote sites. They must classify these assets according to their criticality and map all dependencies between assets, systems, processes, and ICT third-party providers.

Article 8.7 adds a specific obligation around legacy ICT systems: entities must carry out a specific risk assessment for any ICT system that is no longer supported by its provider or that uses outdated technology.

The four layers of ICT asset mapping

Effective asset mapping under DORA requires thinking in four interconnected layers:

1. Business functions

Start by identifying your critical or important business functions. Under DORA, these are functions whose disruption would materially impair the entity's financial performance, soundness, or continuity. Examples include payment processing, trading operations, client account management, regulatory reporting, and core banking operations.

2. Information assets

Map the data and information that each business function relies on. This includes customer data, transaction records, market data feeds, regulatory filings, and internal operational data. Understanding data flows is essential for assessing impact if an ICT asset fails.

3. ICT assets

Document the technology components that store, process, or transmit information assets. This layer includes:

• Hardware - servers, network equipment, storage devices, endpoints
• Software - operating systems, applications, middleware, databases
• Cloud services - IaaS, PaaS, SaaS platforms
• Network infrastructure - firewalls, load balancers, VPN gateways, DNS
• Security tools - SIEM, endpoint protection, identity management

4. Dependencies

This is the most complex but arguably the most valuable layer. Map how assets depend on each other and on external providers. A single cloud provider outage might cascade through dozens of applications. A DNS failure could disable all external-facing services. Dependency mapping reveals these hidden chains of risk.

Step-by-step approach to asset inventory

1. Scope definition - Define the boundary of your inventory. All ICT assets that support financial services operations are in scope, including those managed by third parties on your behalf.
2. Discovery - Use automated discovery tools where possible to identify assets on your network. Supplement with manual input for cloud services, SaaS applications, and assets managed by third parties.
3. Classification - Assign each asset a criticality level based on the business functions it supports. An asset that underpins a critical function inherits that criticality.
4. Dependency mapping - Document upstream and downstream dependencies for each asset. What does it depend on? What depends on it? Include third-party dependencies.
5. Ownership assignment - Assign a responsible owner for each asset. Under DORA, management bodies have ultimate accountability, but day-to-day ownership should be clearly delegated.
6. Documentation - Record all information in a structured, auditable format. This feeds into your ICT risk management framework and your Register of Information.

Dependency mapping best practices

Dependency mapping is where most organisations struggle. A few practical recommendations:

• Map in both directions - For each asset, document what it depends on (upstream) and what depends on it (downstream). This reveals both vulnerability and blast radius.
• Include third-party chains - A cloud-hosted application depends on the cloud provider, which may depend on specific data centre operators and network providers. Trace as far as practical.
• Identify single points of failure - Look for assets or providers where a single failure would disrupt multiple critical functions. These represent concentration risk.
• Visualise the map - Dependency data in a spreadsheet is hard to analyse. Use tools that provide visual dependency chain views to spot patterns and risks.
• Validate with stakeholders - Technical discovery tools miss business context. Validate your dependency map with business function owners who understand operational reality.

Legacy system considerations

Article 8.7 requires specific attention to legacy ICT systems. For each system identified as legacy (end-of-life, unsupported, or running outdated technology), entities must:

• Carry out a dedicated risk assessment documenting the specific risks
• Assess whether the system can be replaced or upgraded
• Document compensating controls if the system must remain in operation
• Include the legacy system's dependencies in their overall mapping

How DoraLytics helps

DoraLytics is purpose-built for ICT asset and dependency mapping under DORA. The platform provides a structured register where you can classify assets, assign criticality, and map dependencies visually. Dependency chains are displayed as interactive graphs, making it easy to identify concentration risks and single points of failure. The asset register integrates directly with the Third-Party Risk Management and Register of Information modules, so data flows automatically across your compliance workflow.

Further reading

• DORA Regulation full text (EU 2022/2554) - EUR-Lex