How Inaccurate CMDBs Put Madrid’s Banking Groups at DORA Compliance Risk

On April 28, 2025, a grid failure swept across the Iberian Peninsula and knocked out digital payment infrastructure for nearly ten hours. Bizum, Spain’s peer-to-peer payment system with 27 million registered users, went dark alongside international card networks and mobile wallets. Banco de España confirmed the return to normal of national and cross-border payment systems in a public statement hours after the disruption. Spain’s business lobby estimated the economic cost at roughly €1.6 billion, close to 0.1% of GDP.

The outage was a power failure, not a CMDB failure. But European supervisors classified the event under the 2025 DORA incident-reporting framework as a major ICT incident. Every affected Madrid bank had to answer, on a regulatory clock, which systems were touched, what depended on them, and how far the impact spread. That answer is only as fast and accurate as the CMDB underneath it.

Madrid is home to some of Europe’s largest banking groups, including Santander, BBVA, and CaixaBank’s operational subsidiaries. Each operates hybrid IT estates spanning on-premises data centers, cloud workloads, and third-party service providers distributed across the EU. Keeping an accurate, current inventory of those assets, and the dependencies between them, is no longer an internal IT discipline. Under the Digital Operational Resilience Act, it is a regulatory obligation with supervisory teeth.

Understanding where that obligation starts, and where most banks’ current CMDB posture falls short, is the starting point for getting ahead of the next review. Virima’s Trusted Runtime Truth framework addresses exactly this layer: discovery-sourced asset and dependency data that supervisors can examine and trace.

What Is DORA Compliance, and Where Does CMDB Accuracy Sit Inside It?

Regulation (EU) 2022/2554 has been mandatory since January 17, 2025. It establishes binding requirements across five domains: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing. The Regulatory Technical Standards on ICT risk management name ICT asset management as a required control area. Banks must maintain a Register of Information covering every system classified as critical or important, including the assets that support those systems and the third-party providers involved in their delivery.

The CMDB is the infrastructure layer where the Register of Information begins. It is not the compliance mechanism itself. Whether a bank achieves DORA compliance depends on its governance program, testing practice, and incident response process. The CMDB provides the asset and dependency data those programs build on. When that data is incomplete or stale, every downstream control built on it inherits the same weakness.

The gap between what a CMDB says and what exists in production closes slowly on manual maintenance cycles. The role of CMDB accuracy in IT security and compliance goes beyond data hygiene. DORA has attached a supervisory clock and a financial penalty to the quality of that data.

Three situations arise repeatedly at banking groups with CMDB accuracy problems.

Why CMDB Accuracy Is the DORA Requirement Nobody’s Watching

Article 50 of Regulation (EU) 2022/2554 establishes administrative penalties for DORA infringements. For the most serious violations, a bank can face a fine of up to 10% of annual turnover. Individual directors can receive temporary bans on management functions.

These are not theoretical penalties. EBA, ESMA, and EIOPA reported 3,383 major ICT-related incidents across EU financial entities in 2025. The majority were concentrated in credit and payment sectors. Roughly one-third carried cross-border impact.

Industry research consistently puts average CMDB accuracy at around 60%. At that baseline, four specific failure modes surface during DORA supervisory reviews.

1. Register of Information mismatches. An asset record not updated since the last manual audit may not reflect current cloud configurations, decommissioned hardware, or a recently onboarded provider. When the RoI submission doesn’t match what supervisors observe, the bank files a correction.
   Result: A corrected filing and a flagged entry in the next supervisory review cycle.
2. Incident classification delay. DORA’s major incident reporting window requires initial notification within four hours. Classifying an incident against critical business functions requires knowing which systems were affected and how they connect. When the dependency map is stale, classification takes longer.
   Result: A missed initial-notification window, which is itself a reportable gap.
3. Third-party concentration blind spots. DORA’s third-party risk requirements include mapping which ICT providers support which critical functions. An incomplete CMDB that doesn’t link contracts to systems of record leaves that mapping unfinished.
   Result: A third-party risk management gap surfaced during supervisory review.
4. Resilience testing scope gaps. Threat-led penetration testing under DORA must cover the systems that matter most. When the inventory is wrong, the scoping exercise starts from a flawed baseline.
   Result: A test that looks complete in documentation but didn’t cover what it should have.

The pattern across all four failures is the same. The CMDB health score was low before the review began, and the compliance team discovered the problem only when a supervisor, auditor, or incident deadline forced the question.

How Getting This Wrong in Madrid Matters

For a board-level conversation, the financial exposure is grounded in Article 50 penalties. The reputational exposure is grounded locally.

Banco de España supervises credit institutions for DORA compliance in Spain. CNMV supervises investment firms and market participants. DGSFP supervises insurance and reinsurance undertakings. A formal finding from Banco de España carries weight beyond the fine itself. For a banking group with Madrid as its EU headquarters, a supervisory finding affects how regulators in other member states perceive the group’s ICT governance posture.

The Financial Stability Board’s November 2025 peer review of Spain recommended that the country further enhance the cyber resilience of its financial sector. That recommendation placed Spain’s banking infrastructure under a sharper supervisory spotlight than most EU peers currently face.

The financial cost of ICT control failures has a published reference point. IBM’s 2026 Cost of a Data Breach Report put the average breach cost in the financial sector at $6.3 million, against a global average of $4.99 million. A CMDB that can’t answer which assets were affected, or whether a third-party provider was involved, extends every breach response and pushes costs toward the upper range.

For configuration management teams, the cost registers differently. The Register of Information deadline produces a reconciliation scramble when the CMDB hasn’t been maintained through the year. Mapping contracts to systems of record manually, weeks before a submission deadline, is recoverable. It is not sustainable. And it produces exactly the stale-at-submission data that generates the findings described above.

Additional context on how CMDB data gaps compound total cost of ownership is covered in Virima’s CMDB TCO analysis.

A DORA Compliance CMDB Solution for Madrid Banks: Three Mechanisms That Close the Gap

Three operational mechanisms move a CMDB from a compliance liability to a credible, audit-ready evidence layer.

1. High-frequency scheduled discovery across the full hybrid estate.
   Virima’s agent-based and agentless discovery runs on scheduled cycles across on-premises infrastructure, AWS, and Azure workloads. Each cycle refreshes CI records with current configuration data, captures newly provisioned assets, and flags configuration changes against the CMDB’s previous state. This keeps the inventory current between Register of Information cycles without manual polling. The discovery techniques that work across hybrid estates are covered in depth on Virima’s blog.
2. ViVID™ service mapping tied to DORA’s critical function taxonomy.
   DORA’s RTS require mapping which ICT assets support which critical and important business functions. Virima’s ViVID™ service mapping builds dependency maps from discovery-sourced CI data. These maps connect infrastructure assets to the service definitions that business owners supply. When an incident touches a CI, the map surfaces which services depend on that CI and how far the impact reaches. That is the classification speed DORA’s four-hour notification window requires.
3. Bi-directional ITSM integration to maintain a single evidence source.
   When CMDB data lives in multiple systems, reconciliation becomes the work. Virima connects to the ITSM platforms Madrid banks are already running, including ServiceNow, Jira Service Management, Ivanti, and HaloITSM, through its integrations hub. The connection keeps CMDB records synchronized with change records in the ITSM. The evidence layer that DORA auditors review reflects the same state as the operational record.

The operational difference between manual CMDB maintenance and discovery-driven CMDB management maps directly to DORA’s requirements.

DORA Compliance and CMDB Accuracy in Practice

Three scenarios illustrate how CMDB accuracy gaps surface under DORA’s requirements. These are composite illustrations, not named case studies.

• Six weeks before the Register of Information deadline. A banking group’s CMDB team discovers that 15% of ICT contracts classified as critical are not linked to a system of record. The contract exists in procurement. The asset exists in the CMDB. The join between them does not. Closing that gap manually before the submission deadline requires cross-team effort. It could have been avoided if discovery had flagged the disconnect when the contract was onboarded.
• A cross-border incident notification. A payment processing failure at a Madrid bank’s core banking platform also affects a subsidiary operating in another EU member state. Under DORA, both entities file incident reports. Classification requires agreement on which critical functions were affected in each entity. When both entities draw from the same discovery-sourced CI inventory, classification converges on a shared evidence base. When each entity maintains its own manual CMDB, the answers diverge, and the submission timelines do too.
• A banking group’s Madrid subsidiary during a supervisory audit. The parent bank sets policy at the group level. The subsidiary delivers evidence at the local level. Both need to draw from the same underlying asset map for the submission to be consistent. A CMDB Owner at the Madrid subsidiary who can point to a scheduled discovery baseline, a current ViVID™ service map, and a synchronized ITSM record is in a fundamentally different position than one reconciling spreadsheets a week before the audit date.

Teams that move from manual reconciliation to discovery-sourced CMDB management report that the evidence they bring to audits holds up under scrutiny. The data can be checked, traced back to a discovery scan, and corrected with a known refresh cycle. That shift, from the most-questioned team in the room to the most-prepared one, is the practical return.

How Virima Supports DORA-Ready CMDB Accuracy

Virima’s contribution to DORA readiness operates across three timeframes.

Immediate operational impact

Scheduled discovery refreshes CI relationships on each scan cycle. Dependency data available during an incident is current, not months old. When a DORA major incident classification is needed within four hours, an accurate, map-backed CMDB makes the difference between meeting the window and missing it. The CMDB health score feature gives configuration teams a measurable signal of inventory quality at any point in the year.

Long-term accuracy through governance

Discovery does not replace CMDB governance. It supplies the data that makes governance tractable. Scheduled scans flag CI drift against previous states, surface unauthorized changes, and identify assets that have moved between environments without a change record. ServiceNow CMDB governance best practices for 2026 cover the governance approach that works alongside discovery-sourced data.

Integration with existing workflows

Most Madrid banks are already running an ITSM platform and a CMDB structure. Virima operates as a discovery and mapping layer that feeds those existing workflows. A detailed view of how that works in a ServiceNow environment is available in Virima’s CMDB workspace overview.

The financial services compliance context for CMDB data quality, including DORA’s ICT asset register requirement, is addressed in Virima’s IT asset management for financial services compliance post.

Moving from Manual Reconciliation to Map-Driven DORA Readiness

The shift from manual CMDB maintenance to discovery-driven accuracy involves two operational changes.

Those two changes produce a cascade of benefits that DORA reporting depends on. Incident notification is faster because classification no longer depends on individuals who know the estate from memory. Evidence is audit-ready because CI records can be traced to a discovery scan rather than a manual entry. Board-level risk visibility improves because the CMDB health score gives leadership a measurable proxy for ICT control quality, before a supervisor raises the question.

Getting from the current state to that posture follows five steps.

1. Inventory current gaps in the existing CMDB against the Register of Information scope.
2. Run a discovery baseline across on-premises and cloud environments to establish what exists in production.
3. Map critical and important business functions using ViVID™ service maps, starting with the functions DORA requires coverage for.
4. Connect the CMDB to the bank’s existing ITSM platform to synchronize change records with CI state.
5. Set CMDB health thresholds and review them before each RoI cycle, not after.

A broader view of the IT asset management process supporting these steps is available in Virima’s best practices for IT asset management post.

A discovery-driven CMDB keeps ICT asset records ready before the next Register of Information deadline arrives, not assembled under pressure after. More on the CMDB capabilities that support this at virima.com/features/cmdb.

Frequently Asked Questions