The DORA register for AI services and subcontractors

Procurement and legal should identify the financial institution using the service, the entity signing for it, and the vendor’s contracting legal entity. Obtain the agreement, order forms, service schedules and any documents showing that another entity signs on the user’s behalf. Record separate legal entities separately. A branch needs the applicable branch record linked to its head office; a product brand does not supply a legal-person identity. (Implementing Regulation 2024/2956, Art. 5(1), Annex I, B_01.01–B_01.03, B_03.01–B_04.01.)

The institution’s ICT team should then reconcile the contract with the deployed service. Establish which entity supplies inference, where the application runs, and who provides operational or security support. Ask the vendor which entity contracts with each provider. A list of approved subprocessors can inform this exercise, but the register needs the ICT services and contractual relationships relevant to this arrangement. (Implementing Regulation 2024/2956, Art. 1, Annex I, B_05.01–B_05.02.)

The direct SaaS provider has rank 1. A model provider contracted by that vendor has rank 2. A host contracted by the model provider has rank 3. If the SaaS vendor contracts separately with the model provider and host, both can occupy rank 2. The support provider’s rank follows its own contractual position. Record the immediate recipient of each subcontracted service and retain separate rows where one provider serves several recipients. No universal two-tier limit ends the enquiry. (Implementing Regulation 2024/2956, Art. 2, Annex I, B_05.02.0030–B_05.02.0070.)

Distinguish the institution’s group from the vendor’s group. If an institution-group ICT company contracts with the external vendor, the register must connect the relevant intra-group and external arrangements through B_02.03. At least the first provider outside that group enters the supply-chain record even where the service supports no critical or important function. The same exception does not arise merely because an external SaaS vendor uses its own operating affiliate. That affiliate’s inclusion and rank follow its evidenced service role and the applicable subcontractor test. (Implementing Regulation 2024/2956, Art. 5(1)(f), Annex I, B_02.03 and B_05.02 instructions.)

For an external vendor’s downstream contracts, retain the references as supporting evidence. Do not create a separate B_02.01 contract reference for each agreement between that vendor and its subcontractors. The instructions make a specific exception for ICT intra-group providers’ contracts. (Implementing Regulation 2024/2956, Annex I, B_02.01 instructions.)

Legal should also identify the supplier’s establishment, relevant delivery jurisdictions and governing law. Keep the provider’s headquarters country separate from service, processing and storage locations. For services supporting critical or important functions, assess the relevant insolvency and data-recovery constraints, third-country enforcement and obstacles to supervision. A completed country field does not establish that the arrangement can lawfully operate there. The countries and applicable restrictions must be resolved before the institution approves the proposed arrangement. (DORA, Arts. 28(4), 29(2), 30(2)(b); Delegated Regulation 2025/532, Arts. 1, 3.)

The institution’s function owner should identify the business activity supported by the AI service and document the consequences of disruption or defective performance. A function is critical or important where those consequences meet DORA’s material-impairment test. That test addresses financial performance, service soundness or continuity, and continuing compliance with authorisation conditions or financial-services law. The assessment belongs to the institution and must precede contracting. (DORA, Arts. 3(22), 28(4)(a).)

Create a function identifier for each combination of the using entity’s LEI, licensed activity and function name. The same internal function used for two licensed activities can therefore require two identifiers. Use the prescribed support-function treatment where the function is not linked to a licensed or registered activity. Preserve the assessment date and supporting rationale. (Implementing Regulation 2024/2956, Annex I, B_06.01 instructions, as corrected.)

Next, assess each downstream provider against the register’s inclusion test. For a service supporting a critical or important function, include subcontractors whose disruption would impair the security or continuity of that service. Model inference or hosting may meet that test. A support provider with privileged access or essential recovery responsibilities may also qualify. A provider supplying unrelated administrative support does not enter merely because the vendor purchases something from it. Document the evidence and the reason for each decision, including at deeper ranks. (Implementing Regulation 2024/2956, Art. 3(2)(b), recital 6, Annex I, B_05.02 instructions.)

Keep the wider subcontracting assessment alongside that register decision. Before contracting, the institution must be satisfied that its direct provider can identify all subcontractors supplying ICT services supporting critical or important functions, or material parts, and provide the necessary assessment information. The narrower register test does not eliminate that duty. If the vendor cannot identify a material model or hosting dependency, the institution cannot simply classify it outside the register to avoid the gap. (Delegated Regulation 2025/532, Art. 3(1)(b), (g)–(j).)

A designated critical ICT provider and a critical or important function are separate classifications. The implications of designation are explained in DORA accountability across firms, providers and supervisors. Apply the function test to the institution’s use even where the vendor has no such designation. (DORA, Arts. 3(22)–(23), 31.)

Use Implementing Regulation 2024/2956 with its September 2025 corrigendum. The correction changes identifier instructions and several field codes. In B_06.01, criticality is .0050, reasons are .0060 and the assessment date is .0070. A build copied from the original uncorrected annex can put the right information in the wrong field. Check the applicable DORA reporting module, validation rules and competent authority’s collection instructions before producing the submission. (OJ L 2025/90725, pp. 1–2; ESAs register FAQ, questions 46–47.)

The register owner should populate the records in this sequence:

1. Identify the maintaining entity, consolidation perimeter and relevant branches in B_01.01–B_01.03. A group register must preserve the information needed at each applicable level. Use the sectoral consolidation rules and include the relevant financial entities and ICT intra-group providers. (Implementing Regulation 2024/2956, Art. 6.)
2. Enter the direct contractual arrangements in B_02.01. Distinguish standalone, overarching and subsequent arrangements. Link an order to its overarching arrangement where required, and allocate annual expenses without duplication. (Annex I, B_02.01 instructions.)
3. Identify the receiving-side signatories in B_03.01, provider signatories in B_03.02, applicable intra-group providers in B_03.03, and actual service users in B_04.01. These roles may belong to different entities. (Annex I, respective template instructions.)
4. Create provider records in B_05.01 for direct suppliers, included subcontractors and their ultimate parents. Match the legal name and identifier to the actual entity. Record ownership separately: an ultimate parent does not acquire a supply-chain rank solely through ownership. (Annex I, B_05.01–B_05.02 instructions.)
5. Connect each contract, using entity, provider, function and ICT-service type in B_02.02, at the required granularity. Populate B_05.02 with the qualifying supply chain. Complete B_06.01 for the supported functions and B_07.01 for the applicable critical-function service assessments. Document the institution’s meanings for specified classifications in B_99.01. (Annex I, respective template instructions.)

Maintain four consistent keys throughout: contract reference, entity or provider identifier, function identifier and ICT-service type. Within one B_05.02 chain, every provider carries the same direct-contract reference and the same service type. If the contracted service is cloud SaaS, the relevant Annex III code is S19. Its downstream host does not switch that chain to S17 merely because the host supplies infrastructure. A separately contracted direct infrastructure service has its own mapping. (Implementing Regulation 2024/2956, recital 8, Annex I, B_05.02 instructions, Annex III.)

Submission conventions need their own checks. The printed ITS tells the preparer to leave the rank-1 recipient field blank. EBA Q&A 2024_7284 instead instructs reporting the direct provider’s own identifier in B_05.02.0060 because the data model treats it as a key. Apply that reporting convention without treating it as an actual subcontracting relationship. For downstream rows, keep the recipient’s identifier type consistent with its provider record. (EBA Q&A 2024_7284, final answer; Implementing Regulation 2024/2956, Annex I, B_05.02.0070.)

Contract dates should come from the applicable agreement and amendments. B_02.02 records entry into force and the end or renewal date, replacing the end date with a different actual termination date where applicable. Use 9999-12-31 for an indefinite arrangement where instructed. Apply each location field’s conditions and repeat rows for multiple valid country values. Do not put a list of countries into a field requiring one value. Contractual location disclosures remain required under Article 30(2)(b), even where a particular reporting field is conditional. (Implementing Regulation 2024/2956, Art. 4(2), Annex I, B_02.02.0070–B_02.02.0170; DORA, Art. 30(2)(b).)

For B_07.01, obtain the institution’s assessment of substitutability, exit arrangements and discontinuation effects. The last-audit date concerns an audit of the specific service by the institution, a pooled audit team or its appointed auditor. Receiving a certification or the provider’s internal audit report is not that audit. Where none has occurred, the field expressly requires 9999-12-31. Preserve the evidence behind both the value and the assessment. (Implementing Regulation 2024/2956, Annex I, B_07.01.0050–B_07.01.0120.)

The institution should send the vendor one coordinated request tied to the contracted service. Ask for:

• The contracting provider’s legal name, valid identifier, identifier type, headquarters country and ultimate-parent details, with registry evidence.
• The model, cloud and support entities serving this arrangement, their contractual recipients, and relevant providers further down each chain.
• Service descriptions and architecture showing which dependencies affect security, inference availability, continuity and recovery.
• Contract extracts confirming service scope, subcontracting permissions, dates, termination notices and applicable governing law.
• Delivery, processing and storage countries, including relevant support locations, backed by the service configuration and contractual schedules.
• The evidence needed for risk assessment, audit access, continuity, substitution and change notification, with a named supplier contact responsible for updates.

Those requests implement the institution’s recordkeeping and diligence duties. The vendor’s obligation to supply particular documents should be secured in the contract; the request does not itself create a direct contractual right against every remote provider. Obtain appropriate upstream commitments where the required information or access depends on them. (DORA, Arts. 28(3)–(5), 30; Delegated Regulation 2025/532, Arts. 3–4.)

The statutory identifier rule requires valid, active LEIs or EUIDs for legal-person providers; the template instructions require LEIs for non-EU legal persons. Use both identifiers where available and applicable. The alternatives for individuals acting in a business capacity do not establish a general corporate-registration-number substitute for companies. Never insert a guessed identifier, a parent’s LEI in place of its subsidiary’s, or a trading name as the legal identity. (Implementing Regulation 2024/2956, Art. 3(5)–(6), Annex I, B_05.01.0010–B_05.01.0040, as corrected.)

Technical reporting instructions address incomplete data separately. The ESAs’ FAQ permits an available alternative identifier for a third-country provider whose LEI is missing, with a data-quality issue recorded. EBA Q&A 2024_7285 permits certain missing non-key values and prescribes “Not Applicable” for an unavailable primary-key value, subject to specific instructions. Use the relevant convention only where it applies, preserve consistent joins, and continue obtaining the required evidence. A file accepted through that mechanism has not thereby satisfied the statutory identifier rule. (ESAs register FAQ, questions 26, 39–40; EBA Q&A 2024_7285.)

Give each gap an owner, evidence request and consequence. An incomplete reporting field and an inability to assess a critical dependency require different responses. If missing information prevents satisfaction of the subcontracting conditions, resolve the information or change the proposed service before entering the arrangement. For existing arrangements, assess the risk, document remediation and apply the required contractual changes promptly. Any termination decision must follow the applicable rights and continuity arrangements. (DORA, Arts. 28(4), (7)–(8); Delegated Regulation 2025/532, Arts. 3(1), 4(2), 6.)

Where the gap concerns upstream disclosure or access rights, the DORA contract review for non-EU ICT suppliers addresses the agreement, subcontractor schedule and evidence requests that need negotiation.

Assign a register owner within the institution. Procurement should report contract changes; the ICT team should report architecture and supplier changes; function owners should reassess criticality; compliance should manage the applicable supervisory notifications. The vendor should supply agreed change information through its designated contact. The institution retains responsibility for accuracy, regular review and prompt correction, including consistency between entity and consolidated records. (DORA, Art. 28(1), (3); Implementing Regulation 2024/2956, Art. 3(3)–(4).)

Review the affected records when the model provider, host, operating affiliate, support arrangement, service location or supported function changes. A model-version update within the same provider and contract may leave the register’s entity and contract keys unchanged. It still needs assessment if it changes dependencies, service scope or risk. A new model provider can require revised provider records, ranks, locations and service assessments. Where a function becomes critical or important, update its classification and inform the competent authority in a timely manner. (DORA, Art. 28(3); Delegated Regulation 2025/532, Art. 3(2).)

For material changes to relevant subcontracting arrangements, the contract must provide advance information and a reasonable approval or objection period. The provider may implement the change after approval or after that period expires without objection. If the institution concludes that the changes exceed its risk tolerance, it must inform the provider, object and request modifications before the notice period ends and before implementation. An ordinary model update does not automatically trigger this rule; assess whether it changes the relevant subcontracting arrangement materially. DORA does not supply one universal number of notice days. (Delegated Regulation 2025/532, Art. 5.)

Before each submission, reconcile the contract references, identifiers and code types across all affected tables. Check function-to-user links, valid service codes, recipient links and ranks, parent records, dates and conditional fields. Compare the result with the contract inventory and architecture, then run the applicable technical validations. Preserve the submission, feedback and remediation record. These controls put the ITS accuracy and consistency duties into operation. (Implementing Regulation 2024/2956, Arts. 3–4.)

When a contract ends, record the actual termination date and reason. EIOPA’s final reporting answer retains a contract included in the register for 31 December X and terminated in X+1 in the report concerning X+1, then omits it from the report concerning X+2. Keep the underlying evidence separately under the institution’s applicable retention arrangements. The reporting treatment does not itself establish a universal retention period. (EIOPA Q&A DORA 253–3393; Implementing Regulation 2024/2956, Annex I, B_02.02.0080–B_02.02.0090.)

Finally, confirm the collection date, reference date, reporting level and channel with the institution’s competent authority. DORA requires maintenance, at-least-yearly information about new arrangements and production of the register on request. Those duties do not create one identical submission timetable for every institution. (DORA, Art. 28(3).)