Building Your DORA Art. 8 ICT Asset Register: From Spreadsheet to Living Inventory
The Foundation That Everything Else Depends On
If there is one DORA obligation that underpins every other, it is Article 8. The ICT asset register is the foundation upon which the entire ICT risk management framework rests. Without a complete, accurate, and current inventory of ICT assets, the institution cannot perform a meaningful business impact analysis, cannot assess ICT risk comprehensively, cannot define backup scope correctly, cannot map third-party dependencies, and cannot design a resilience testing programme that covers the right systems.
DORA Art. 8(1) requires financial entities to "identify, classify and adequately document all ICT assets" and to "identify all sources of ICT risk." Art. 8(4) requires that the identification be "updated on a regular basis and at least once a year." The EBA's ICT risk management guidelines further specify that the register should include dependencies between assets and that the classification should reflect the criticality of the business functions the assets support.
The reality in most financial institutions is that the ICT asset inventory exists in some form — a CMDB, a spreadsheet, a wiki page, a combination of all three — but it is incomplete, inconsistent, and not governed as a regulatory artifact. The gap between "we have a CMDB" and "we have an Art. 8 compliant ICT asset register" is substantial, and closing it is the single most impactful step an institution can take in its DORA compliance journey.
What Art. 8 Requires
Art. 8 establishes a multi-layered identification and documentation requirement:
| Art. 8 provision | Requirement | Practical scope |
|---|---|---|
| Art. 8(1) | Identify, classify, and document all ICT assets | Hardware, software, data, network, cloud services, SaaS |
| Art. 8(2) | Identify all sources of ICT risk | Threat landscape per asset, vulnerability exposure |
| Art. 8(3) | Identify ICT assets and systems supporting critical functions | Mapping from business functions to ICT infrastructure |
| Art. 8(4) | Review and update at least annually | Governance process with triggers for ad hoc updates |
The word "all" in Art. 8(1) is significant. Supervisors will ask whether the register includes:
- On-premise hardware (servers, network equipment, storage)
- Cloud infrastructure (IaaS instances, managed databases, serverless functions)
- SaaS applications (CRM, ERP, HR systems, collaboration tools)
- APIs and integration middleware
- Data stores and databases
- Backup and disaster recovery infrastructure
- Security infrastructure (firewalls, WAF, SIEM, IAM)
- End-user devices (where they support critical functions)
- Third-party provided services mapped to the supporting provider
The Asset Taxonomy
A functional asset register requires a consistent taxonomy. The DORA-aligned taxonomy organizes assets into categories that map to regulatory requirements:
Mandatory Attributes Per Asset
Every asset in the register must carry a minimum set of attributes to satisfy Art. 8 and feed into downstream DORA obligations:
| Attribute category | Fields | DORA dependency |
|---|---|---|
| Identity | Asset ID, name, type, category, description | Art. 8(1) identification |
| Ownership | Owner role, steward, department | Art. 5 management body accountability |
| Classification | Criticality level, data classification | Art. 8(1) classification |
| Lifecycle | Status, commissioning date, planned decommission | Art. 8(4) currency |
| Resilience | RTO, RPO, MTPD, DR tier | Art. 11, Art. 12 business continuity |
| Dependencies | Upstream assets, downstream assets, dependency type | Art. 8(3) critical function mapping |
| Third-party | Hosting provider, service provider, contract reference | Art. 28 third-party register |
| Risk | Threat exposure, vulnerability score, last assessment | Art. 8(2) risk identification |
| Environment | Production, UAT, Development | Art. 9 protection measures |
| Location | Data center, region, availability zone | Art. 12(4) backup segregation |
From Spreadsheet to Living Inventory
The migration from spreadsheet-based inventory to a governed asset register follows a predictable path:
Phase 1: Discovery and Baseline (Months 1-3)
The initial discovery combines top-down and bottom-up approaches:
Top-down: Start from critical functions (identified per Art. 8(3)) and trace downward through the technology stack. For each critical function, ask: What applications support this function? What databases do those applications use? What infrastructure hosts those databases? What network connects them? What third parties provide any of these layers?
Bottom-up: Use automated discovery tools to scan the network, cloud accounts, and SaaS tenants. Compare discovered assets against the existing CMDB or inventory. Every asset that appears in discovery but not in the inventory is a gap.
Phase 2: Classification and Enrichment (Months 3-5)
With the baseline inventory established, enrich each asset with:
- Criticality classification derived from the business impact analysis. Assets supporting critical functions are classified CRITICAL or HIGH by default.
- Data classification per the institution's data classification scheme. The highest classification of data processed by the asset determines its data classification attribute.
- Resilience parameters (RTO, RPO, MTPD) inherited from the business function the asset supports or defined per the asset's role in the recovery architecture.
- Dependency mapping identifying both upstream dependencies (what this asset depends on) and downstream dependencies (what depends on this asset).
Phase 3: Governance and Operationalization (Months 5-8)
A register without governance degrades to a stale artifact within months. The governance framework must include:
| Governance process | Trigger | Responsible | Evidence |
|---|---|---|---|
| New asset registration | Procurement, provisioning, shadow IT discovery | Asset owner + register steward | Registration record with classification |
| Asset modification | Configuration change, migration, upgrade | Asset owner | Change record with impact assessment |
| Asset decommission | End of life, replacement, service termination | Asset owner + approver | Decommission record with data disposition |
| Dependency change | New integration, provider change, architecture change | Asset owner + architecture review | Updated dependency map |
| Annual review | Calendar trigger (Art. 8(4)) | Register steward + all asset owners | Review record with changes made |
| Criticality reclassification | BIA update, function change, incident trigger | Risk function | Reclassification record with justification |
Phase 4: Integration and Automation (Months 8-12)
The register reaches maturity when it is integrated with the systems that consume it:
- Risk management: Asset risk scores feed into the enterprise risk register under Art. 6
- Incident management: Incidents are mapped to affected assets, enabling impact assessment under Art. 17
- Third-party management: Assets linked to third-party providers feed the register of information under Art. 28(3)
- Resilience testing: The testing programme under Art. 24 uses the asset register to determine test scope
- Backup management: Backup scope under Art. 12 derives from critical function asset mapping
- Board reporting: Art. 14 reporting includes asset register coverage as a key risk indicator
The Dependency Map
Asset dependencies are the most difficult attribute to capture accurately and the most valuable for resilience analysis. A critical function may depend on an application, which depends on a database, which depends on a storage system, which depends on a network, which depends on a third-party provider. A failure at any point in this chain can disrupt the critical function.
The dependency map must distinguish between:
- Hard dependencies: The upstream asset must be available for the downstream asset to function. Failure propagates immediately.
- Soft dependencies: The upstream asset enhances the downstream asset's functionality but is not required for basic operation. Failure causes degradation, not outage.
- Optional dependencies: The upstream asset provides supplementary capability. Failure has minimal immediate impact.
This dependency typing feeds directly into business continuity planning — hard dependencies define the minimum recovery scope, while soft and optional dependencies define the order of restoration after the critical path is recovered.
Supervisory Expectations
Supervisors will assess the Art. 8 register against several dimensions. The ENISA guidelines on ICT asset management and EBA guidelines inform these expectations:
| Assessment dimension | What supervisors look for | Red flag |
|---|---|---|
| Completeness | All ICT assets supporting critical functions are in the register | Critical functions with unmapped technology dependencies |
| Currency | Register updated within the last 12 months (Art. 8(4)) minimum | Last update date > 12 months ago for any section |
| Accuracy | Asset attributes match reality (spot checks during examination) | Material discrepancies between register and actual configuration |
| Dependency mapping | Dependencies documented and validated | Critical functions with no documented dependencies |
| Classification consistency | Criticality aligned with BIA results | Asset classified LOW while supporting a critical function |
| Governance | Formal process for registration, modification, decommission | No change management process for the register |
| Integration | Register feeds risk assessment, testing, backup, third-party management | Register exists in isolation, not consumed by other DORA processes |
Common Implementation Pitfalls
Starting with the tool, not the taxonomy. Institutions that begin by purchasing a CMDB or GRC platform without first defining their asset taxonomy, classification criteria, and governance process end up with an expensive tool that replicates the problems of the spreadsheet in a prettier interface.
Ignoring SaaS. The register includes on-premise servers and databases but omits the 50+ SaaS applications that employees use daily — many of which process CONFIDENTIAL data and support important business functions. Shadow SaaS is the modern equivalent of shadow IT, and Art. 8(1) requires "all" ICT assets.
Static dependency maps. Dependencies are captured once and never updated. In a cloud-native or microservices environment, dependencies change with every deployment. The dependency map must be refreshed through a combination of automated discovery and manual validation.
No ownership model. Every asset must have a designated owner who is accountable for its classification, attributes, and governance. Assets without owners are orphans — they do not get updated, reviewed, or decommissioned, and they accumulate risk silently.
Use the DORA readiness assessment to evaluate your ICT asset register maturity, and consult the glossary for precise definitions of terms like "ICT asset," "critical or important function," and "ICT third-party service provider."
Conclusion
The Art. 8 ICT asset register is not a compliance artifact to be produced once and filed. It is the living foundation of the institution's entire ICT risk management framework. Every DORA obligation — from risk assessment to incident management, from resilience testing to third-party oversight, from backup management to board reporting — depends on the register being complete, accurate, current, and governed.
The institutions that build a living register invest more upfront but save exponentially across every downstream DORA workstream. The institutions that settle for a spreadsheet will rebuild it from scratch for every supervisory examination.
Resume en francais
L'article 8 de DORA exige des entites financieres qu'elles identifient, classifient et documentent tous les actifs TIC soutenant leurs fonctions critiques. Cet article fournit un guide de mise en oeuvre en quatre phases : decouverte et inventaire de base (approches descendante et ascendante), classification et enrichissement (criticite, donnees, resilience, dependances), gouvernance et operationnalisation (processus de changement, revue annuelle), integration et automatisation (alimentation des processus DORA en aval). Il presente la taxonomie d'actifs alignee DORA avec 7 couches et 27 types canoniques, les attributs obligatoires par actif, la cartographie des dependances avec typage (critique, souple, optionnel), les attentes des superviseurs et les erreurs courantes de mise en oeuvre. Le registre des actifs TIC est le fondement sur lequel repose l'ensemble du cadre de gestion des risques TIC — sans lui, toutes les obligations DORA en aval sont construites sur des bases incompletes.