DORA Register of Information: The Supplier's Field-by-Field Guide

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.

Contents

• Why a filing you don't make keeps landing on your desk
• What the register actually is, in plain terms
• The annual cycle: dates you can plan around
• The 15 templates, and which ones are about you
• Field by field: exactly what your customer needs from you
• The Annex III service taxonomy: all 19 ICT service types
• LEI and EUID: the most common reason a register fails
• Your subcontractors: the ranked ICT service chain
• Why accuracy matters more than it looks: CTPP designation
• The four questions where your answer is a judgement call
• The supplier RoI data pack: a reusable template
• Nine mistakes that send the request back to you
• Keeping it current between cycles
• Where a system of record helps
• Related reading
• FAQ
• Official sources

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.

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:

1. 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.
2. 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.
3. 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.	Mid-year onward

Sources: CSSF, AFM.

Two practical notes.

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.

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	Must match B_05.01 exactly.
B_02.02.0050	Function identifier	Their business function. Their call.
B_02.02.0060	Type of ICT services	One Annex III code, S01–S19. See the full list below.
B_02.02.0070	Start date of the contractual arrangement	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.

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.

Code	Type of ICT service
S01	ICT project management (including Project Management Office services)
S02	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)
S13	Software licensing, excluding SaaS (on-premises software)
S14	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)
S17	Cloud services: IaaS
S18	Cloud services: PaaS
S19	Cloud services: SaaS

Source: Annex III, CIR 2024/2956.

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.

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

Nine mistakes that send the request back to you

1. Sending the brand name instead of the contracting entity's registered legal name. Guaranteed mismatch.
2. Quoting a lapsed LEI. Silent on your side, disruptive on theirs.
3. Answering "EU" for data location. Not a value the format can take. Give regions or countries.
4. Conflating storage and processing. Two separate fields — 0150 and 0160 — precisely because they are often two separate answers.
5. Omitting third-country support access. It surfaces later, in a worse setting.
6. Giving different service-type codes to different customers for the same product. Cross-referencing finds it.
7. Sending your GDPR subprocessor list as the supply-chain answer. Right facts, wrong structure, no identifiers, no rank.
8. Not tracking the ultimate parent after a funding round or reorganisation. Your customers' registers go stale and nobody tells you.
9. 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.

Related reading

• DORA for ICT Vendors: What Financial Institutions Need From Their Technology Providers — the broader contract and due-diligence effects of DORA on suppliers.
• EBA 2026 Third-Party Risk Guidelines — the parallel framework covering non-ICT services.
• Bank Vendor Onboarding and Third-Party Risk Approval — what happens before the contract is signed.
• Third-Party Risk Management From the Vendor Side — the full assessment lifecycle from where you sit.
• Vendor Due Diligence Checklist — the evidence to have ready before any of this starts.
• Security Questionnaires: A Complete Guide for SaaS Vendors and Suppliers — the request that usually arrives first.

FAQ

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.

Official sources

• Regulation (EU) 2022/2554 (DORA) — Article 28(3) establishes the register of information.
• 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).
• ESAs dry run summary: reporting of registers of information — data-quality findings from the 2024 exercise.
• ESAs designate critical ICT third-party providers (18 November 2025)
• AFM — Information register — reference date, deadlines, and guidance on missing provider identifiers.
• CSSF — DORA register of information collection — 2026 deadlines and the April correction window.
• FSMA — limited update in 2026 — an example of a reduced-scope national cycle.

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.