DORA's register of information when the ICT provider is an AI model

The register in brief

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 28(3) requires financial entities to maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, distinguishing those that support critical or important functions. They report on new arrangements at least yearly, make the full register available to the competent authority on request, and inform it in a timely manner about planned arrangements for ICT services that support critical or important functions.

The format is fixed by Commission Implementing Regulation (EU) 2024/2956, published on 2 December 2024: fifteen templates, from B_01.01 for the entity maintaining the register to B_99.01 for definitions. It is not paperwork for its own sake. Competent authorities sent the first registers to the European Supervisory Authorities by 30 April 2025, and the ESAs drew on that data when they published their first list of 19 critical ICT third-party providers on 18 November 2025. What a bank writes about its AI providers feeds directly into how supervisors see concentration across the sector.

Your model provider is an ICT third-party service provider

I still meet banks across the EU that treat a model API as a developer tool bought on a card, outside the third-party risk process. Under DORA it is an ICT service, the company behind it is an ICT third-party service provider, and the arrangement belongs in B_02.01 and B_02.02 like a core banking contract. The ICT service taxonomy in Annex III of the implementing regulation has no AI category. Most teams classify a hosted model API as cloud SaaS (S19), and some as PaaS (S18) where they build on the provider's platform. Pick a rule, document it and apply it the same way across every AI arrangement.

Then decide the function. B_06.01 identifies the functions your ICT services support and whether they are critical or important. A drafting assistant for internal policy documents probably supports neither. A model that triages transactions for fraud review, or summarises credit files for underwriters, may well support a critical or important function, and that classification drives everything after it: the supply chain template, the assessment fields in B_07.01, the Article 29 assessment of concentration risk before you sign, and the additional contractual provisions in Article 30(3).

Location fields are where AI arrangements go wrong

Template B_02.02 holds the specific information for each arrangement, and five of its columns matter most for AI. B_02.02.0130 is the country from which the ICT services are provided. B_02.02.0140 asks whether the service involves storage of data, even temporarily. B_02.02.0150 is the country of the data at rest, and B_02.02.0160 the country where the data is managed, meaning processed. B_02.02.0170 records the sensitiveness of the data as low, medium or high. Country fields take ISO 3166-1 alpha-2 codes, and where there is more than one country you add a row for each.

For a model API those rows must describe the service under failure, not only the primary region. If a Frankfurt deployment fails over to Dublin and Paris, processing happens in DE, IE and FR, and the register should say so. Do not answer No to storage by reflex either. If the provider keeps inputs for abuse monitoring, data is stored, and the country of that store belongs in B_02.02.0150. Prompts that carry customer data are rarely anything but high sensitiveness.

• One B_02.02.0160 row per country of processing, including every failover region in the graph.
• Storage answered from the provider's retention terms for the endpoints you actually call.
• Contractual locations under Article 30(2)(b), which requires the regions or countries of service provision and data processing, including storage, plus advance notice of any change, matching the register rows.

Who signs the provider contract decides the rank

Template B_05.02 maps the ICT service supply chain. Providers that contract directly with the financial entity are rank 1, their subcontractors rank 2, and the rank rises with each tier. For services supporting critical or important functions you include the subcontractors that effectively underpin the service, meaning those whose disruption would impair its security or continuity.

With a gateway in the path, the contract structure decides the shape of the chain. On YTT Secunet, customers connect model providers with their own credentials under their own contracts, so each provider is a rank 1 provider with its own arrangement, and YTT Secunet is a separate rank 1 provider for the gateway service. Our subprocessors for hosting and operations sit at rank 2 under our arrangement. On Sovereign Dedicated the data plane runs in your VPC or data centre, so prompts are processed on infrastructure you operate rather than ours, though the licence and support arrangement still belongs in the register. A gateway that resells model access under its own contracts produces a different chain, with the model providers at rank 2 behind it. Ask every vendor which structure you are buying before you fill in the template.

Substitutability and the exit plan

B_07.01 asks, for each ICT service, whether the provider can be substituted, why not if it cannot, whether an exit plan exists and whether the service could be reintegrated in-house. Be candid about model APIs. Moving from one model to another changes outputs, so a provider is only easy to substitute if you have already tested an alternative against your evaluation set and recorded the results.

A credible exit plan names the in-jurisdiction alternative, the evaluation evidence and the switching procedure, and it has been exercised at least once. Reintegration is a real option for some workloads: an open-weight model on a runtime you operate can take over extraction and summarisation tasks if a provider relationship ends. Our next post covers how to build and test that fallback.

Reconcile the register with evidence

A register is a statement about where things run, and supervisors will test it against reality. Test it first. Every gateway response carries a signed receipt naming the resolved endpoint, the provider region and the facility. Map endpoints to provider codes and countries through your endpoint registry, aggregate a quarter of verified receipts, and compare the countries you observed with the countries you declared in B_02.02.0160. Any difference is either a register error or a routing error, and both need fixing before the annual submission.

• Run it before each annual submission and after any change to a failover graph.
• Keep the output with the submission: an empty result, backed by verified receipts, is the evidence you want on file.

import csv
import json
from collections import defaultdict

# endpoint id -> provider identification code and ISO 3166-1 alpha-2 country
registry = json.load(open("endpoint-registry.json"))
# output of: ytt-verify batch --bundle 2026q3.tar.gz --strict --json
receipts = json.load(open("2026q3-verified.json"))["receipts"]

observed = defaultdict(set)
for r in receipts:
    ep = registry[r["resolved_endpoint"]]
    observed[ep["provider_code"]].add(ep["country"])

declared = defaultdict(set)
with open("b_02_02.csv", newline="") as f:
    for row in csv.DictReader(f):
        declared[row["B_02.02.0030"]].add(row["B_02.02.0160"])

for provider, countries in sorted(observed.items()):
    missing = countries - declared[provider]
    if missing:
        print(f"{provider}: processing in {sorted(missing)} not declared in B_02.02.0160")