Why Amsterdam’s Banks Can Pass a DORA Audit and Still Fail Their CMDB

When De Nederlandsche Bank and the Dutch Authority for the Financial Markets collect the annual Digital Operational Resilience Act (DORA) Register of Information, Amsterdam-based banks treat the submission window as a hard calendar event. For the 2026 cycle, the AFM asked firms under its remit to deliver a complete register in xBRL-CSV no later than 22 March 2026, after a formal request in December 2025, and made clear that incorrect formats would force a fresh file instead of a quiet conversion favour. Both AFM and DNB collect registers in the Netherlands and forward them to the European Supervisory Authorities so critical ICT third-party providers can be designated. The earlier ESA dry-run summary already showed how quickly data-quality feedback multiplies resubmission work across nearly a thousand entities. Boards that clear format checks still face a quieter failure mode: the configuration management database (CMDB) that should feed the register drifts between cycles, so the file that passes validation no longer matches the estate operators run every night.

What a DORA Audit Actually Checks

Supervisors and the European Banking Authority (EBA) tooling primarily verify that the register exists, that mandatory fields are populated, and that the submission follows the Implementing Technical Standards taxonomy and validation rules. The AFM Register of Information process accepts xBRL-CSV packages with a strict naming convention, then relays EBA data-quality feedback so firms can correct and resubmit. Those checks prove documentation discipline and reporting hygiene while leaving open whether every configuration item (CI) in the bank’s CMDB still matches live hosts, contracts, and service paths on the day the zip file is uploaded.

That distinction sits at the centre of the operating tension for Amsterdam institutions. A register can score well on technical checks while the underlying inventory still holds decommissioned appliances, missing third-party hops, or owner fields that stopped tracking after the last reorganisation. Audit packets built from spreadsheets and last-quarter exports often look complete in the portal. Operations teams still open incidents against CIs that no longer exist, or discover vendor dependencies that never entered the register in the first place.

DORA’s official text, Regulation (EU) 2022/2554, sets the ICT risk-management and third-party framework financial entities must implement. Supervisory collection of the Register of Information is the annual proof point for contractual ICT arrangements. Clearing format validation is the mandatory filing step. Keeping a living asset and dependency record is the operational condition that makes the next filing cycle less painful.

The Gap Between a CMDB and an Article 8 Asset Register

Article 8 of DORA requires financial entities to identify, classify, and document ICT assets and supporting information so ICT risk management has a factual base. The Register of Information that AFM and DNB collect is the contractual and third-party lens of that broader identification duty. A CMDB is the operational system of record for configuration items, relationships, and change history. The two layers must join in daily operations so identification work and runtime operations share one factual base.

A CMDB that only stores static host lists will starve the register of dependency and ownership truth. A register built only from procurement folders will starve operators of runtime context when an outage starts. The durable pattern is discovery-sourced CI truth feeding both operational workflows and the compliance extract. Teams that treat the CMDB as a filing cabinet for last year’s audit pack recreate the same reconciliation scramble every March.

A healthy CMDB supports Article 8 identification work as upstream infrastructure under a complete DORA programme, a finished Register of Information, and legal ownership of third-party contracts.

What’s at Stake for Amsterdam’s Boards and Compliance Teams

Amsterdam sits at the centre of Dutch prudential and conduct supervision. DNB and AFM share collection of Registers of Information and forward quality-checked files toward the EBA, EIOPA, and ESMA designation process. That dual-oversight model means ICT asset and third-party data quality is visible to more than one national desk, then to European authorities that use the same registers to identify critical ICT third-party providers.

NautaDutilh has spelled out how DORA makes the management body explicitly responsible for ICT risk-management arrangements, strategy, continuity plans, third-party policy review, and board-level knowledge of ICT risk. Under Dutch corporate law, management and supervisory board members already carry collective responsibility for the general course of affairs. Failures in ICT risk governance can factor into suitability screening by Dutch regulators and into mismanagement analysis when serious reproach is assessed. Board training, clear ICT roles, and reporting lines on major incidents and critical third-party arrangements are therefore standing operating requirements for every management body in scope.

Penalty headlines often compress DORA into a single EU-wide turnover percentage. Article 50 leaves administrative penalties for financial entities to each member state under an effective, proportionate, and dissuasive standard, so national regimes diverge. A separate EU-level figure applies to designated critical ICT third-party providers under the oversight framework. Compliance and legal teams in Amsterdam should track Dutch transposition and supervisory practice and avoid pasting a generic percentage into board packs.

Where DORA readiness breaks in practice

1. Register fields outrun estate truth. Contract tables list providers while discovery still misses shadow instances and unregistered network paths that support critical functions. Result: Validation may pass while incident bridges still hunt for owners.
2. Annual extract without interim ownership. A March submission freezes a snapshot; cloud and vendor change continues every week. Result: The next cycle opens with a full rebuild instead of a controlled delta.
3. Format success hides relationship gaps. xBRL-CSV checks confirm structure; service interdependencies remain tribal knowledge in runbooks. Result: Critical-function mapping stays incomplete when supervisors or internal audit ask for blast radius.
4. Board reporting without CI evidence. Risk committees receive green status on “register filed” while CMDB stale rates stay high. Result: Personal accountability rises without an operational control the board can inspect.

Trusted runtime truth, the live explainable record of what exists, how it connects, what changed, and who owns it, is the practical bridge between those failure modes and a register the bank can defend. Explore how Virima frames that layer at Trusted Runtime Truth.

What an Inaccurate Asset Register Costs, by Role

For CIOs and boards. Supervisory questions land on the management body that already owns ICT risk framework approval and oversight. Incomplete asset and dependency evidence lengthens supervisory dialogue, increases the chance of follow-up information requests, and weakens the narrative that digital operational resilience is under control. When an incident hits a path missing from the register, the reputational and operational cost arrives faster than the next filing window.

For CMDB owners and IT operations. Each annual cycle becomes a project: reconcile spreadsheets, chase application owners, merge vendor lists, and hand a fragile file to compliance. High manual effort crowds out change quality work. Stale CIs inflate false incident assignments and slow restore work because the clock starts on the wrong object.

For regulated entities under DNB and AFM. The AFM’s 2026 process requires firms to submit xBRL-CSV themselves, with resubmissions welcomed through a defined correction window when EBA feedback arrives. The ESAs’ dry-run summary showed that only a small share of registers passed every data-quality check on first analysis, while many others failed a handful of rules among more than a hundred checks. Plan for feedback loops and treat data quality as standing work. Entities that rebuild the register from cold sources each year absorb overtime and delayed confidence from risk committees.

IT asset management in financial services already has to support overlapping regimes such as DORA-oriented resilience and PCI-related inventory expectations, so an inaccurate register multiplies work across programmes that sample the same base. Flexera’s 2026 State of ITAM reporting continues to show how few organisations claim complete IT asset visibility even as spend and complexity rise.

Three Ways Automated Discovery Closes That Gap

Automated discovery leaves legal contract management and Register of Information filing with compliance and risk owners. It closes the operational gap between what the estate runs and what the register claims.

1. Discovery populates and refreshes CI records. Agent-based, agentless, and API methods pull hardware, software, and cloud objects into a governed CMDB on a high-frequency scheduled cadence. Owners gain last-seen evidence instead of annual spreadsheet archaeology. Virima documents that feed pattern under IT discovery.

Banks that stop at host lists still miss the path risk that shows up in change windows and major-incident bridges. Interdependency evidence has to sit next to the CI record before Article 8-style identification work is useful to operators and to the people who build the register extract.

2. Service maps capture interdependencies plain CMDBs often miss. Once service definitions are supplied, ViVID™ builds dependency maps that show installed-on, runs-on, exchanges-data-with, and related paths operators need for change and incident decisions. Article 8-style identification work needs those links when critical or important functions span on-premises cores and cloud edges. Service mapping turns isolated CIs into defendable service context.

3. Change and audit trails support annual review. CMDB-backed change history shows what moved since the last register extract, which CIs were retired, and which relationships were added after a release. That trail shortens the question about what changed since last March. CMDB support for change management keeps CAB packets aligned to the same record compliance will sample.

CMDB automation matters here because scale defeats heroic cleanup. Banks with thousands of CIs cannot staff a permanent reconciliation war room between every supervisory ask.

What This Looks Like Inside a Compliance Cycle

Consider an illustrative mid-size bank headquartered in the Amsterdam region with a hybrid estate: core banking on private infrastructure, customer channels on cloud, and a long tail of ICT vendors. Ninety days before the AFM or DNB submission deadline, compliance opens the prior register and asks technology for confirmation. Without discovery authority, application owners return partial lists, network teams export switch inventories by hand, and cloud tags disagree with the CMDB. Two weeks before filing, a conversion tool produces xBRL-CSV; validation flags LEI and relationship issues; nights go to cleanup.

With discovery-sourced CMDB and service maps already running, weekly scheduled discovery has refreshed CI classes, exception queues hold unmatched contracts, and service maps show which infrastructure supports critical payment and customer functions. Compliance runs a controlled extract and spends effort on third-party diligence. When EBA-style feedback returns through the national portal, corrections target data fields instead of an entire unknown estate.

The scenario is illustrative and still matches the operating pattern Dutch supervisors describe when they stress correct format, data-quality feedback, and annual reuse of the register for European designation work.

The Discovery Layer Virima Adds Beneath the Asset Register

Virima sits beneath the Register of Information as a discovery, CMDB, mapping, and ITAM layer, while legal and compliance keep DORA programme design, contract clauses, and portal submission. Technology gains an authoritative feed so those programmes stop arguing with stale inventory.

Immediate operational impact

High-frequency scheduled discovery reduces blind spots across data centres, endpoints, and cloud accounts the bank already runs. Where product scope applies, NIST-oriented vulnerability context on Windows Server can overlay service maps so risk conversations stay tied to owned CIs. Incident and change teams share one configuration backbone with compliance extracts.

Long-term accuracy and tool fit

Promotion rules, ownership fields, and relationship guards keep the CMDB from decaying after the first successful filing, so annual register work becomes a delta exercise and boards can evidence ongoing ICT asset identification. Virima feeds ITSM and adjacent platforms while leaving service-desk choice with the bank. Partner names stay plain in the integration fabric teams already selected; connect through the integrations hub. ITOM capabilities unify discovery, CMDB, ViVID™ service mapping, and ITAM views without asking Amsterdam teams to abandon platforms staff already know.

From Spreadsheet Registers to a Living Asset Record

Moving from spreadsheet registers to a living asset record is a two-change programme: change how inventory is collected, and change how inventory is governed.

Benefits cascade in a straight line: fresher CIs improve incident routing, clearer dependencies improve change success, cleaner extracts shorten Register of Information preparation, and stronger evidence improves board and supervisory conversations about ICT risk.

Getting started

1. Scope critical and important functions first. Name the business services DORA already forces you to prioritise.
2. Stand up discovery against that scope. Cover on-premises, cloud, and network classes that support those functions.
3. Define services, then build maps. Supply service definitions; let mapping automation draw runtime relationships.
4. Bind ownership and exception handling. Every unmatched CI needs an owner and a time-bounded queue.
5. Rehearse the extract. Produce a register-shaped export months before the portal deadline and fix quality issues early.

ITIL-aligned configuration management practice and IT asset management process discipline keep the operating model stable after the first filing success.

Where to Start

Amsterdam banks already know how to file. The next resilience step is keeping the estate record as disciplined as the xBRL-CSV package. Build discovery-sourced CMDB and service-map truth under the Register of Information so March stays a controlled extract instead of an inventory emergency. When your team is ready to see that layer on your own hybrid estate, schedule a demo with Virima and walk the path from scheduled discovery to a living asset record your board can stand behind.

Frequently Asked Questions