CMDB for DORA Compliance Milan: One Asset Map for DORA and PCI DSS Before March 2027

On 28 November 2024, card payments across Italy began failing. The Bancomat and PagoBancomat circuits and Nexi services all reported problems. Worldline traced the cause to gas pipe installation work by local authorities, which severely damaged a supplier’s cables. Banca d’Italia monitored the disruption with CODISE, the crisis coordination body for the Italian financial centre. The outage exposed the chain Milan firms must now map: a bank, a payment processor, a network provider, and a subcontractor’s physical cable. A CMDB that Milan teams can rely on for DORA compliance starts by recording those relationships before an incident forces the question, and Banca d’Italia expects the next register of information by 15 March 2027, with a 31 December 2026 reference date. A CMDB is where that record begins.

Where DORA and PCI DSS ask Milan firms the same question

Both frameworks ask what exists, what connects to what, and how often the answer is confirmed. One maintained record can answer all three for both audiences.

The text of Regulation (EU) 2022/2554 sets the DORA duties, and PCI DSS v4.0.1 sets the card requirements. The PCI Security Standards Council states that the future-dated v4.x requirements, including 12.5.2, took effect on 31 March 2025. The PCI scope explanation from Cloud Security Alliance lists what a 12.5.2 scope confirmation must cover, from data-flow diagrams to third-party connections.

PCI DSS applies to entities that store, process or transmit cardholder data. Banks with issuing or acquiring activity usually carry substantial scope. Many capital markets firms carry limited card scope, so DORA is usually their main driver. A 12.5.2 scope confirmation covers more than a list of servers. It includes updated data-flow diagrams, every location where account data is stored, processed or transmitted, and all system components in or connected to the cardholder data environment. It also covers segmentation controls with their justification and every third-party connection that has access. Significant change triggers a fresh confirmation. The standard’s examples include new hardware or software, changed data flows, and changes to service providers that support in-scope systems. Such changes occur frequently in a large estate, so a yearly spreadsheet exercise falls behind quickly.

Teams that want more context on overlapping obligations can read about IT asset management for financial services compliance and the PCI DSS compliance requirements.

Who supervises what in Italy

Legislative Decree 23/2025, in force from 12 March 2025, adapts Italian law to DORA. It designates Banca d’Italia, Consob, IVASS and COVIP as competent authorities. Banca d’Italia covers banks, payment institutions and intermediaries. Consob covers markets and investment services. IVASS covers insurers, and COVIP covers pension funds. The decree also names CSIRT Italia, the national cyber incident response team, within the national cybersecurity agency.

Register quality is now a board question

Article 5 of DORA places ultimate responsibility for ICT risk with the management body. For a CIO or head of technology risk, the register of information is therefore a document the board answers for. Exposure and accountability sit at the same table.

The first evidence of how hard the register is comes from the European Supervisory Authorities’ dry run. Of 947 registers analysed, only 6.5% passed every data quality check. Half of the remaining registers failed fewer than five of the 116 checks, and the worst entity failed 43. Integration checks ran first, and a failed submission was discarded without further processing. Feedback also stressed the importance of correct identifiers. Missing mandatory data fields were the most common error. The exercise ran on a best-efforts basis, and partial registers were allowed, so the figures describe a rehearsal and a final submission carries higher expectations.

A Deloitte survey of financial entities across 28 countries found that 46% of surveyed entities named the register of information the most challenging DORA task. The same survey reports that only 8% of participants achieved full compliance in digital operational resilience testing, and only 8% in third-party risk management. Third-party risk depends on knowing which providers support which functions, and that knowledge sits in dependency data. The sample is modest, and the findings still match the dry-run results.

The register also feeds supervision above the national level. The European Supervisory Authorities collected data from financial entities’ registers before they designated the first critical ICT third-party providers on 18 November 2025. The designation also weighed each provider’s systemic importance, its role in supporting critical or important functions, and the substitutability of its services. Every Milan submission contributes to that EU picture.

Banca d’Italia set the annual submission deadline at 15 March, with data as of 31 December of the previous year. In its February 2026 communication, the authority states that submitted registers undergo data quality checks. Where anomalies appear, it asks firms to correct the errors and resubmit.

These figures describe register data quality, which is mostly a field-completeness problem. A CMDB feeds the asset and dependency layer behind the register, and contract fields remain a procurement and legal task.

Four places the evidence breaks before a supervisor asks

Each of these gaps applies where the register is assembled from separate sources by hand.

1. Contracts and assets sit in separate systems. The register is built from contract data, while assets are tracked in spreadsheets. Tracing the chain from business function to service to provider takes days by hand, so exposure questions take days to answer.
2. The inventory is refreshed only for the annual submission. The deadline falls on 15 March with a 31 December reference date, so teams assemble the inventory once a year, leaving a record that describes year-end rather than the estate running today.
3. Provider-of-provider dependencies sit outside the relationship record. The Worldline chain is the example, where the subcontractor sat behind the processor that banks and merchants relied on, so during an incident, the first hours go to establishing exposure before any response can start.
4. DORA and PCI teams keep separate inventories. Each team builds its own list of systems and its own scope boundary, so two answers appear to whether a system is in scope, and reconciliation repeats before every review.

CMDB for DORA compliance in Milan: what discovery-sourced data adds

A CMDB sits upstream of compliance work. It supplies the asset and dependency evidence that compliance, risk, and security teams use in their own processes. Three capabilities carry that evidence to compliance teams.

1. High-frequency scheduled discovery. IT discovery scans network-connected infrastructure and cloud accounts on a set schedule, and each cycle updates the CMDB. New instances, retired hosts, and changed configurations enter the record on the next cycle. Teams choosing a collection method can compare options in this guide, including agentless and agent-based discovery.

2. ViVID™ service maps. Service mapping builds the dependency map once service definitions are supplied by hand, by import, or through an integration. The map holds the interdependency data that Article 8 describes. It also holds the data-flow and connection scope that Requirement 12.5.2 asks teams to confirm. Readers who want the operational case can read why service mapping matters.

3. ITSM integration. Virima syncs with ServiceNow, Jira Service Management, Ivanti, Cherwell, and other ITSM platforms, so the record sits where change and incident work already happens. Governance practices for that shared record are covered in CMDB governance practices. The full list of supported connections sits on the integrations hub.

Where a CMDB stops, and other tools take over

Contract fields, legal entity identifiers, exit plans, and costs live in procurement and third-party risk tools. The CMDB supplies the asset and dependency layer those tools link to.

Data classification belongs to data loss prevention tooling. A CMDB maps the paths where data flows, and a DLP tool classifies the data travelling along them.

Discovery covers network-connected infrastructure and cloud or SaaS accounts. Browser-side payment-page scripts, which PCI DSS addresses in requirements 6.4.3 and 11.6.1, need a dedicated script-monitoring control.

A CMDB supports DORA and PCI DSS work by supplying the evidence layer. The compliance decisions stay with the people and processes that own them.

Four situations where Milan teams need the map fast

These scenarios show how the map gets used day to day:

• A provider outage. A query shows which critical or important functions touch the affected provider. The team starts from a list of services instead of a war room.
• Ahead of 15 March. The discovered inventory is compared with the register’s function and service mapping before submission. Gaps surface while there is still time to correct them.
• A cloud workload moving near the cardholder data environment. The next discovery cycle picks up the new instance. The dependency map shows whether it sits inside or beside the documented path, which is a Requirement 12.5.2 trigger.
• A capital markets platform. The dependency chain from a trading platform to its market-data and clearing providers appears as relationships. Risk teams can follow each link when a provider reports a problem.

Milan teams can compare this approach with a London view of the same problem in the FCA operational resilience post.

Five steps before the next 15 March submission

The first benefit arrives quickly, because exposure questions get faster answers from a single record. Scope confirmation then becomes a controlled comparison between discovered and documented systems. Over time, the record produces evidence that teams can reproduce after the next change.

1. List your critical or important functions. Use the classification already recorded under DORA.
2. Run discovery and compare the result. Check it against the register and the PCI inventory, and log every difference with an owner.
3. Build dependency maps for those functions. Supply the service definitions, and let the mapping draw the relationships.
4. Connect the CMDB to ITSM and to third-party risk tooling. Change, incident, and contract work then reference the same assets.
5. Set a review cadence. Align it with the 15 March submission and with PCI DSS Requirement 12.5.2. This guide to CMDB audit essentials covers the evidence reviewers ask for.

One annual review instead of two

Both frameworks require a yearly confirmation, so the two calendars can share one cycle. The DORA register carries a 31 December reference date, and a discovery run just before that date gives both teams the same inventory. The team compares the discovered assets with last year’s classification, and any unclassified asset surfaces during the Article 8 annual review. Each difference receives an owner and a decision. The same comparison feeds the PCI scope confirmation, and service providers repeat it every six months under Requirement 12.5.2.1. One reviewed record replaces two parallel reconciliations.

See the dependency map on your own estate

To see how ViVID™ builds dependency maps from discovered infrastructure, start with the service mapping overview.

Frequently Asked Questions