Introduction
DORA's headline requirements - incident reporting, resilience testing, ICT risk management - get most of the attention. The Register of Information gets far less, and it is quietly one of the hardest requirements to satisfy well. Every in-scope financial entity must maintain a complete, structured, continuously updated register of all its ICT third-party service providers, mapped to the specific functions each one supports, the criticality of those functions, and the contractual terms governing the relationship. Firms that consider themselves DORA-compliant because they have passed resilience testing frequently discover, on closer inspection, that their Register of Information is incomplete, stale, or inconsistent with what their actual vendor relationships look like.
Why the Register Is Harder Than It Looks
It has to reflect reality, not procurement's record of reality
Most financial institutions already maintain some form of vendor inventory through procurement or vendor management systems. The Register of Information demands more: a structured mapping between each third-party provider and the specific business function it supports, including subcontracting chains where a critical vendor itself relies on further subcontractors. Procurement records typically capture the commercial relationship - who signed the contract, what it costs - not the operational dependency chain DORA requires, which means the register frequently has to be built as a new artifact rather than repurposed from an existing system.
It has to stay current, not just accurate at submission
Regulators expect the Register of Information to be maintained as a living document, updated as vendor relationships change, not refreshed once ahead of a supervisory request. A register that was accurate at its last submission but has not tracked subsequent contract renewals, subcontracting changes, or newly onboarded critical vendors will not satisfy an examiner looking for evidence of ongoing maintenance, even if the original submission was technically complete.
What Falling Short Actually Looks Like in Practice
- Critical function mapping that hasn't been updated since a vendor's contract was last renewed with expanded scope
- Subcontracting chains that are known informally within the vendor management team but never captured in the register itself
- Multiple business units maintaining separate, inconsistent vendor records rather than one authoritative register
- Criticality classifications that were set once during initial DORA implementation and never reassessed as usage patterns changed
Turning the register into evidence, not a spreadsheet
The firms handling this best are treating the Register of Information less like a document and more like a continuously synchronized record - one that updates automatically as contracts change and vendor relationships evolve, with a verifiable history of when each entry was added or modified. That approach converts the register from a compliance artifact assembled ahead of an examination into a live source of truth that can be produced, with evidence of its own currency, on demand.
A Register of Information that only holds up when nobody asks how current it is isn't compliance - it's a snapshot waiting to be outdated. See how ROOTKey keeps third-party risk evidence continuously current and verifiable.
Recevez nos analyses sur la cyber-résilience par e-mail
Des conseils pratiques et prêts pour l'audit sur l'intégrité des données, la conformité et la continuité - dès leur publication.