Can DORA CMDB Accuracy for Banking and Insurance Groups in Paris Pass Stricter Checks?

The European Supervisory Authorities (ESAs) published their DORA dry run summary report in December 2024. A total of 1,039 financial entities submitted registers of information. Of the 947 registers analysed, 6.5% passed all data quality checks, and missing mandatory information accounted for 86% of all data errors.

Paris banking and insurance groups faced the official version in 2026. The ACPR set the reference date at 31 December 2025 and the submission deadline at 31 March 2026. Groups with both a bank and an insurer file through two collections, SURFI for banking and SOLVA for insurance.

DORA CMDB accuracy for banking and insurance groups in Paris therefore starts with a practical question. Can each register line be traced to a system, an owner, and a last-verified date?

What the register asks of Paris banking and insurance groups

Regulation (EU) 2022/2554, known as DORA, sets out that financial entities maintain a register of information on their contractual arrangements with ICT third-party service providers.

In France, the ACPR’s 23 January 2026 webinar set the calendar for banking and insurance entities. The platform opened on 1 January 2026, the reference date was 31 December 2025, and the submission deadline was 31 March 2026. Entities accredit on the OneGate portal with their LEI, and new ACPR teams handle reminders and follow-ups. The ACPR recommends test submissions on the OneGate homologation platform before the deadline, and each accepted submission returns an HTML report, an XML report, and an Excel file listing anomalies.

The scope covers non-significant credit institutions, Solvency II insurers and reinsurers, and insurance group holding companies, among others. An annex table helps each group identify its consolidation level.

A CMDB holds the infrastructure side of this picture: which systems exist, what they connect to, who owns them, and when each record was last verified. The group’s governance builds and files the register itself, drawing on those records. Virima’s Frankfurt DORA CMDB guide covers how DORA’s ICT asset documentation duties relate to the register.

What stricter register checks mean in practice

The dry run accepted partial registers. Official reporting rejects registers when the LEIs of the financial entities are missing, according to the ESAs report. The official process has two layers. Submissions that miss technical requirements are rejected and resubmitted, and accepted files are checked against data model and business rules, including LEI checks against GLEIF. Failures in that second layer are flagged for correction and resubmission.

Identifiers made up a visible share of the dry run errors. Invalid LEI codes accounted for 6.5% of data errors, and duplicate keys and invalid dates for another 2.8%. Across the exercise, more than 235,000 data quality checks failed against more than 9.2 million data points, a ratio of 2.5%. The highest number of failed checks for a single entity was 43 of 116.

The 2026 process added a content review. The Central Bank of Ireland describes an additional EBA review step, with data quality checks on register content in April 2026. Its examples include a placeholder parent identifier and a generic provider name such as “not applicable.” The Central Bank adds that firms lower the chance of a resubmission request by checking that their data is sensible before final submission.

In Luxembourg, the CSSF forwards all registers to the ESAs, which run additional quality and consistency checks in April 2026, according to EY Luxembourg. A rejected register returns to the entity for correction and resubmission. EY also lists what the register requires entities to demonstrate. The list includes mapping ICT service providers and subcontracting chains, consistency across group entities and consolidation scopes, and reconciling IT, operational risk and outsourcing records. EY adds that for many organizations the register is the first time this information sits in a single dataset.

In Deloitte’s European DORA survey from early 2025, covering 28 countries, 46% of financial entities named the register of information their most challenging task.

Why a banking and insurance group ends up with competing system lists

Groups that combine a bank and an insurer often keep separate lists of ICT systems for each entity. Three patterns appear repeatedly when those lists meet a register deadline.

• Each entity names systems its own way: the bank, the insurer, and shared services may each record the same payments gateway under a different name. Result: system counts differ across the group, and every reconciliation starts from scratch.
• Provider details sit in several places: procurement, legal, and IT each hold part of the provider picture. EY raises a related point when it lists the reconciliation of IT, operational risk and outsourcing records. Result: the provider fields of the register are assembled by hand each cycle.
• Retired systems stay on the list: a system retired by one entity can remain in another entity’s list until an owner confirms the retirement. Result: stale records reach the filing.

Across industries, Flexera’s 2026 State of ITAM survey of 512 professionals found complete IT visibility at 36%, down from 43% in 2025.

Three DORA tasks that draw on CMDB data

In a 2025 article, KPMG Germany calls the CMDB the central data basis for managing IT in financial institutions and says its importance increases under DORA. The article describes three tasks where CMDB data supports DORA implementation.

• Legacy ICT systems: the CMDB can identify and manage them when it holds end-of-life data, and providers are a source of that data for outsourced IT. KPMG recommends adding a legacy-system attribute to the data model.
• Critical or important functions: KPMG recommends flagging these business processes in the CMDB data model and keeping the flags up to date.
• Incident classification: linking CMDB data to incident management lets an institution assess an incident’s impact on business processes quickly.

In Virima, ViVID™ service mapping establishes Trusted Runtime Truth by overlaying ITSM records, vulnerability data, and change history on each service map. Incident teams see the connections around a system alongside its open records.

DORA CMDB Accuracy for Banking and Insurance Groups in Paris: One Owned Record Across Entities

Accuracy here means each record matches what is on the network and carries a named owner and a last-verified date. Four mechanisms in Virima support that goal.

• Discover every entity on a schedule: IT Discovery combines more than 140 extendable agentless probes with a lightweight agent for Windows, macOS, and Linux endpoints. API connectors pull AWS and Azure resources into the same CI record as on-premises assets. Credentials for agentless discovery stay encrypted on the on-premises Discovery App server, and scans recur on a high-frequency schedule that the team sets. Varied scan windows catch devices that appear only at certain times, and the agent reports from roaming endpoints regardless of network connectivity.
• Reconcile sources with authority rules: a last-scan-wins rule lets whichever scan ran most recently overwrite the value. Virima’s reconciliation article walks through a case where a stale switch-port scan overwrote a correct rack location and a change board then approved maintenance for the wrong rack. When two sources disagree on an attribute, Virima’s discovery-sourced CMDB applies configured authority rules. Each CI carries its source, a freshness timestamp, and an owner, and reconciliation history stays available for audit. Virima’s article on attribute-level multi-source reconciliation gives examples of authority rules: cloud APIs for region and tags, the ITSM for owner and criticality, and agent-based discovery for installed software. Disagreements on important attributes go to a review queue, and each decision is recorded in the audit trail.
• Map the connections: ViVID™ service mapping shows communication flows between servers, including port and protocol. It also lists ghost machines, which are hosts that appear in communication flows before a CMDB record exists. The group’s team defines each service once, in the Virima UI or by CSV import.
• Carry change into the record: Virima’s ServiceNow integration syncs reconciled CI data and dependency maps into ServiceNow tables via standard ITSM integrations. Virima’s article on CMDB for change management follows five stages. The request identifies the CIs in scope and their owners, impact analysis maps dependencies, and the approval board receives accurate configuration data. Implementation flags items that must be updated together, and the post-implementation review confirms that updates match the plan.

Where the CMDB ends and the group’s governance begins

The CMDB records ICT infrastructure and the connections between systems. The group’s governance owns the register of information, the choice of critical or important functions, contract terms, subcontracting chains, and incident reporting.

Discovery reaches devices that are network-accessible and speak a compatible protocol, plus AWS and Azure accounts. Owners register other systems manually in the CMDB.

Retirement is a deliberate step with a named owner. Virima’s ITAM lifecycle statuses run from requested through decommissioned, and the CMDB flags retired assets as decommissioned while keeping their timestamped change log.

Virima’s financial services ITAM guide covers how discovery-driven asset management supports SOX, PCI DSS, DORA, and GLBA programs.

How to measure CMDB accuracy before the next register cycle

Three measures give a group a baseline before the next collection opens.

• The share of CI records that carry a named owner and a last-verified date.
• The number of differences between the bank’s list, the insurer’s list, and the outsourcing register for one service.
• The days needed to produce an agreed ICT system list for one entity.

Virima’s CMDB health score article defines six metrics: completeness, accuracy, staleness, relationship coverage, ownership coverage, and CI lifecycle validity. Staleness is measured against a freshness window, commonly 30, 60, or 90 days. The article’s benchmark bands run from Healthy at 85 to 100 down to Unreliable below 55, and it suggests audits at least monthly, or weekly in high-change environments.

Getting started: the first 90 days

• Name an owner for the CMDB and for each entity’s IT, and agree who confirms records before each register cycle.
• Pick one bounded scope, such as a payments service shared by the bank and the insurer, and compare the CMDBs, the outsourcing register, and the spreadsheets for it.
• Run discovery on that scope on a schedule the team can keep, include its AWS or Azure accounts, and record each difference with an owner and a decision.
• Define the services the group treats as important in ViVID™ with their owners, and review the connections to them.
• Add a change check so a migration or entity change closes only when its records carry an owner and a last-verified date, and let a named owner confirm each retirement.

A scoped first pass shows how far your current system lists agree with what discovery finds, before the next register cycle begins. Schedule a Virima demo to walk through that comparison on one of your own services, with owners and last-verified dates attached to each record.

Frequently Asked Questions