DORA’s ICT risk requirements read, to a software architect, like a checklist of good distributed-systems design. The controls that make an entity resilient under Articles 9–12 are largely architecture choices made years earlier. Get the architecture right and compliance becomes evidence collection; get it wrong and no amount of policy will save you in an incident.

Patterns that lower ICT risk

  • Redundancy & no single point of failure. Multi-AZ, replicas and failover so one component’s death is not the service’s death. Maps to protection and recovery (Art. 9, 11–12).
  • Isolation & bulkheads. Contain failures so a problem in a non-critical area cannot cascade into a critical function. Directly supports limiting the impact of incidents.
  • Graceful degradation & circuit breakers. Shed load and degrade non-essential features rather than collapse — the difference between a minor and a major incident under the DORA classification criteria.
  • Immutable, tested backups. Versioned, restore-tested backups (ideally immutable against ransomware) underpin Article 12 recovery. A backup you have never restored is not a backup.
  • Least privilege & segmentation. Tight access control and network segmentation reduce both the likelihood and blast radius of compromise (Art. 9).
  • Observability as a first-class concern. Structured logging, metrics and tracing make detection (Art. 10) and post-incident analysis possible — you cannot respond to what you cannot see.

Design for the incident you will have

Assume failure. The architectures that survive supervisory scrutiny are the ones that were designed to degrade predictably and recover automatically — and that can prove it through testing. This is exactly what DORA’s resilience testing programme (Art. 24–25) probes, and what threat-led penetration testing stresses for designated entities.

Tip. Map each architecture decision to the DORA article it serves, and keep that mapping. It turns “we built it well” into “here is the evidence” — which is what auditors and supervisors actually want.

Architecture and the ISO 27001 bridge

Many of these patterns are already required by ISO 27001 Annex A technological controls (backup, logging, monitoring, secure development). If you run an ISMS, you can reuse that evidence for DORA — see our ISO 27001 to DORA mapping guide, and the DORA × ISO 27001 Lead Implementer certification.

Go deeper

The ICT Risk Management Professional certification connects these architecture choices to the DORA risk framework, controls and continuity expectations. Browse the full DORA certification catalogue.