Compliance Audit
PUBLIC / REFERENCEEngine
DORA / RULE REFERENCE

DORA — ICT resilience

DORA (Regulation 2022/2554) applies to financial entities and their ICT third-party providers — which pulls SaaS vendors into scope through their customers’ registers of information. Its core demand is provable resilience: classified incident handling, continuity testing, and a ledger of what broke and when. If you sell into EU finance, your customers’ DORA register now includes you.

The rule

Financial entities and their ICT providers must demonstrate operational resilience: incident handling, continuity, and the records to prove both.

What it means for how you build

Resilience is an architecture: circuit-breakers on external dependencies, dead-letter queues on async flows, and a ledger of what broke and when.

Self-check

  • Do external dependencies fail closed — breakers, timeouts, dead-letters — or fail by hanging?
  • Is there an incident ledger with severity classification, not a postmortem wiki?
  • Can you evidence continuity testing — restores and failover — on a schedule?
  • Are your ICT dependencies registered — would you appear correctly in a customer’s register of information?

Common pitfalls

  • Resilience-by-uptime-number: "99.9%" is not evidence — incident records and tested recovery are.
  • Retry storms masquerading as resilience: retries without a breaker turn a partial outage into a full one.
  • Assuming DORA is the bank’s problem — ICT providers get pulled in via contracts and registers.

How the engine checks it

Redis-backed circuit breaker states, incident ledger, and dead-letter topics — resilience as records, not promises.

Last reviewed 2026-11-01.

Reading up on DORA — ICT resilience? The engine verifies this surface from the perimeter — live on sovereign EU/UK partitions.