DORA Register of Information — which fields Vannus can answer

Field identifiers and names are verbatim from Commission Implementing Regulation (EU) 2024/2956, Annex I, checked against its text on EUR-Lex on 9 October 2026; the explanations beside them are Vannus's. If you have seen RT.xx names, those are from the 2023–24 draft and were superseded.

B_05.01.0050 Per provider.

Legal name of the ICT third-party service provider

The record's fieldContracting entity — its name

The legal person the vendor's own documents name as the party the customer contracts with, with the source URL and the date the page was read. The export gives its leading legal name, with the record's full words beside it and a note to read them wherever they say more than the name. The register identifies the same provider by its LEI or EUID in B_03.02; the export carries neither (see below).

Thirty-one of the vendors on record contract through more than one entity, depending on where the customer is incorporated or located, where it is billed, or how it bought. For twenty-one of them the record quotes the words that say which fact decides: where the customer is located, billed or holds its account for nineteen, where it is incorporated for six, and an order form or the channel it bought through for five, with eight of them naming more than one of these; for the other ten, the record does not settle which. For every one of them the register needs YOUR entity, not a general one — which is what the paid report resolves, where the clause's words and your answers let it.

B_02.02.0120 Conditional — critical or important functions.

Country of the governing law of the contractual arrangement

The record's fieldGoverning law — its country, where there is one

The register wants the ISO 3166-1 alpha-2 code for the country the law belongs to. The export gives that code only where the record holds one law for every customer — US for “the laws of the State of California” — with the choice-of-law clause, as the record reads it in the vendor's own documents, beside it, so the code is checkable rather than asserted. Where the law depends on where the customer is based, or the record holds no single law, the code is left empty, with the clause beside it where the record publishes one.

Read from the vendor's own published documents; your signed contract can say otherwise. Mandatory only where the ICT service supports a critical or important function. Whether yours does is your determination, not ours.

B_05.01.0080 Always, per provider.

Country of the ICT third-party service provider’s headquarters

The record's fieldNot held — a sourced parent for 6

This field asks for the country of the provider's global operating headquarters, which the ITS notes is usually the country of tax residence. The record carries no sourced headquarters fact for any vendor. For 6 it carries a sourced parent, which the export gives with its source — ownership, not headquarters. Otherwise it leaves the field for you to establish rather than filling it from an unsourced catalog flag.

This is deliberately NOT the contracting entity's country. A vendor contracting through an Irish subsidiary of a US parent files the US here — which is exactly why a guess is worse than a blank.

What the record does not answer

Stated plainly, because a mapping that oversells is worse than no mapping when you are the one filing.

Field	What it asks	Why not us
`B_03.02.0020/0030`	Identification code of ICT third-party service provider; Type of code to identify the ICT third-party service provider	The register identifies the provider that signed each arrangement by code, not by name. The export carries no LEI or EUID for any provider; the name it holds goes in B_05.01.0050.
`B_05.01.0010/0020`	Identification code of ICT third-party service provider; Type of code to identify the ICT third-party service provider	Only LEI or EUID may be used for legal persons, and only LEI for legal persons established outside the Union. The export does not carry LEIs.
`B_05.01.0110/0120`	Identification code of the ICT third-party service provider’s ultimate parent undertaking; Type of code to identify the ICT third-party service provider’s ultimate parent undertaking	Mandatory where the provider is not itself the ultimate parent. For 6 vendors the export gives a sourced parent with its source; whether that parent is the ULTIMATE one, and its code, the record does not say.
`B_02.01`	Contractual arrangements – General information	Reference number, type, currency, annual expense. These are facts about YOUR contract and exist only in your own records.

None of this is advice. Whether an arrangement supports a critical or important function — and therefore whether B_02.02.0120 is mandatory for it — is your determination and not ours. Vannus is not your lawyer.

Getting the answers

The record is free to read: every determined vendor's page carries its contracting entity, governing law and control finding, each quoted and dated. Browse the record.

Where a vendor contracts through more than one entity — thirty-one of those on record do — the register needs the entity that signed your arrangement, identified in B_03.02 and named in B_05.01.0050, which depends on where your company is incorporated or located, where it is billed, or how it bought. The AI Subprocessor Jurisdiction Report resolves that per vendor for your own entity, with the clause attached so you can check the reading.

Two of DORA's fields are in a vendor's own terms. The third is not.

The three fields

Legal name of the ICT third-party service provider

Country of the governing law of the contractual arrangement

Country of the ICT third-party service provider’s headquarters

What the record does not answer

Getting the answers