There is a hard truth behind DORA’s testing pillar: a recovery plan you have never exercised is a hypothesis, not a control. Chaos engineering — deliberately injecting controlled failure to see how systems actually behave — is the engineering discipline that turns “we think it is resilient” into “we have proven it, here is the evidence”. That is exactly what DORA Articles 24–25 ask for.
What DORA actually requires
DORA expects a risk-based testing programme covering ICT systems that support critical or important functions, run at least annually, with findings tracked to remediation. The test types range from vulnerability scans to scenario-based and penetration testing — and, for designated entities, advanced threat-led penetration testing (TLPT). Chaos engineering complements all of these by testing the resilience dimension specifically: failover, degradation and recovery.
From chaos experiment to DORA evidence
- State a hypothesis. “If the primary database node fails, the service fails over within our RTO with no data loss.”
- Inject the failure — in a controlled way, with safeguards (kill-switch, blast-radius limits), ideally starting in non-production.
- Measure against the target (RTO/RPO, error rate, recovery time).
- Record the result as a dated test artefact, and track any finding to remediation and re-test — the part auditors check.
Safeguards matter (especially on production)
Testing live systems that support critical functions carries real risk — the same reason DORA wraps TLPT in a controlled white-team model. Agree blast-radius limits, monitoring and rollback before any production experiment. Resilience architecture makes this safer; see our guide to architecture choices that reduce ICT risk.
Go deeper
The Business Continuity, DRP & Test Exercises certification covers how to design and run scenario, tabletop and full recovery tests; the TLPT Tester Certification covers advanced threat-led testing for designated entities. Both are part of the verifiable DORA certification catalogue.
