Compliance decisions
DORA register: an AI supplier worked example
DORA’s register covers contractual arrangements for ICT services, distinguishing those supporting critical or important functions from other arrangements. An AI-tool inventory is a useful starting point, but the register needs linked entity, provider, contract, service and function information. Validate those relationships and identifiers before using the official reporting format.
For Financial-entity ICT risk, procurement and operational-resilience teams
A populated teaching example shows the relationships without pretending to be a regulator-ready filing.
All entities, contracts, references and dependency findings are synthetic. Internal EX identifiers are not legal identifiers; this is not an official filing or a completed DORA assessment.01
Start from the contractual arrangement
Article 28 of DORA requires covered financial entities to maintain and update a register of information for contractual arrangements on ICT services, with the required distinction for critical or important functions. Identify the actual arrangement and the entity that uses the service rather than adding only a product name to a tool list.
A reseller, group procurement company and underlying provider may occupy different positions. Record who signs, who supplies and who uses the service. An employee’s discovery event can help find an unrecorded tool, but it does not establish the legal contracting party or terms.
Source context: DORA: Regulation (EU) 2022/2554
02
Use the register’s linked structure
Commission Implementing Regulation 2024/2956 sets the templates and instructions. It distinguishes general and specific contract information, signing entities, service users, provider information, supply-chain relationships, functions and relevant service assessments. The shared identifiers are what connect those records.
The worked example uses stable internal teaching references for one fictional institution, supplier, contract, service and function. They are deliberately not valid LEIs or EUIDs. The official instructions require valid provider identifiers in the applicable circumstances; an internal inventory label is not a substitute.
Source context: Commission Implementing Regulation (EU) 2024/2956
03
Assess the supported function
Describe what the AI service supports and how interruption or failure affects that function. Distinguish a convenience tool for general drafting from a service embedded in a critical operation, but do not decide criticality solely from the supplier’s marketing category or the presence of a manual fallback.
The fictional case assumes general internal correspondence drafting with an alternative process. Its non-critical classification is an exercise assumption, not a determination for a real financial entity. The accountable function owner must substantiate the actual assessment and review changes to the use or dependency.
Source context: DORA: Regulation (EU) 2022/2554 · Commission Implementing Regulation (EU) 2024/2956
04
Populate the evidence before exporting
The download contains linked teaching CSVs for the entity, provider, arrangement and supported function. Each reference is populated consistently, so the reader can trace the supplier through the contract to the user and function. The mapping table identifies the relevant official template families.
Before a real submission, replace the teaching references with validated legal identifiers and the full required data elements, classifications and relationships. Apply the competent authority’s current submission instructions and validation rules. These simplified CSVs are an evidence-mapping exercise, not an ITS-complete filing or a validated reporting package.
Source context: Commission Implementing Regulation (EU) 2024/2956
05
Keep the record current as AI use changes
Assign owners for the contract, service inventory, provider information and function assessment. A new feature, group arrangement, material dependency or subprovider can require updates across several linked records. Avoid changing one supplier name while leaving disconnected contract and function references behind.
Reconcile discovery and procurement information with the accountable register process. Retain the evidence behind the entries and any unresolved data-quality issue. A catalogue of AI products, a security report or a vendor’s own DORA statement does not complete the financial entity’s register.
Source context: DORA: Regulation (EU) 2022/2554 · Commission Implementing Regulation (EU) 2024/2956
Put it into practice
Linked AI supplier register example
Trace a fictional provider through its contractual arrangement to the financial entity, service user and supported function. The pack includes populated linked CSVs.
All entities, contracts, references and dependency findings are synthetic. Internal EX identifiers are not legal identifiers; this is not an official filing or a completed DORA assessment.
ENTITY-EX-01
Uses the drafting service
CONTRACT-EX-01
Links the entity to PROVIDER-EX-01
SERVICE-EX-01
Supports FUNCTION-EX-01
FUNCTION-EX-01
Internal correspondence
All references and the classification are synthetic.
| Record relationship | Populated teaching entry | Official-structure handoff |
|---|---|---|
| Entity and user | ENTITY-EX-01: fictional Example EU Finance SA. | Link entity scope and users through B_01 and B_04.01 as applicable. |
| Direct provider | PROVIDER-EX-01: fictional Example Text Services Ltd. | Provider and signing-party information link to B_05.01 and B_03.02. |
| Contract | CONTRACT-EX-01: direct subscription for the fictional drafting service. | General/specific arrangement information belongs in the B_02 family. |
| Service | SERVICE-EX-01: employee correspondence drafting, no customer action automation in the example. | Map the actual ICT service and users to the contract. |
| Function | FUNCTION-EX-01: internal administrative correspondence. | Identify the supported function in B_06.01. |
| Criticality assumption | Non-critical only for the teaching scenario, with an alternative process. | Real function assessment needs evidence; B_07.01 concerns relevant critical/important-function service assessments. |
| Identifier validation | All EX references are internal teaching identifiers, not LEIs or EUIDs. | Obtain valid legal identifiers and complete the official data requirements before filing. |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
dora-ai-supplier-register-example.mdInspect
# Linked AI supplier register example
All entities, contracts, references and dependency findings are synthetic. Internal EX identifiers are not legal identifiers; this is not an official filing or a completed DORA assessment.
Trace a fictional provider through its contractual arrangement to the financial entity, service user and supported function. The pack includes populated linked CSVs.
| Record relationship | Populated teaching entry | Official-structure handoff |
| --- | --- | --- |
| Entity and user | ENTITY-EX-01: fictional Example EU Finance SA. | Link entity scope and users through B_01 and B_04.01 as applicable. |
| Direct provider | PROVIDER-EX-01: fictional Example Text Services Ltd. | Provider and signing-party information link to B_05.01 and B_03.02. |
| Contract | CONTRACT-EX-01: direct subscription for the fictional drafting service. | General/specific arrangement information belongs in the B_02 family. |
| Service | SERVICE-EX-01: employee correspondence drafting, no customer action automation in the example. | Map the actual ICT service and users to the contract. |
| Function | FUNCTION-EX-01: internal administrative correspondence. | Identify the supported function in B_06.01. |
| Criticality assumption | Non-critical only for the teaching scenario, with an alternative process. | Real function assessment needs evidence; B_07.01 concerns relevant critical/important-function service assessments. |
| Identifier validation | All EX references are internal teaching identifiers, not LEIs or EUIDs. | Obtain valid legal identifiers and complete the official data requirements before filing. |
## Review steps
- Validate the legal identities: Confirm the contracting, supplying and using entities and the applicable valid LEI/EUID requirements.
- Reconcile linked references: Check that contract, provider, user and function records refer to the same actual arrangement.
- Evidence the function assessment: Have the accountable owner assess criticality, dependency and change triggers before mapping the complete official templates.
## Populated linked records
ENTITY-EX-01 uses SERVICE-EX-01 from PROVIDER-EX-01 under CONTRACT-EX-01. The service supports FUNCTION-EX-01. All names and identifiers are fictional.
## Register mapping
Use the actual 2024/2956 template instructions for B_01 entity scope, B_02 arrangements, B_03 signing entities, B_04 users, B_05 providers/supply chain, B_06 functions and the relevant B_07 assessments. This exercise does not contain every required field or controlled vocabulary.
## Data-quality finding
The EX references are suitable only for tracing this example. They must not be submitted as LEIs/EUIDs. No regulatory validation or filing has been performed.
## Source and scope
Guide: https://aona.ai/resources/guides/dora-ai-vendor-register-example/
Source check: 21 September 2026. General information, not professional approval or a completed control test.
- DORA: Regulation (EU) 2022/2554: https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
- Commission Implementing Regulation (EU) 2024/2956: https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng
Download dora-ai-supplier-register-example.mddora-ai-supplier-register-example.csvInspect
Record relationship,Populated teaching entry,Official-structure handoff
Entity and user,ENTITY-EX-01: fictional Example EU Finance SA.,Link entity scope and users through B_01 and B_04.01 as applicable.
Direct provider,PROVIDER-EX-01: fictional Example Text Services Ltd.,Provider and signing-party information link to B_05.01 and B_03.02.
Contract,CONTRACT-EX-01: direct subscription for the fictional drafting service.,General/specific arrangement information belongs in the B_02 family.
Service,"SERVICE-EX-01: employee correspondence drafting, no customer action automation in the example.",Map the actual ICT service and users to the contract.
Function,FUNCTION-EX-01: internal administrative correspondence.,Identify the supported function in B_06.01.
Criticality assumption,"Non-critical only for the teaching scenario, with an alternative process.",Real function assessment needs evidence; B_07.01 concerns relevant critical/important-function service assessments.
Identifier validation,"All EX references are internal teaching identifiers, not LEIs or EUIDs.",Obtain valid legal identifiers and complete the official data requirements before filing.
Download dora-ai-supplier-register-example.csvdora-example-entities.csvInspect
entity_ref,entity_name,role,identifier_status
ENTITY-EX-01,Example EU Finance SA,fictional financial entity and service user,internal teaching reference; not an LEI
Download dora-example-entities.csvdora-example-providers.csvInspect
provider_ref,provider_name,role,identifier_status
PROVIDER-EX-01,Example Text Services Ltd,fictional direct ICT provider,internal teaching reference; not an LEI/EUID
Download dora-example-providers.csvdora-example-arrangements.csvInspect
contract_ref,signing_entity_ref,provider_ref,service_ref,service_description,status
CONTRACT-EX-01,ENTITY-EX-01,PROVIDER-EX-01,SERVICE-EX-01,Employee internal correspondence drafting,synthetic direct subscription
Download dora-example-arrangements.csvdora-example-functions.csvInspect
function_ref,using_entity_ref,service_ref,contract_ref,function_description,criticality,evidence_status
FUNCTION-EX-01,ENTITY-EX-01,SERVICE-EX-01,CONTRACT-EX-01,Internal administrative correspondence,non-critical teaching assumption,fictional alternative process; no real assessment
Download dora-example-functions.csvBefore you proceed
Keep these distinctions clear
- A tool list is not the register
- Legal entities, arrangements, users and functions need consistent linked information.
- A teaching identifier is not a valid LEI
- Validate the required legal identifiers and complete official fields before submission.
Apply it to employee AI use
Bring your actual data path.
Aona’s supported discovery and activity evidence can help identify employee AI services that need procurement or risk review.
Its AI catalogue is not the DORA register and does not establish legal identifiers, contract scope or critical-function classification.
Use discovery evidence as one input, then reconcile the named service with the institution’s contract and register owners.
Review your use caseFAQ
Questions for this decision
Does the register include only critical ICT services?
Can we submit these CSVs to a regulator?
Is an AI product name enough to identify the provider?
Does a manual fallback prove the function is non-critical?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- DORA: Regulation (EU) 2022/2554
Article 28 register-of-information obligations and distinction between ICT arrangements supporting critical or important functions and others.
law · checked 2026-09-21 - Commission Implementing Regulation (EU) 2024/2956
Register templates and instructions, linked contract/entity/provider/function data, valid provider identifiers and data-quality requirements.
law · checked 2026-09-21