One Contract, How Many Countries?

DORA Register of Information: lessons from the field, part 2

In the first article in this series, a compliance officer at a mid-sized investment firm was working out how to document Google’s supply chain three times over, once for each service her firm uses. She has since moved one field along in the same template, and this one looks a lot friendlier.

It is called “Country of provision of the ICT services”: one field, one ISO country code and no supply chain to reconstruct. I suspect it is the hardest question on the form.

Look at what she is actually being asked to name. An ordinary cloud platform, contracted through an Irish entity, running out of data centres in the Netherlands and Germany, backed up in another EU country, monitored around the clock by teams on three continents and accelerated by edge nodes in dozens of locations worldwide.

So in which country is that service provided?

There is no clean answer, because the question has never really been defined. On its own that would be harmless regulatory trivia. What makes it matter is a technical detail buried in the reporting data model, the same detail that produced the supply-chain problem in our first article. The country field is part of the identity of the record. An extra country is not extra colour on an existing row; it is an extra row. Answer too narrowly and the register quietly understates a firm’s geographic exposure. Answer too broadly and it swells into a page of near-identical rows that nobody, the supervisor included, can read for meaning.

The short answer: the reporting instructions require another row for every country reported, but they do not provide a stable threshold for deciding when a distributed ICT service is provided in a country. We propose one operational baseline, plus any country whose loss would impair the security or continuity of the service.

That is not the answer usually offered. The instinctive fix, and the one we reached for first ourselves, is to qualify the field with a word such as material. We think that fix is too cheap. An undefined adjective merely hands the interpretation problem to a different court. What the field needs is a test, and the templates already contain one. A country belongs in the register when its loss would be felt.

What the rules actually say

It helps to start with the plumbing, since that is where the problem sits.

Article 28(3) of DORA requires every financial entity to maintain a register of information covering its contractual arrangements with ICT third-party service providers. Implementing Regulation (EU) 2024/2956 turns that duty into fifteen linked templates.

Template B.02.02, “Contractual arrangements, specific information”, is the workhorse. It records a contract for each entity using it, function supported and type of ICT service. It carries the dates, notice periods, governing law and three geography fields: country of provision of the ICT services (0130), location of the data at rest (0150), and location where data is managed or processed (0160).

Here is the detail most policy discussions skip. In the EBA data model, those three geography fields are primary-key columns. They sit alongside the contract reference, the entity using the service, the provider, the function and the service type. The key defines a row. A service reported in two countries therefore needs two rows. Add several storage and processing countries and the number of valid combinations can climb quickly, each carrying an otherwise identical copy of the record.

The distinction between law and reporting instruction matters here. The ESA staff reporting FAQ says that provision across multiple countries should be reported with an additional row for each country. It gives the same row-per-value answer for multiple functions and service types. The FAQ also says plainly that it is practical, best-efforts assistance, not formal legal interpretation or an official ESA position. It nevertheless describes the technical treatment against which submissions are checked.

So the granularity is not in doubt. The trigger is. When does a country count?

A definition that raises more questions than it answers

The ITS instruction for field 0130 says to identify the country from which the ICT services are provided, using an ISO country code. The obvious follow-up arrived soon enough. Does that mean a registered office, an affiliate, a customer location or the place where the service actually runs?

The staff FAQ offers a gloss. The field refers to where the ICT service is processed by the provider and focuses on the operational aspect of provision. Registered offices do not count unless they are actively involved. Customer countries may count if they affect the service’s operational footprint, for example through localised processing.

That rules out one easy answer, the provider’s legal seat, and replaces it with a test that has no floor under it: actively involved in operational provision. Almost everything a modern service provider does is, in some attenuated sense, actively involved.

Take a concrete case, and not an exotic one. A financial entity engages a large consultancy as its ICT adviser. The contract is signed with the firm’s UK partnership. The consultants doing the work sit in the Netherlands. Behind them is a shared-services hub in Hungary handling internal tooling and reporting. Is that service provided in one country, two or three? A defensible argument can be built for each answer. None changes the firm’s operational-resilience picture in a way a supervisor would act on, yet each produces a structurally different register. The choice falls to whoever happens to be filling in the template.

Now scale that to the way software is delivered. A typical platform may use edge infrastructure in dozens of countries, run production workloads in one or more cloud regions, hold backups elsewhere and draw on support teams across several time zones. Read “actively involved in operational provision” literally and a modest European provider can appear to deliver from more countries than most banks have branches. Every modern cloud service starts to look the same. A register that records all of it faithfully records nothing anyone can use.

The geography fields compound because they share the key of the same table. Four provision countries, two storage countries and two processing countries can produce as many as sixteen country combinations for one contract, service and function, depending on how the applicable locations align. Multiply that by the entities using the contract and the functions it supports, both of which also sit in the key, and one cloud agreement becomes a page of permutations.

The regulator’s aim is legitimate. The instrument is not calibrated to it.

The aim is right; the instrument is not calibrated to it

It is worth being fair about why these fields exist, because the purpose is sound and we support it.

The register is not only an internal compliance artefact. Financial entities use it to monitor ICT third-party risk; competent authorities use it in supervision; and the ESAs use it when designating critical ICT third-party providers. Geography genuinely matters to that picture. Whether the Union’s financial infrastructure quietly depends on data processed in a single non-EU jurisdiction is exactly the sort of question DORA was written to answer. Third-country exposure, data-transfer risk and the reach of foreign legal process are real supervisory concerns.

The storage and processing fields serve that purpose reasonably well because they are tied to identifiable data. “Provision of a service” does not have a location in the same sense. Treating it as if it does produces data that is precise without necessarily being accurate.

The staff FAQ gives the game away. Asked what to do when a provider will not disclose which EU country stores the data, it says to choose the closest and most relevant country. That is an identifying field in a supervisory dataset, populated by a considered estimate. Aggregate thousands of registers assembled under that instruction and the concentration map is drawn partly from estimates, with different firms estimating differently.

That is the deeper cost of the missing definition, and the regulator eventually pays it. Granularity was chosen to make data comparable and aggregable. Undefined granularity does the opposite. One bank reports a cloud provider in a single country, its neighbour reports the same provider on similar terms in nine, and the gap between them is interpretive style rather than risk. Noise at row level does not average out at European level. It piles up.

What the dry run does, and does not, prove

The ESAs’ 2024 dry run put numbers on the broader data-quality problem before the regime went live. Of the 947 registers analysed, 6.5% passed every check. Missing mandatory information accounted for 86% of recorded failures, and 60% of the missing information sat in B.02.02.

That last figure needs handling honestly. The report identifies provider codes, function identifiers and service types as the information most often missing from B.02.02. It does not say the geography fields caused the failures. The dry run therefore does not prove our argument. It does show that the template carrying these fields was already the largest source of missing information before firms had to keep it current in steady state.

That maintenance burden matters. The register is a living record, and competent authorities collect it for annual transmission to the ESAs as well as requesting it when needed. Every row added for a marginal country must remain consistent with contract renewals, provider migrations and the register’s referential-integrity checks. Cloud regions move. Edge locations are commissioned and retired. A register wired to transient infrastructure is a register that always needs correcting, and correction effort is exactly the scarce resource DORA should be pointing at resilience work: testing, exit plans and incident response.

The tempting fix, and why it is not enough

Anyone who has worked with these templates lands on the same first instinct: qualify the field. Ask not for the countries of provision, but for the material countries of provision, and let judgement handle the rest. It is the fix we drafted first ourselves.

It fails, and it is worth being precise about why. Materiality works in financial reporting because it stands on decades of convention, quantitative anchors and an audit profession paid to police the boundary. Drop it into the register without that scaffolding and “material” is merely the current ambiguity in a better suit. Two hundred organisations reporting the same cloud provider would decide for themselves what material means. The supervisor would still receive two hundred private definitions, now with an official word attached.

An undefined adjective does not resolve an interpretation problem. It moves it.

The lesson is not that thresholds are wrong. It is that a threshold has to be a test rather than a word.

The templates already contain the test

What makes this fixable with one amendment rather than a redesign is that the ITS has already solved the same kind of problem one template over.

Template B.05.02 maps the ICT supply chain. The drafters understood that a literal supply chain is bottomless because every subcontractor has subcontractors. Recital 6, Article 3(2)(b) and the instructions for B.05.02 do not ask for every link. For services supporting critical or important functions, they focus on subcontractors that effectively underpin the service: those whose disruption would impair its security or continuity.

Look past the drafting and see what that clause is. It is a counterfactual you can put to an operations engineer and get a defensible, checkable answer: if this subcontractor stopped tomorrow, would our service degrade? Judgement remains, but it is anchored to an observable property of the service rather than the reporter’s temperament.

Geography needs the same anchor. A country belongs in the register when its unavailability would be felt in the service.

One refinement is needed before that becomes a workable rule. A resilient cloud service may be designed so that no single country’s loss impairs anything. Read literally, the impairment test would then return no country at all. That is absurd for a field intended to locate the service. The rule needs a floor as well as a filter.

A two-part rule for field 0130

Our proposal to the ESAs is concrete.

Report the ordinary operational place of delivery. Use the primary place from which the contracted service is delivered where one exists. For a managed service this may be the principal delivery centre. For infrastructure and platform services it will usually be the contracted production or deployment region used by the financial entity. Where a genuinely distributed service has no natural singular location, the instructions should specify an evidence hierarchy rather than force an invented answer.
Add every country whose unavailability would impair security or continuity. This is not a new concept. It is the B.05.02 test applied to place rather than party.

The examples will matter at least as much as the definition. Guidance should say what belongs under each limb and, just as importantly, what does not.

Ordinary place of delivery

The country from which staff perform the service as its ordinary delivery model, such as a managed service run from a service centre in India or a development team in Poland.
For infrastructure and platform services, the country of the contracted region in which the entity’s production workload runs.

Impairment-based additions

A designated failover region in another country that would take over production.
Localised processing without which the service cannot function, for example processing required by the financial entity in a specific jurisdiction.
A single-country operations or security hub whose outage would stop the service being delivered securely.

Do not report as service-provision countries

A registered office, holding company or contracting entity merely because it is a legal counterparty. It should count only if operations there actually deliver the service.
Transient or fungible infrastructure such as content-delivery edge nodes, DNS or traffic routing where the provider can shift location without notice or effect on the service.
Internal corporate functions, such as HR or group finance, that support the provider’s business rather than the customer’s service.
Data locations solely because they store or process data. Those locations already have their own fields. They should count under 0130 only when they also meet the service-provision test.

Finally, say what the field is for. One recital-level sentence explaining that the geography fields are intended to expose operational dependence on jurisdictions, not inventory a provider’s global footprint, would do more for data quality than another validation rule. People fill in a field better when they know what question it is answering.

None of this weakens supervision. The two-part rule does not hide meaningful processing or delivery dependencies. It makes them visible by clearing away the edge locations and corporate offices that would otherwise bury them. A threshold anchored to impairment is not a loophole. It is the difference between a register and a landfill.

A defensible practice while guidance catches up

Guidance moves slowly and registers are due now, so firms still need a workable position. Pending a formal answer, the safest approach is to document a methodology and apply it consistently. Distinguish the place of contractual signature, the operational delivery of the service, and the locations of data storage and processing. Identify the ordinary operational place of delivery where the evidence supports one. Add countries where a demonstrable operational dependency exists.

Where the facts support a second or third provision country, the templates and data model support the additional rows, and the staff FAQ expects them. The judgement remains the financial entity’s. What the entity should not have to do is guess at the meaning of an identifying field in a European supervisory dataset more than a year after the first submissions.

The machinery for a fix exists. Reporting instructions have been clarified before, closed lists have been adjusted where primary-key fields forced impossible answers, and formal questions can be handled through the Single Rulebook process. The precedent also exists one template over. What is missing is a decision that geography, like subcontracting, deserves an anchored test rather than an open question.

Until then, the honest answer to “in which country is your cloud provider’s service provided?” remains what it has been since January 2025: it depends who you ask, and the register will faithfully record whichever answer they give.

In the next instalment we will continue through the structural tensions in the Register of Information and the proposals that might reconcile regulatory intent with operational reality. A pattern is emerging across the first two articles. We will name it now so you can test it with us as the series develops:

Information that describes risk belongs on the row. It should not define the row.

Ariadnah Solutions B.V. builds reporting software for the DORA Register of Information. This article is part of the series “DORA Register of Information: lessons from the field”, examining the templates from the perspective of the entities that must file them and the authorities that must use them. Comments and challenges are welcome. We would rather be corrected than comfortable.

The DORA guide places the register in the wider operating model. Book a Discovery Call to discuss the contract, supplier and reporting relationships your organisation is still reconstructing by hand.

Primary sources

Regulation (EU) 2022/2554: Article 28(3), Register of Information requirements.
Implementing Regulation (EU) 2024/2956: templates B.02.02 and B.05.02, data format requirements and the subcontractor impairment test.
EBA Data Model for DORA RoI: primary and foreign keys for the reporting templates.
ESA staff reporting FAQ, 28 March 2025: practical reporting treatment for multiple countries and field 0130.
ESAs 2024 dry-run summary report: participation and data-quality results.
Joint ESAs Q&A 2025_7309: yearly transmission of the registers and availability on request.

This article presents the author’s analysis and a proposal for clearer reporting instructions. The two-part test described above is not current law or formal ESA guidance. Financial entities remain responsible for applying DORA, the implementing regulation and instructions from their competent authority.