DORA for AI systems: a build checklist for engineering and risk teams

How does DORA apply to an AI system, and what do you have to write down?

If you run — or supply ICT to — an EU financial entity, the Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA, applying from 17 January 2025) treats your AI system like any other critical piece of ICT. It has to be identified, risk-assessed, tested, contractually pinned down, and recorded in a register you can hand to a supervisor. An LLM inference endpoint is ICT; a vector database is ICT; and both are usually supplied by a third party. AI is not carved out.

DORA reaches a broad set of financial entities — banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, and more — and it reaches through them to their ICT third-party service providers. The most critical of those providers can be designated for direct EU oversight.

This is engineering and practitioner guidance on how teams prepare for and meet DORA, grounded in production delivery of retrieval and agent systems. It is not legal advice, and it is not a compliance guarantee. Accountability for the DORA framework, the testing programme, and the register stays with the financial entity — it does not transfer to your cloud provider or your model vendor. A vendor supplies facts; the entity carries the obligation. Confirm your own obligations and deadlines against the official text and your own counsel.

DORA is built on five pillars. Below is each one read as an engineering task — what to write down, and what evidence to produce — followed by the field-by-field Register of Information entry that pillar four demands.

Pillar 1 — ICT risk management: name the AI dependency

The first pillar is a documented, ICT risk-management framework owned by the management body (the board or equivalent). For an AI system the move is to stop treating "the model" as a black box and start treating it as a mapped dependency with a blast radius.

Write down:

• The function this AI supports and whether it underpins a critical or important function. A model that drafts internal summaries is not the same risk as one scoring credit or triaging fraud alerts.
• The full dependency chain — inference provider, hosting region, vector store, embedding model, orchestration layer — with the failure mode if each degrades or disappears.
• The single points of failure. A hard dependency on one US hyperscaler for inference is exactly the fragility DORA asks you to surface.

Evidence to produce: an architecture diagram with data-flow boundaries, a dependency inventory, and a documented risk assessment a non-author can follow. Keep it under version control beside the code so it stays current instead of rotting in a wiki.

Pillar 2 — Incident management: make AI failures classifiable

The second pillar is ICT-related incident management: detect, classify, and — above a threshold — report major incidents to your competent authority on a defined timeline. AI systems fail in ways generic monitoring misses, so instrument for them.

Write down an incident taxonomy for AI-specific failures: inference outage, latency breach, retrieval returning wrong or stale context, prompt-injection or data-exfiltration attempt, silent quality regression after a model or index update. For each, define what "major" means in your classification scheme so on-call isn't improvising mid-incident.

Evidence to produce:

• Structured logging of inputs, model and version, retrieval sources, key decisions, and outputs — with defensible retention. This is the record you reconstruct an incident from.
• Alerting thresholds tied to the taxonomy above, not just CPU and 500s.
• A reporting runbook mapping a classified incident to who notifies which authority, by when.

An incident you cannot reconstruct is one you cannot classify or report. The log is the evidence.

Pillar 3 — Resilience testing: test the model path, not just the app

The third pillar is a digital operational resilience testing programme — regular testing, and threat-led penetration testing (TLPT) for significant entities. Bring the AI path into scope explicitly.

Write down a test plan that exercises the AI failure modes, not only the happy path:

• Dependency failure drills — pull the primary inference endpoint and confirm the system degrades safely (fallback, queue, or honest error) rather than hanging or fabricating.
• Retrieval and grounding tests — does the system refuse or flag when context is missing, instead of answering confidently from nothing?
• Adversarial input testing — prompt injection, data-exfiltration attempts, and boundary cases against tenant separation.
• Failover and recovery — if you run a hybrid or self-hosted path, prove the switchover works under load, not just in a diagram.

Evidence to produce: test results with dates, remediation tickets, and a re-test cadence. For TLPT scope, the AI system's exposure and its data boundaries belong in the tester's brief.

Pillar 4 — Third-party risk: the Register of Information and concentration risk

This is the pillar where AI procurement decisions bite hardest, and where the register is mandatory. The Register of Information is an inventory of all ICT third-party arrangements — where regulators look first, and where an under-specified AI system shows its gaps. For each AI-related arrangement, capture at least:

Then confront concentration risk head-on. DORA treats over-reliance on one provider — or on a provider that is hard to substitute — as a resilience defect you must surface and manage. A single-vendor, single-region LLM dependency is the textbook case: closed frontier models are not drop-in interchangeable, so "we would switch providers" is only a real exit plan if you have tested the alternative and can cut over inside your recovery objectives. If you cannot fill the "actual processing region," "subcontractors," and "substitutability" rows for your AI provider, that is not a paperwork gap — it is the concentration risk itself, made visible.

Two structural mitigations, both of which you should document:

• Substitutability — abstract the inference boundary so you can re-point to an alternative model or provider without re-architecting.
• Jurisdiction and CLOUD Act exposure — an EU-sovereign or self-hosted deployment keeps the ICT supply chain in-jurisdiction and removes required US data transfer. Running inference on Mistral AI with Qdrant for vector search, under EU data residency and self-hostable to on-prem or air-gapped, is how we reduce that dependency in practice. US-hosted models stay valid for many workloads; the point is to choose deliberately and record the choice.

Pillar 5 — Information sharing

The lightest pillar operationally: DORA encourages financial entities to share cyber-threat intelligence within trusted communities. For an AI system the useful contribution is concrete — indicators from prompt-injection and exfiltration attempts, and patterns from model-supply-chain incidents. Write down whether you participate, and how sanitised indicators leave your environment without leaking customer data.

The evidence a financial entity can actually file

DORA runs on documentation. A sovereign or self-hosted deployment is only worth its resilience claim if it produces the artefacts your framework, register, and testing need:

1. Classify the function the AI supports and record the rationale.
2. Map the full dependency chain and mark every single point of failure.
3. Instrument AI-specific logging — inputs, model/version, retrieval sources, outputs — with defensible retention.
4. Define an AI incident taxonomy and wire alerting plus a reporting runbook to it.
5. Test the failure modes — dependency drills, grounding, adversarial input, failover — on a cadence, with dated evidence.
6. Complete the Register of Information entry for every AI provider and sub-processor.
7. Assess concentration risk and document your substitutability and exit position — with the results of a tested cutover, not a diagram.
8. Pin contractual terms — audit rights, sub-contracting, termination/exit assistance.
9. Reduce jurisdiction exposure where the data warrants it, via an EU-sovereign or self-hosted inference path.
10. Schedule a re-review cadence so the register and tests keep pace with model and index changes.

The rows you cannot complete are your DORA priorities. Note the division of labour DORA assumes: your firm owns the framework, the testing, and the register; the vendor supplies the facts — where it runs, its dependencies, the audit trail, and the substitutability story.

Where TechRevati fits

Most of this becomes lighter when the deployment is built for it from day one. Structured logging, pinned model provenance, an abstracted inference boundary, and an EU-resident path turn register entries and test evidence into properties of the system rather than a scramble before an audit. That is the posture EinCoreRAG is built around: Mistral plus Qdrant, EU-resident and self-hostable, so "where does our data go" has an auditable answer and the exit plan is a deployment you already run.

If you are mapping DORA against a live or planned AI system — alongside the GDPR and EU AI Act overlap — our compliance overview lays out how we approach it, mapping each obligation to evidence we deliver rather than a promise. And the Sovereign RAG Pilot is a scoped, single-tenant way to test an EU-resident, self-hostable retrieval stack against your own concentration-risk and residency requirements — with the audit trail as a by-product. Reach us at hello@techrevati.com.