Compliance & Privacy · 2026-10-05

DORA Evidence Ownership: Who Assembles Each Register Field Before a Q1 Review

By J. W. Bouckaert

The register is a spreadsheet with a supervisor on the other end

Regulation (EU) 2022/2554 has applied since 17 January 2025. Article 28(3) requires every financial entity to keep a register of information covering all contractual arrangements for ICT services, at entity, sub-consolidated and consolidated level, distinguishing the arrangements that support critical or important functions from those that do not, and to hand the whole register or any section of it to the competent authority on request. Commission Implementing Regulation (EU) 2024/2956, adopted on 29 November 2024, fixed its shape: fifteen templates coded B_01.01 to B_07.01 plus a terminology sheet, B_99.01, submitted as plain csv and validated by the European Supervisory Authorities against a data point model.

The earlier post on Article 28 covers what the register must contain and why an identity stack is an awkward fit for it, since the carriers whose telemetry a step-up decision depends on sit two or three contracts below the one the bank signed. This post is about the other half of the problem. The templates do not care which department fills them in, and the first two reporting cycles show that this is exactly where registers fail.

The numbers from the first two cycles

The ESAs ran a voluntary dry run in 2024. Their summary report of 17 December 2024 says 1,039 financial entities took part, covering 3,447 entities once groups are counted, and that of the 947 registers that passed the technical integration checks, 6.5 percent passed every data-quality check. Missing mandatory information accounted for 86 percent of all data errors; 60 percent of the missing values sat in B_02.02, the template that describes each contractual arrangement, and 20 percent in B_07.01, the assessment of services supporting critical or important functions. Invalid legal entity identifiers ran to about 9,000 for financial entities and 6,000 for providers.

The first live collection followed in 2025, with competent authorities forwarding registers to the ESAs by 30 April against a reference date of 31 March. The ESAs' published observations from that round list the most common errors in order: foreign-key violations, which reject the file; missing mandatory values; missing primary keys, which also reject; wrong filing indicators; wrong LEIs; and European Unique Identifiers that the business registers interconnection system could not find. The ESAs used those registers to designate nineteen critical ICT third-party providers between April and November 2025.

The 2026 cycle moved to the steady-state calendar: reference date 31 December 2025, competent authorities to the ESAs by 31 March 2026, and national deadlines set earlier by each authority, as the Netherlands did in 2025 with a date a week ahead of the ESAs'. Luxembourg's CSSF opened its 2026 window on 11 February and added a warning worth taping to the wall: the checks now cover more fields, so "a register of information which was accepted last year, may be rejected this year".

The next reference date is 31 December 2026. A register that is assembled in the first quarter of 2027 from whatever the contracts say is the register that fails the ESAs' checks. One assembled from named owners who each hold their evidence by the end of the year is the one that passes, and the difference between the two is a sequence rather than a tool.

Every field has a natural owner, and it is rarely compliance

The register is built from four kinds of fact, and each kind lives with a different function.

Facts about the contract live with procurement and legal. The unique contractual arrangement reference number that B_02.01 requires and that every row in the supply-chain template B_05.02 has to repeat; the signing entities in B_03.01 and B_03.02; the notice periods and termination reasons in B_02.02; the governing law; whether subcontracting is permitted and on what conditions, which Article 30(2)(a) requires the contract to say. None of this can be derived by a compliance team from the outside, and the 2025 error list shows what happens when it is: a foreign key that does not resolve, because the reference number in one template was typed differently from the one in another.

Facts about the service live with the technology owner who runs the integration. The service type from Annex III, where the nineteen codes run from S01 to S19 and none of them is identity, authentication or access management, so an identity provider is entered under what its service is: S04 for ICT security management services, S19 for a hosted service, S05 where carrier lookups are bought as a data feed. The FAQ is explicit that each entity assesses the type itself and adds a row per type. The countries of provision, of data storage and of data processing, which B_02.02 requires for every arrangement that supports a critical or important function and which Article 30(2)(b) requires the contract to state; the FAQ offers no "EU" option, so a provider that runs in several member states needs a row per country.

Facts about the function live with the business owner of the function. B_06.01 records whether the function is critical or important, the date the assessment was made, the reasons, the recovery time and recovery point objectives in hours, and the impact of discontinuing it. The template accepts "assessment not performed" and a date of 9999-12-31 as answers, and a register full of those is a register that tells the supervisor the entity has not done the work Article 28 assumes.

Facts about the risk live with the third-party risk function. B_07.01's substitutability field takes one of four values (not substitutable, highly complex, medium complexity, easily substitutable), with the reasons drawn from a closed list that includes the lack of real alternatives on a market and the difficulty of migrating data and workloads; the date of the last audit of the provider, again with 9999-12-31 for never; whether an exit plan exists; and how hard reintegration would be. Article 30(3)(e)(i) gives the entity unrestricted audit rights and 30(3)(f) requires exit strategies with an adequate transition period, so these fields are where a supervisor checks that the contract clauses are being used.

The identifiers cut across all four. Article 3(5) of the ITS requires a valid and active LEI or EUID for every provider that is a legal person, extended through the direct provider to every subcontractor that underpins a critical or important function; a non-EU legal person can be identified by LEI only; the financial entity itself by LEI only. The validation layer checks LEIs against GLEIF and EUIDs against the business registers system, and an identifier that fails either check is a finding the entity cannot argue with. Somebody has to own the identifier for every row, and the dry run's 15,000 invalid ones say that in 2024 nobody did.

The identity stack, field by field

The table below is the identity-specialised extract: the fields that an identity provider, its carrier-signal subcontractors and a KYC vendor generate, with the owner who holds the evidence and the artefact that proves the value. It follows the ITS column names.

Two rows deserve a note. The carrier layer's substitutability is structural: a mobile network operator is the only source of truth for its own subscribers' SIM state, so within a country it is not substitutable, and the honest value in B_07.01 says so. And the identifiers for that layer come from the direct provider, since the entity has no contract with the operators; Article 3(6) of the ITS routes the request through the direct provider, which means the identity vendor's disclosure of its own chain is a register input rather than a courtesy. That is what the sixth of our contract clauses is for.

An assembly sequence that ends before the reference date

The reference date is 31 December. Working back from it:

October. Legal confirms the contract list is complete and that every arrangement has a reference number that will not change. Terminated contracts come out; the FAQ confirms they are not required. Procurement lists every new arrangement of the year for the Article 28(3) annual notification, which is a separate obligation from the register itself.

November. Third-party risk sends each direct provider a dated request for three things: the current subcontractor chain with identifiers, the hosting and processing countries, and any change to the exit terms. The answers are the evidence for B_05, B_02.02 and B_07.01; a provider that cannot answer is a finding in its own right. Internal audit confirms the last-audit dates, or records that an audit right was requested and when.

December. Business owners re-date the criticality assessments and refresh the RTO and RPO figures from the continuity plans, so that no B_06.01 row carries 9999-12-31 by accident. The integration owner confirms the service types and country rows against the provider answers. The DPO reconciles the data-location rows with the records of processing.

January. Compliance assembles the file and runs it against the ESAs' published validation rules and the national authority's checks before anyone signs it. The ESAs' own guidance is that a file with no findings is not thereby accepted, so the internal pass is a floor, and the CSSF's warning means last year's clean file is not evidence for this year's.

February and March. Submission inside the national window, which the FAQ says may close earlier than the ESAs' 31 March. The evidence pack behind the file, the provider answers, the GLEIF lookups, the assessment minutes, the audit correspondence, is filed with it, because Article 28(3) lets the authority ask for the register at any time and the same owners will be asked the same questions.

The return on the sequence

The dry run's headline figure, 6.5 percent of registers passing every check, is the figure for registers assembled by one team from documents written by others. The 2025 error list, foreign keys and missing mandatory values at the top, is the list of what breaks when the reference number lives in one system and the supply chain in another. Naming an owner per field turns each of those errors into a question that has an answer and a person to ask it of, and it puts the evidence where a supervisor's request under Article 28(3) will land, which is with the people who know.

For an identity stack the sequence also settles something the templates cannot express: that a step-up decision the bank makes in 200 milliseconds depends on a chain the register can only describe once a year. The register is evidence that the chain is known; the assurance platform is where the chain is watched between reference dates.

Start free · Test the API