Digital Operational Resilience Testing

Digital operational resilience testing, under DORA, is the structured checking of whether the ICT systems that support critical or important functions would keep working, or recover in an orderly way, when something goes wrong. A test is not a document review. It exercises a system, a process, or a team under conditions that resemble a real failure, then records what happened. The point is evidence. A board, a supervisor, and the firm itself should be able to see, from test results, where resilience is real and where it is only assumed. Testing that is proportionate to risk, complexity, and scale, and that covers systems supporting critical functions, is the core idea in this cluster.

The testing chapter of Regulation (EU) 2022/2554 sets out a programme rather than a single exercise. It includes basic checks such as vulnerability scanning and network security testing, alongside more demanding work such as scenario based testing and, for certain entities, threat led penetration testing, known as TLPT. What unites them is scope. Tests should reach the systems that matter for critical functions, including relevant third party services where a failure there would affect the function. A programme that tests only peripheral systems, or only the easiest parts of a central system, leaves the most consequential risk unexamined, however tidy the resulting report may look.

A testing programme that never finds anything deserves suspicion, not celebration. Real systems contain weaknesses, outdated components, unclear ownership, and recovery steps that have never been tried under pressure. If testing never surfaces any of these, the likely explanation is that the testing was too gentle, too narrow, or too detached from production. Consider a retail card payment service that passes every exercise in a quiet test environment, yet has never been tested with the transaction patterns, data volumes, and third party dependencies of a busy trading day. Its clean record says little about its next disruption. Honest findings are a sign that testing is working.

The recurring pitfall in this cluster is the laboratory test. Test data is simplified, interfaces to suppliers are stubbed out, staff know the exercise in advance and in detail, and no customer is waiting. A pass in those conditions proves that a system can work when nothing else is competing for its attention. Production is different. Queues build, a supplier responds slowly, a backup restores data that is older than expected, and two teams make conflicting decisions at the same time. Testing should therefore move, over time, toward realism: real data shapes, real dependencies, real handovers, and real time pressure, within safe boundaries that protect live customers and live data.

A programme needs a plan, a record, and a follow up loop. The plan states which systems and functions are tested, by what method, and why that method fits the risk. The record captures what was tested, what failed or behaved unexpectedly, and what was left untested, with reasons. The follow up loop turns findings into remediation, retesting, or an accepted and documented decision, owned by a named person. Without that loop, testing becomes theatre. Reports accumulate, the same weakness appears in successive exercises, and nobody can explain why it was still present when a real incident arrived. The guides in this cluster take each part of that loop in turn.

When reading a test result, ask which critical function it concerned, which systems were actually exercised, and how closely the conditions matched production. Ask what failed, what was not tested, and what changed afterwards. Ask who owns each open finding and when it will be retested. A result that answers those questions, including an uncomfortable answer, is useful. A result that reports only that a test took place, with no findings and no follow up, should prompt further questions rather than reassurance. That sceptical reading is the habit this cluster aims to build.

That habit also protects the firm from a quieter risk, which is mistaking activity for assurance. A calendar full of exercises, a shelf of reports, and a clean pass rate can coexist with a critical system that has never been tested under realistic conditions. Reading results sceptically, and following findings through to retesting, is what converts testing from a routine into a source of genuine confidence.