DORA Requires Financial Entities to Prove ICT Data Lineage

The Digital Operational Resilience Act asks a question most financial institutions cannot answer with confidence: which systems, vendors, and data flows would take down a critical function if one of them failed. DORA's Register of Information requires EU financial entities to maintain a current, auditable map of every ICT third-party dependency tied to a critical or important function. A spreadsheet updated at renewal time does not meet that bar, and neither does a catalog that only shows where data lands.

DORA took effect in January 2025, and 2026 has become the year regulators start comparing what firms filed in their Register of Information against what actually runs in production. That gap, between the documented dependency map and the real one, is where compliance risk concentrates. This post covers what the Register of Information actually demands, why most ICT mapping efforts fall short, and what a defensible, code-derived version of that map looks like.

What DORA's Register of Information Actually Demands

The Register of Information is not a one-time questionnaire. It requires financial entities to maintain a continuously accurate inventory of ICT third-party service providers, the specific functions each one supports, and whether that function is critical or important to the business. Entities must be able to show, on request, how data moves into, through, and out of each of those dependencies, not just that a contract exists with the vendor.

That requirement sits on top of a harder operational reality. A single critical function, loan origination, claims processing, trade settlement, typically touches application code, one or more data platforms, several transformation pipelines, and multiple third-party APIs before it produces an output. Proving the dependency map behind that function means tracing all of it, not just the vendor relationships that show up in procurement records.

Where Most Financial Institutions' ICT Mapping Breaks Down

Most Register of Information efforts start from contracts and manually maintained architecture diagrams. Both go stale the moment a team ships a change that was not routed through the documentation process, which is most changes. The result is a register that reflects what the ICT dependency map looked like at its last review, not what it looks like today.

Deterministic lineage is a complete, code-derived record of how a specific piece of data moved and transformed across every system it touched, verified from the actual source code and metadata rather than inferred from documentation. Unlike a manually maintained diagram, deterministic lineage updates whenever the underlying code changes, because it is built from that code directly.

What Good Looks Like

A defensible Register of Information is backed by lineage that comes from the code itself, not from the last time someone updated a diagram. Foundational analyzes application code, transformation pipelines, established systems, and the API calls embedded in them to build a deterministic map of every ICT dependency tied to a critical function, including which third-party services touch which data and through what code path. When an examiner asks for evidence, the answer comes from a live, code-verified graph instead of a document that needed to be re-created for the request.

This is the same proactive governance model that has held up under audit pressure elsewhere in financial services. Vio saw a 52 percent reduction in potential data issues and a 37.5 percent faster development cycle time after adopting code-derived lineage, evidence that mapping dependencies at the source, rather than after the fact, changes both the audit outcome and the pace of engineering work. Analyst coverage points the same direction: Forrester's 2026 predictions single out governance and trust as decisive factors in scaling any technology reliably, DORA's ICT risk requirements included.

Frequently Asked Questions

What is the DORA Register of Information?
It is a mandatory, continuously maintained inventory that EU financial entities must keep of their ICT third-party service providers, mapped to the specific critical or important functions each one supports. It has to reflect current reality, not a point-in-time snapshot, and entities must be able to produce it on request from regulators.

Does DORA apply to data lineage specifically, or only to vendor contracts?
DORA's ICT risk management requirements extend past contracts into how data actually flows through third-party dependencies. Proving compliance means showing the data path behind a critical function, not just confirming a vendor relationship exists on paper.

Can a data catalog satisfy DORA's mapping requirement?
A catalog can show where data is stored. It generally cannot show the application code, transformation logic, or embedded third-party API calls that moved the data there, which is the part of the map DORA examiners are most likely to test against production reality.

How often does an ICT dependency map need to be updated to stay compliant?
DORA expects the Register of Information to reflect current operations, not a periodic snapshot. A map built from source code analysis updates automatically as the underlying code changes, which is the only practical way to keep a large ICT estate continuously accurate rather than accurate only on the day it was last reviewed.

Get a Defensible ICT Dependency Map

DORA examiners are starting to test filed registers against production reality, and a manually maintained diagram will not hold up to that scrutiny. See how Foundational builds a code-derived, audit-ready map of every ICT and data dependency in a demo, or read how the same source code analysis approach applies to CCAR and BCBS 239 compliance in banking.