DORA for engineering teams: what the regulation actually asks of your systems

The Digital Operational Resilience Act is usually introduced to engineering teams as a compliance project owned by someone else. A policy is written, a questionnaire arrives, a few boxes are ticked. Then an audit asks for evidence — an incident timeline, a test report, a list of every external service the platform depends on — and the compliance project becomes an engineering project after all, under time pressure.

This guide reads DORA as what it is for the people who build and run systems: a set of requirements about how ICT services are inventoried, monitored, tested and sourced. If you understand it that way, most of it is cheaper to satisfy by design than by paperwork.

Who is in scope, and why that includes you

DORA applies to a wide range of financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more — and, indirectly, to the ICT third-party providers those entities rely on. Since the regulation applied in January 2025, the supervisory focus has shifted from “do you have a framework” to “show us it works”.

If you are an engineering team inside a financial entity, the obligations are yours to implement. If you build platforms, AI systems or hosting for financial clients, expect their contracts to pass DORA requirements through to you: audit rights, incident notification, exit support, sub-contractor transparency. Either way, the regulation has a concrete shape in your architecture.

The five pillars, translated

1. ICT risk management — the inventory and the controls

DORA requires an ICT risk-management framework: identify assets, dependencies and risks; protect and prevent; detect; respond and recover; learn. In engineering terms this is an accurate, maintained inventory of systems and data flows, controls that are actually implemented (access management, change management, backups, encryption), and monitoring that can detect anomalies.

The most common gap I find is not a missing control but a missing map. Teams cannot name every service that processes a given data set, or every external endpoint a workload calls. Infrastructure-as-code, service catalogues and dependency scanning turn this from a quarterly spreadsheet exercise into a generated artefact.

2. Incident management and reporting — the pipeline

Major ICT-related incidents must be classified and reported to the competent authority on a strict timeline: an initial notification within hours of classification, an intermediate report within days, and a final report within a month, following the regulatory technical standards. That timeline is only achievable if incident detection, classification and evidence collection are engineered, not improvised.

Concretely: alerting that reaches a human with context, an incident record that captures timestamps and impact automatically, logs that are immutable and retained, and a classification rule set that maps technical signals (affected clients, duration, data loss, geographic spread) to DORA’s materiality criteria.

3. Digital operational resilience testing — proving recovery

Entities must test their ICT systems regularly — vulnerability assessments, scenario tests, and, for significant entities, threat-led penetration testing every three years. For engineering this means: recovery is tested, not assumed. Restore from backup on a schedule. Fail over and measure the time. Run game days on realistic scenarios, including “the AI provider is down” and “the vector store was corrupted”.

The output of testing is evidence: what was tested, when, by whom, what broke, what was fixed. Treat test reports as versioned artefacts in the repository next to the code they cover.

4. ICT third-party risk — the dependency graph

This is where DORA bites hardest for modern architectures. Entities must maintain a register of information covering all contractual arrangements with ICT third-party providers, assess concentration risk, ensure contracts contain specific clauses (audit rights, service levels, termination, exit assistance), and maintain exit strategies for critical services.

For a team building AI systems, the third-party list is long and often invisible: the model API, the embedding service, the vector database, the GPU cloud, the observability SaaS, the CI runner. Each is an ICT dependency. Concentration risk is real when the model, the hosting and the identity provider all sit with one hyperscaler in one region.

5. Information sharing

Entities may share cyber threat intelligence with each other under DORA’s framework. For engineering, the relevant piece is simply that indicators of compromise, attack patterns and lessons learned should be captured in a form that can be shared — structured, anonymised, timely.

What this means for AI and platform systems

AI workloads are ICT services like any other under DORA, but they add specific concerns:

• Data integrity. A model answering from corrupted or manipulated source data produces confident wrong outputs at scale. Lineage, hashing and verification of the document corpus are resilience controls, not nice-to-haves.
• Model and provider dependence. Treat model providers as critical third parties: contract clauses, monitoring, exit strategy, and the ability to fall back to a self-hosted or alternative model.
• Observability of AI behaviour. Prompt and retrieval logs, evaluation metrics and drift monitoring are the incident-detection layer for AI systems. Without them you cannot classify an AI incident, let alone report it within the deadline.
• Change management. A prompt change, a model version bump or a re-indexing run is a production change. It needs the same review, testing and rollback path as a code deployment.

A pragmatic order of work

If you are starting from a policy document and a worried compliance officer, this sequence has worked well:

1. Generate the inventory from reality: infrastructure code, service catalogue, network egress logs. Compare with what compliance thinks exists. The delta is your first finding.
2. Build the third-party register from the inventory, with contracts attached. Classify criticality and concentration.
3. Make incident evidence automatic: immutable logs, incident records with timestamps, a classification rule set.
4. Schedule and run recovery tests. Keep the reports.
5. Write the exit strategy for the top three critical providers and test the cheapest step of each.
6. Only then, revise the policy so that it describes what you actually do.

Done this way, DORA compliance stops being a separate deliverable. It is the operational discipline you wanted anyway, with an audit trail.