DORA Register of Information: The Supplier's Field-by-Field Guide | MatchAudit Learn
DORA Register of Information: The Supplier's Field-by-Field Guide
Every EU financial customer has to file a DORA register of information each year, and it is built from data only you can give them. A field-by-field reference for suppliers: the 15 templates of CIR (EU) 2024/2956, the fields in B_05.01, B_02.02, B_05.02 and B_07.01, the full S01–S19 Annex III service taxonomy, the annual calendar, LEI and EUID pitfalls, and a reusable supplier data pack.
•33 min read
Last reviewed: 25 September 2026. This article explains a regulatory reporting process from the supplier's point of view. It is not legal advice, and it does not tell you how your customer should classify your service — that decision is theirs.
Quick answer: The DORA register of information is a structured annual filing that EU financial entities must make about every contractual arrangement they have for ICT services. You, as their supplier, are not the filer — but a large share of the data in it is about you, and only you can supply it accurately. Under Commission Implementing Regulation (EU) 2024/2956, the register is made up of 15 inter-linked templates. Your customer needs your legal name, your active LEI or EUID, your ultimate parent's identification code, your headquarters country, the exact Annex III service-type code (S01–S19) for what you sell them, the countries where the service is provided and where data is stored and processed, your notice period, and — for services supporting a critical or important function — the ranked chain of your subcontractors. Get it wrong and your customer's filing fails validation, comes back to you, and is re-asked every single year. Get it into a reusable, dated pack and it becomes a short annual task instead of a fire drill.
Why a filing you don't make keeps landing on your desk
If you sell software, infrastructure, data, or IT services to a bank, insurer, payment institution, investment firm or crypto-asset service provider in the EU, you have probably received a spreadsheet at some point between January and March with a tab full of codes like B_05.01.0080 and a short, slightly apologetic email asking you to fill it in by Friday.
That spreadsheet is your customer's register of information under the Digital Operational Resilience Act. Here is the part that is easy to miss and expensive to misunderstand:
The obligation is theirs. The data is yours. Article 28(3) of DORA (Regulation (EU) 2022/2554) requires every in-scope financial entity to maintain and update a register of all contractual arrangements for ICT services, and to make it available to its supervisor. Nothing in that article obliges you to do anything. But the register cannot be completed without facts that exist only inside your company: your ultimate parent's identity, the country your service is actually delivered from, where data sits at rest, who your subcontractors are and in what order they sit in the chain.
So the obligation flows downhill as a request. And unlike a security questionnaire, it is not a one-off:
A security questionnaire is asked once and re-asked on renewal. The register of information is asked every year, by every EU financial customer you have, against a fixed reference date, in a format that is machine-validated.
That last clause is what changes the character of the work. Supervisors run automated validation against the submission. A free-text answer that a human reviewer would have accepted — "EU/EEA", "various", "our group HQ" — fails a validation rule, and the failure bounces straight back through your customer to you, usually with less time remaining than the first request had.
You are not "DORA compliant" and you cannot be. DORA obligations apply to financial entities, and to a small number of providers formally designated as critical (see below). If a supplier tells you they are "DORA certified", treat it as marketing. What you can be is accurate, fast and consistent when your financial-entity customers ask — which is the thing that actually affects whether your contract gets signed and renewed. Our companion guide, DORA for ICT Vendors, covers the wider set of contract and due-diligence effects.
What the register actually is, in plain terms
Think of it as a relational database that your customer has to hand their supervisor once a year, describing their ICT supply chain.
It is not a document. It is a set of 15 linked tables, standardised across the whole EU by Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 — the implementing technical standards on standard templates for the register of information. Every table has fixed field codes, fixed data types and fixed permitted values. The tables join to each other through keys: a contractual arrangement reference number, an identification code for the provider, a function identifier.
Three consequences follow from that design, and all three land on you:
One record per contractual arrangement, not per supplier. If your customer has three separate contracts with you — the core platform, a managed-services addendum, a data feed — that can be three sets of entries, each needing its own service type, dates and data-location answers. "We already sent you this last year for the other contract" is not an answer the format can absorb.
Codes, not prose. Country is an ISO 3166-1 alpha-2 code. Service type is one identifier from a closed list of 19. Yes/no fields have defined enumerations. Anything you send as a sentence has to be translated by someone at your customer who is guessing at your meaning.
Joins break loudly. If the identification code you give for your entity in one place does not match the one used elsewhere in the register — or does not match the global LEI database — the failure is not confined to that one cell.
How hard is that in practice? In the ESAs' 2024 dry run, almost 1,000 financial entities submitted a register. 6.5% passed all the data quality checks. Half of the rest failed fewer than 5 of the 116 checks applied — in other words, most entities were close, and were tripped up by a small number of specific, repeatable errors (ESAs dry run summary). A meaningful share of those errors sit in fields that only the supplier can answer.
The annual cycle: dates you can plan around
This is the part worth bookmarking, because the shape of the year repeats.
Stage
What happens
Typical timing
Reference date
The register must reflect all contractual arrangements in place as at this date. For the 2026 cycle the reference date was 31 December 2025.
31 December
Supplier data requests go out
Financial entities reconcile their contract inventory and chase suppliers for missing or changed fields. This is when your inbox fills up.
January – February
Submission to the national competent authority
Financial entities file with their NCA. For the 2026 cycle this was 31 March 2026 in most member states; third-country branches of credit institutions had until 30 June 2026.
End of Q1
NCA consolidation and ESA quality control
NCAs pass registers to the ESAs by 30 April. The ESAs run additional quality checks through April; errors are sent back and entities are expected to correct and resubmit before the end of the month.
April
Corrections round
This is the second time you may be contacted — and the deadline is measured in days, not weeks.
April
Criticality assessment and CTPP designation
The ESAs use the aggregated register data to assess which ICT providers should be designated critical.
The cadence is annual but the scope of each round is not fixed. The AFM states plainly that the register is requested annually so the ESAs can determine which ICT service providers should be supervised as critical. But national authorities can and do calibrate. The Belgian FSMA, for example, ran a limited 2026 exercise in which only a subset of companies had to submit data, and participants could either confirm that the situation was unchanged since 2025 or submit an update (FSMA). The volume of requests you get can therefore differ year to year and country to country, even between customers of identical size.
Assume the request arrives late. As of 16 March 2026, with the deadline two weeks away, the CSSF reported that only 40% of required entities had submitted. Your customers are not, as a rule, running this process with a comfortable buffer. The supplier who can answer in an hour rather than a fortnight is doing something quietly valuable for the relationship.
Put the reference date and the end-of-Q1 deadline in your own calendar rather than waiting to be asked. A supplier who emails its EU financial customers in early January with an up-to-date, dated data sheet — before they chase — converts an annoying obligation into one of the cheapest trust signals available. Very few others in their supplier list will have done it.
The 15 templates, and which ones are about you
Here is the full structure defined by CIR 2024/2956. The right-hand column is the one to read: it marks where your data actually lands.
Code
Template
Is it about you?
B_01.01
Entity maintaining the register
No
B_01.02
Entities within the scope of consolidation
No
B_01.03
List of branches
No
B_02.01
Contractual arrangements — general information
Partly (contract-level)
B_02.02
Contractual arrangements — specific information
Yes — heavily
B_02.03
Intra-group contractual arrangements
No
B_03.01
Entities signing the contractual arrangement
No
B_03.02
ICT third-party service providers signing the contractual arrangement
Yes
B_03.03
Financial entities providing ICT services
No
B_04.01
Entities making use of the ICT services
No
B_05.01
ICT third-party service providers
Yes — this is your entity record
B_05.02
ICT service supply chains
Yes — your subcontractors
B_06.01
Functions identification
No (your customer's business functions)
B_07.01
Assessments of ICT services supporting critical or important functions
Yes — but they answer, about you
B_99.01
Definitions
No
Four templates carry the bulk of what a supplier is asked for: B_05.01 (who you are), B_02.02 (what the contract says and where the service and data live), B_05.02 (who sits behind you), and B_07.01 (how replaceable you are — filled in by your customer, but shaped almost entirely by what you tell them).
Field by field: exactly what your customer needs from you
This is the reference section. Field codes and names are as set out in Annex I to CIR 2024/2956.
B_05.01 — Your entity record
Field
Name
What you need to have ready
B_05.01.0010
Identification code of ICT third-party service provider
Your active 20-character LEI, or EUID. Not your VAT number or company registration number, unless you genuinely have neither.
B_05.01.0020
Type of code to identify the ICT third-party service provider
Which identifier the code above is. Tell your customer explicitly; don't make them guess.
B_05.01.0030
Additional identification code
A second identifier where one exists.
B_05.01.0040
Type of additional identification code
As above.
B_05.01.0050
Legal name
The exact registered legal name of the contracting entity, including the legal form suffix. Not your brand.
B_05.01.0060
Name in Latin alphabet
A transliteration where your registered name is not in Latin script.
B_05.01.0070
Type of person
Legal person, or natural person conducting a business activity.
B_05.01.0080
Country of headquarters
ISO 3166-1 alpha-2 code for the head office of the contracting entity.
B_05.01.0090
Currency of the amount reported in 0100
Your customer's figure, in their currency.
B_05.01.0100
Total annual expense or estimated cost
Their spend with you. You don't supply this — but be ready for them to reconcile it against your invoicing.
B_05.01.0110
Identification code of ultimate parent undertaking
The field suppliers most often cannot answer on the day. The identifier of the entity at the top of your ownership chain — your group holding company, or your majority owner's top entity.
B_05.01.0120
Type of code for the ultimate parent
As above.
Two of these deserve a flag.
Legal name and contracting entity (0050). If you sell through a local subsidiary — "Acme Software B.V." contracts with the Dutch bank, while "Acme Software Inc." is the brand everyone says out loud — the register needs the entity that is actually party to the contract. Vendors that operate a group structure routinely send the parent's identifier and the subsidiary's name, which is a guaranteed mismatch.
Ultimate parent (0110). This is a genuine ownership question, not a branding one, and the answer can change without your sales team noticing — a funding round, a holdco reorganisation, an acquisition. If your ultimate parent changed since the last filing and you didn't tell your customers, their register is now wrong and yours is the name attached to the error.
B_02.02 — Contract specifics
Field
Name
Why it comes back to you
B_02.02.0010
Contractual arrangement reference number
Their key. Quote it back in every reply so answers don't get attached to the wrong contract.
B_02.02.0020
LEI of the financial entity using the service
Theirs.
B_02.02.0030 / 0040
Identification code and code type of the ICT provider
Should match your own contract record. Frequently doesn't.
B_02.02.0080
End date
As above, including how auto-renewal is treated.
B_02.02.0090
Reason for termination or ending
Only where applicable.
B_02.02.0100
Notice period for the financial entity
Straight out of your contract. Have the clause reference to hand.
B_02.02.0110
Notice period for the ICT third-party service provider
Your notice period — asked separately, because the two are often not symmetric.
B_02.02.0120
Country of the governing law
ISO code. From the contract, not from where you happen to be based.
B_02.02.0130
Country of provision of the ICT services
Where the service is actually delivered from, including any delivery, support or operations centre outside the EU.
B_02.02.0140
Storage of data
Whether data is stored under the arrangement at all.
B_02.02.0150
Location of the data at rest (storage)
Actual storage region(s). "The cloud" is not an answer.
B_02.02.0160
Location of management of the data (processing)
Where processing happens — often a different answer to storage, and the difference is exactly what the field exists to capture.
B_02.02.0170
Sensitiveness of the data stored
Their classification of the data you hold.
B_02.02.0180
Level of reliance on the ICT service supporting the critical or important function
Their assessment.
Fields 0130, 0150 and 0160 are where suppliers most often give an answer that is technically true and operationally incomplete. A common pattern: storage sits in one EU region, but 24/7 support is staffed from a third country and support engineers can reach production data. If the register says the service is provided from the EU, and an audit later surfaces that access path, the correction lands on your customer's filing — and on your relationship. Answer for where the work is actually done, not only where the servers are.
B_05.02 — The supply chain
Field
Name
B_05.02.0010
Contractual arrangement reference number
B_05.02.0020
Type of ICT services
B_05.02.0030 / 0040
Identification code and type of the ICT third-party service provider
B_05.02.0050
Rank
B_05.02.0060 / 0070
Identification code and type of the recipient of the sub-contracted ICT services
See the section on subcontractors for what rank means and why it is the field most likely to generate a second round of questions.
B_07.01 — The assessment your customer writes about you
You do not fill this in. But every field in it is answered using information you provided, so it is worth knowing what conclusions your inputs feed.
Field
Name
B_07.01.0010
Contractual arrangement reference number
B_07.01.0020 / 0030
Identification code and type of the ICT third-party service provider
B_07.01.0040
Type of ICT services
B_07.01.0050
Substitutability of the ICT third-party service provider
B_07.01.0060
Reason where the provider is considered not substitutable or difficult to substitute
B_07.01.0070
Date of the last audit on the ICT third-party service provider
B_07.01.0080
Existence of an exit plan
B_07.01.0090
Possibility of reintegration of the contracted ICT service
B_07.01.0100
Impact of discontinuing the ICT services
B_07.01.0110
Are there alternative ICT third-party service providers identified?
B_07.01.0120
Identification of alternative ICT third-party providers
Field 0070 is worth noting specifically: date of the last audit. If your customer has audit or inspection rights in the contract and has never exercised them, this field is one of the quiet nudges that eventually produces an audit request. Knowing the field exists tells you why the request can arrive seemingly out of nowhere in year three of a calm relationship.
The Annex III service taxonomy: all 19 ICT service types
Every ICT service in the register is classified with one identifier from this closed list, set out in Annex III to CIR 2024/2956. Only the identifier — S01 to S19 — is reported.
ICT development (business analysis, software design, development and testing)
S03
ICT help desk and first-level support
S04
ICT security management services (security protection, detection, response and recovery; security incident handling and forensics)
S05
Provision of data (subscription to data provider services)
S06
Data analysis
S07
ICT facilities and hosting services, excluding cloud (infrastructure, facilities, hosting, utilities such as energy and heat management, telecom access, physical security; and payment-processing activities and operating payment infrastructures)
S08
Computation — digital processing capabilities, excluding cloud services
S09
Non-cloud data storage
S10
Telecom carrier
S11
Network infrastructure
S12
Hardware and physical devices provided as a service (workstations, phones, servers, storage devices)
ICT operation management (infrastructure configuration, maintenance, installation, capacity management, business continuity; includes managed service providers)
S15
ICT consulting (intellectual and technical expertise)
S16
ICT risk management (verification of compliance with Article 6(10) of Regulation (EU) 2022/2554)
Decide your own codes once, and write them down. Most suppliers are not a clean single code. A SaaS platform that includes a managed onboarding service and a 24/7 support desk plausibly touches S19, S14 and S03. A data vendor with an analytics layer touches S05 and S06. There is no single correct mapping handed down for every product, and different customers will classify the same service differently — but if you hold a documented default position with a one-line rationale per code, you answer consistently across every customer. Inconsistency across customers is precisely what aggregation and cross-referencing surface.
Note also the two traps in the list. S07 quietly contains payment processing and payment infrastructure alongside hosting — payment firms reading the taxonomy for the first time often look for a payments code, don't find one, and pick something else. And the cloud / non-cloud split is enforced throughout: S08 and S09 explicitly exclude cloud, because cloud computation and storage belong under S17–S19.
LEI and EUID: the most common reason a register fails
Article 3 of CIR 2024/2956 requires financial entities to identify ICT third-party service providers using a valid and active Legal Entity Identifier (LEI), or the European Unique Identifier (EUID) referred to in Article 16 of Directive (EU) 2017/1132, where available.
Four things follow.
1. "Valid and active" is a machine check, not an opinion. The LEI is a 20-character code under ISO 17442, issued by GLEIF-accredited issuers (Local Operating Units). It must be renewed annually to remain in active status, and it is verified against the global database. Plenty of suppliers obtained an LEI once for an unrelated reason years ago, let it lapse, and now supply a code that fails validation every January without anyone internally knowing why the customer keeps writing back.
2. EUID is not "EU Digital Identity". The European Unique Identifier is the company identifier from the interconnected EU business registers system under the Company Law Directive. It is an alternative to an LEI for entities registered in the EU — not a digital wallet, and not a substitute for having your entity data straight.
3. If you have neither, say so clearly and give something real. The AFM's guidance to financial entities is direct: where a provider has no LEI or EUID, report another available identification number — and do not use dummy codes or leave the field blank. That instruction exists because suppliers were returning blanks. A clearly labelled national registration number is a far better answer than silence, and far better than an invented placeholder that will be cross-referenced and flagged.
4. There is a strong practical case for getting an LEI even though nothing obliges you to. The legal obligation to report the identifier sits with your customer, not with you. But you bear the cost of not having one: repeated back-and-forth every cycle, a customer's register that fails validation partly because of you, and an identifier gap that surfaces in exactly the risk conversations where you would rather look organised. An LEI is issued by any GLEIF-accredited issuer for an annual fee that varies by issuer, and is typically obtained in days rather than weeks. If you sell to EU financial entities and you don't have one, this is among the cheapest items on your entire third-party-risk list.
Set a calendar reminder for your LEI renewal that is owned by a named person, not by a shared inbox. LEI lapse is silent from your side and loud from your customer's. If your entity structure means you also quote a parent's identifier (field B_05.01.0110), check that one too — you are quoting an identifier you do not control.
Your subcontractors: the ranked ICT service chain
Template B_05.02 is where the register stops being an address book and starts being a dependency map.
The concept is rank: the position a provider occupies in the chain of sub-outsourcing for a given ICT service. You, contracting directly with the financial entity, are rank 1. A provider you subcontract to for that service is rank 2. A provider they subcontract to is rank 3. Each link is recorded with the identification code of the provider and the identification code of the recipient of the sub-contracted service — so the chain is reconstructable, not just listed.
What this means in practice for a supplier:
Your subprocessor list is probably not in the right shape. A privacy-driven subprocessor list is typically a flat set of names and purposes, sufficient for GDPR Article 28 transparency. The register wants a directed chain with identifiers, per service, tied to a specific contractual arrangement. The same underlying facts, a different structure.
Your subcontractors need identifiers too. Where the service supports a critical or important function, the chain is expected to carry valid identification for the providers in it. That can mean asking your own cloud provider, your data centre or your BPO partner for their LEI. Do it once, store it, reuse it.
Depth is bounded by relevance, not by curiosity. The register focuses on the chain supporting the ICT service being reported — particularly where it supports a critical or important function — rather than a complete inventory of every vendor in your business. But expect the question to go at least one level past your direct suppliers.
Changes are the trigger. Adding a subcontractor mid-year is the classic silent register-breaker. Most well-drafted financial-services contracts already require you to notify material subcontracting changes; the register is what makes the absence of that notification visible.
Why accuracy matters more than it looks: CTPP designation
Here is the part most suppliers do not know, and it reframes the whole exercise.
The registers are not filed and forgotten. They are the input data for deciding which ICT providers come under direct EU supervision.
The ESAs describe a three-step process: collect data from financial entities' registers of information, run a criticality assessment in cooperation with the competent authorities, then formally notify the providers concerned and give them a right to respond. On 18 November 2025 the ESAs published the first list of designated critical ICT third-party service providers (CTPPs) — 19 providers, according to the list published alongside that announcement — spanning cloud and data-centre operators, IT services firms, and financial data and software providers (EBA).
For a designated CTPP, the ESAs act as direct overseers, assessing whether the provider has appropriate risk-management and governance frameworks for the services it delivers to EU financial entities. That is a genuine regulatory relationship, not a label.
Two honest implications:
If you are nowhere near that scale, this is not your future. Designation follows from systemic concentration across the EU financial sector. Most suppliers will never approach the threshold, and you should be sceptical of anyone selling you preparation for a designation you will not receive.
But the data you supply is aggregated and cross-referenced across all your customers. That is why consistency matters beyond any one filing. If ten financial entities describe the same service from you using three different service-type codes, two spellings of your legal name and two different identifiers, the aggregate picture of your footprint is wrong — and correcting it later is a conversation you will have on someone else's timetable rather than your own.
The four questions where your answer is a judgement call
Most of the register is fact retrieval. Four questions are not, and these are the ones worth agreeing an internal position on before you are asked under time pressure.
1. "Which service type code applies?" Covered above. Pick your defaults, document one line of reasoning each, reuse them.
2. "Where is the service provided from?" The honest answer includes follow-the-sun support, offshore engineering, and any third-country entity in your own group that touches delivery. Decide what your standard disclosure is, get it agreed by whoever owns the customer relationship and whoever actually knows the architecture, and make sure the two answers are the same one.
3. "Are you substitutable?" Your customer fills in B_07.01.0050, not you — but they fill it in based on what you have told them about data portability, export formats, transition assistance and contractual exit support. There is a real commercial tension here and it is better acknowledged than pretended away: "difficult to substitute" is a phrase that sounds like lock-in to a risk committee. Suppliers who can point to concrete, documented exit mechanics — a data export in a documented format, a defined transition-assistance period, written exit cooperation — generally come out of this question better than those who leave the assessor to infer.
4. "Is there an exit plan?" (B_07.01.0080.) Your customer owns their exit plan. But a customer writing "no" against a service supporting a critical or important function has a supervisory problem, and their first call to fix it will be to you, asking for the cooperation clauses and technical detail that make a plan writable. Being ready for that call is straightforwardly good account management.
The supplier RoI data pack: a reusable template
Build this once. Date it. Re-issue it every January. This is the artefact that turns the annual scramble into a short email.
Section 1 — Entity identification(one block per contracting entity you sell through)
Exact registered legal name, including legal form
LEI (20 characters) — and its next renewal date
EUID, if you have one
Any additional identifier, clearly labelled (national registration number, VAT)
Type of person: legal person
Country of headquarters, ISO 3166-1 alpha-2
Ultimate parent undertaking: legal name and identification code
Date this block was last verified, and by whom
Section 2 — Service classification
Your default Annex III service type code(s), S01–S19, per product or module
One line of rationale per code
A note on how you handle bundles (which code leads, and why)
Section 3 — Provision and data locations
Country or countries the service is provided from, including support and operations
Location of data at rest, by region
Location of data processing, by region — stated separately from storage
Any third-country access path to production data, and the control around it
Whether data is stored under the arrangement at all
Section 4 — Contract facts(per customer, not generic)
Contractual arrangement reference, as your customer numbers it
Start date and end date, and renewal mechanics
Notice period — the customer's
Notice period — yours
Governing law, by country
Section 5 — Supply chain
Subcontractors relevant to the service, with legal name and identifier
Rank, or position of each in the chain for that service
Which subcontractor supports which service type
Locations for each
Section 6 — Exit and substitutability support
Data export formats and documented export mechanism
Transition-assistance terms and duration
Contractual exit-cooperation clauses, with clause references
Documented alternatives or interoperability, where they exist
Section 7 — Change log
What changed since the last cycle, with dates
Who was notified, and when
Section 7 is the one people skip and the one that pays. It is what lets a customer confirm "situation unchanged" in a limited-scope year — the exact option the FSMA offered in 2026 — without reopening every field. It also protects you: a dated record that you notified a subcontractor change in June is the difference between a data-quality issue and a contractual notification failure.
Nine mistakes that send the request back to you
Sending the brand name instead of the contracting entity's registered legal name. Guaranteed mismatch.
Quoting a lapsed LEI. Silent on your side, disruptive on theirs.
Answering "EU" for data location. Not a value the format can take. Give regions or countries.
Conflating storage and processing. Two separate fields — 0150 and 0160 — precisely because they are often two separate answers.
Omitting third-country support access. It surfaces later, in a worse setting.
Giving different service-type codes to different customers for the same product. Cross-referencing finds it.
Sending your GDPR subprocessor list as the supply-chain answer. Right facts, wrong structure, no identifiers, no rank.
Not tracking the ultimate parent after a funding round or reorganisation. Your customers' registers go stale and nobody tells you.
Treating each customer's request as a fresh project. Ten customers, ten spreadsheets, ten chances to answer inconsistently. One dated source, ten consistent extracts.
Keeping it current between cycles
The register has a fixed annual reference date, but the facts behind it change continuously. Three events should trigger an update of your pack and a proactive note to affected customers, not a wait until next January:
Corporate change. New ultimate parent, a merger, a new contracting entity, a change of registered name.
Delivery change. A new hosting region, a new support location, a change in where processing happens, a new access path.
Supply-chain change. A new subcontractor, a removed one, or one that changes its own footprint in a way that affects your chain.
Most financial-services contracts already carry notification obligations for at least the second and third of these — a standard flow-down described in our guide to DORA for ICT vendors and in the wider EBA third-party risk framework. The register simply makes non-notification visible on a supervisory timetable.
A workable rhythm for a mid-sized supplier:
Cadence
Action
On change
Update the pack; notify affected customers under the contractual clause; log it in Section 7
Quarterly
Verify LEI status and renewal date; confirm the subcontractor list is unchanged
Each December
Refresh the whole pack against the 31 December reference date
Each January
Send the dated pack proactively to every EU financial customer, before the request arrives
Each April
Keep a named person available for the corrections round
Where a system of record helps
None of the above is conceptually hard. It is hard because the facts live in different places and different heads: legal has the contract dates and notice periods, finance knows the group structure, engineering knows where processing actually happens, and the account manager is the one holding the deadline.
That is the same problem that makes security questionnaires slow, and it has the same shape of solution: one approved, dated, sourced set of facts about your company that different requests draw from, rather than a new reconstruction each time. When a register request arrives, the question should be "which of our approved facts does this field map to?" rather than "who knows where our data is processed?"
MatchAudit is built around that idea for suppliers selling into regulated industries: your customers, the requests they send, your approved answers, the documents behind them, and the commitments you made — kept in one place, with the source visible next to every answer and a person approving before anything is sent. The register of information is a good test case for it, because it recurs on a fixed timetable, is asked by every EU financial customer at once, and rewards consistency more than eloquence.
Nothing here is a claim that a tool makes you compliant. The filing obligation is your customer's, the accuracy of your own facts is yours, and no software changes either. What can change is how long it takes you to answer, and whether the ten answers you give ten customers say the same thing.
Do suppliers have to file a DORA register of information?
No. The obligation under Article 28(3) of DORA applies to financial entities, not to their suppliers. What suppliers have to do in practice is provide accurate data so their financial-entity customers can file — and because the filing is annual and machine-validated, that request recurs every year from every EU financial customer you have.
What is the deadline for the DORA register of information?
Financial entities file with their national competent authority around the end of Q1, against a reference date of 31 December the previous year. For the 2026 cycle, the reference date was 31 December 2025 and the submission deadline was 31 March 2026, with third-country branches of credit institutions having until 30 June 2026. NCAs pass registers to the ESAs by 30 April, with a correction window during April. Supplier data requests therefore typically arrive in January and February, and a second round of corrections can arrive in April.
Does my company need an LEI to sell to EU financial institutions?
Nothing legally obliges a supplier to obtain an LEI — the reporting obligation sits with the financial entity. But CIR 2024/2956 requires them to identify you with a valid and active LEI or EUID where available, and an LEI is validated automatically against the global database. In practice, suppliers without one generate repeated follow-up requests and can contribute to a customer's register failing validation. An LEI is obtained from any GLEIF-accredited issuer for an annual fee that varies by issuer, and must be renewed each year to stay active.
What is the difference between an LEI and an EUID?
An LEI is a 20-character global identifier under ISO 17442, issued by GLEIF-accredited issuers and renewed annually. An EUID — European Unique Identifier — is the company identifier from the interconnected EU business registers, referred to in Article 16 of Directive (EU) 2017/1132. CIR 2024/2956 permits either. EUID is not the EU Digital Identity Wallet, which is an unrelated scheme.
Which register of information templates contain supplier data?
Of the 15 templates in CIR 2024/2956, four carry most of what suppliers are asked for: B_05.01 (the provider's own entity record — legal name, identifier, headquarters country, ultimate parent), B_02.02 (contract specifics including service type, notice periods, governing law, country of provision, and data storage and processing locations), B_05.02 (the ranked chain of subcontractors), and B_07.01 (the customer's assessment of substitutability, exit plan and audit date, which is written using supplier-provided information).
What are the S01 to S19 codes in the DORA register?
They are the closed taxonomy of ICT service types in Annex III to CIR 2024/2956, and only the identifier is reported. They run from S01 (ICT project management) through S17, S18 and S19 for cloud IaaS, PaaS and SaaS respectively, and include categories such as S04 ICT security management services, S07 facilities and hosting excluding cloud (which also covers payment processing and payment infrastructure), S14 ICT operation management, and S19 SaaS. Many suppliers legitimately map to more than one code, which is why documenting a consistent default position matters.
How do I report my subcontractors for a customer's register?
Template B_05.02 records the ICT service supply chain as a ranked structure, not a flat list: each entry ties a contractual arrangement and service type to a provider and to the recipient of the sub-contracted service, with a rank showing its position in the chain. A GDPR subprocessor list usually contains the right facts in the wrong shape — it lacks identifiers and ranking. Expect to need legal names and identification codes for subcontractors supporting the service, particularly where the service supports a critical or important function.
What happens if we give our customer the wrong information?
The immediate effect is that their submission fails one or more automated data quality checks and is returned for correction, typically during the ESAs' April quality-control window, with a short turnaround. The secondary effect is that the correction request comes back to you at the worst moment. The longer-term effect is inconsistency: because data is aggregated and cross-referenced across financial entities, conflicting descriptions of the same supplier are visible in a way that no single customer relationship would reveal.
Will we be designated a critical ICT third-party provider?
Almost certainly not, unless you operate at systemic scale across the EU financial sector. The ESAs run a criticality assessment using register data and published the first list of designated CTPPs on 18 November 2025. Designation brings direct oversight by the ESAs. Most suppliers are far below the threshold, and preparing for a designation you will not receive is not a sensible use of a small compliance budget — accurate, consistent annual data is.
Is the register of information the same as a security questionnaire?
No. A security questionnaire asks how you protect data and systems, is usually free-text, and is assessed by a human at one customer. The register of information asks a fixed set of structured facts about your legal identity, your contract, your locations and your supply chain, in a machine-validated format, on a fixed annual timetable, for a supervisory filing. The two draw on overlapping underlying facts, which is the argument for holding those facts once rather than per request.
Commission Implementing Regulation (EU) 2024/2956 — implementing technical standards on the standard templates for the register of information, including Annex I (completion instructions and templates) and Annex III (types of ICT services).
Deadlines and national arrangements differ between member states and change between cycles. Confirm the current dates with the customer making the request, or with the relevant national competent authority.
What DORA (EU Regulation 2022/2554) actually requires from ICT vendors selling to EU financial institutions — who is directly regulated, who is a 'critical' ICT third-party provider, and what typically flows down into contracts and due diligence.
