The era of abstract discussions around operational resilience is over. With the Digital Operational Resilience Act (DORA), the European Union has transformed resilience from a conceptual best practice into a binding regulatory requirement. This law doesn’t just ask organisations to be secure—it mandates demonstrable evidence that IT systems can withstand, respond to, and recover from disruption.
For IT, security, and risk teams, DORA represents both a challenge and an opportunity: the challenge of meeting stringent regulatory expectations, and the opportunity to design systems and processes that are genuinely resilient.
What Is DORA?
The Digital Operational Resilience Act (EU Regulation 2022/2554) establishes a harmonised framework for ICT risk management across the EU financial sector. Its goal is simple in theory but ambitious in practice: ensure that financial entities remain operational even during severe ICT disruptions, including cyberattacks, system failures, and third-party service outages.
Unlike directives, which require national implementation, DORA is directly applicable in EU member states. This strengthens both consistency and enforcement. For IT teams, that means resilience is non-negotiable and continuously auditable.
Who Does DORA Apply To?
DORA applies far beyond traditional banks, affecting a wide range of financial and digital service providers.
In-Scope Financial Entities
- Banks and credit institutions
- Investment firms
- Insurance and reinsurance companies
- Payment service providers
- Electronic money institutions
- Crypto-asset service providers
- Trading venues and clearing houses
Critical ICT Third Parties
For the first time, cloud providers, MSPs, SaaS vendors, and other technology providers fall under regulatory oversight. This transforms third-party risk from a contractual concern to a regulatory obligation, making vendor resilience a shared responsibility.
In practical terms, if a major cloud provider suffers an outage, your organisation is still accountable under DORA.
Why DORA Matters to IT Teams
DORA fundamentally links technology operations to business resilience. Key implications include:
- System outages are compliance events, not just operational headaches.
- Architecture decisions carry regulatory consequences.
- Informal or undocumented controls are unacceptable.
- Resilience must be demonstrable and auditable at all times.
In short, IT teams can no longer rely on “we think it’s resilient” assumptions. Every system, process, and dependency must be known, tested, and documented.
The Five Pillars of DORA: A Practical IT Perspective
1. ICT Risk Management
Organisations must establish a formal ICT risk management framework that covers:
- Asset inventory and classification
- Threat and vulnerability management
- Secure system development and change control
- Backup, redundancy, and recovery capabilities
Real-world perspective: In my experience, many organisations underestimate the difficulty of maintaining an accurate asset inventory. Shadow IT, legacy platforms, and undocumented integrations are common weak points that DORA exposes immediately.
2. ICT-Related Incident Management and Reporting
DORA mandates standardised incident classification, strict reporting timelines, and clear escalation procedures.
IT reality check: detecting an incident is no longer enough. Regulators expect:
- Root cause analysis
- Impact assessment across systems, customers, and market operations
- Documented, timely response actions
This places strong emphasis on SIEM, SOAR platforms, and cross-team coordination across IT, security, legal, and compliance functions.
3. Digital Operational Resilience Testing
Regular, risk-based testing is mandatory:
- Vulnerability assessments
- Penetration testing
- Scenario-based resilience tests
- Threat-led penetration testing (TLPT) for larger entities
Key insight: Testing is no longer about finding vulnerabilities. It’s about validating survivability under stress. Can your systems fail safely? Can you recover within acceptable timeframes? Can staff continue operations during sustained disruption?
4. ICT Third-Party Risk Management
DORA significantly strengthens vendor oversight. Organisations must:
- Maintain a register of all ICT third-party dependencies
- Assess systemic risk and concentration
- Include resilience clauses in contracts
- Monitor ongoing vendor performance
Real-world experience: Cloud outages, SaaS failures, or MSP compromises are no longer external problems—they are regulatory liabilities. IT, procurement, and legal teams must collaborate to ensure:
- Exit strategies exist
- Data portability is tested
- Failover and redundancy plans are validated
5. Information Sharing
DORA encourages voluntary cyber threat intelligence sharing among financial entities.
For IT and security teams, this means:
- Participating in trusted threat intelligence networks
- Consuming actionable threat feeds
- Aligning detections with real-world adversary tactics
In practice, integrating intelligence-sharing into operational workflows significantly improves detection and response times.
DORA vs Traditional Security Frameworks
| Framework | Focus | Key Difference |
|---|---|---|
| ISO 27001 | Information security management | Process-oriented |
| NIST CSF | Cybersecurity risk | Security-centric |
| DORA | Operational resilience | Ensures continuity and recovery under ICT failure |
Insight: DORA cares less about perfect security and more about graceful failure, rapid recovery, and demonstrable resilience.
Common Gaps IT Teams Discover Under DORA
- Incomplete system inventories
- Overreliance on a single cloud region or provider
- Poorly documented recovery procedures
- Untested backup restoration processes
- Vendor contracts lacking resilience clauses
- Manual processes hidden inside “automated” workflows
From my experience, organisations that treat DORA as a checkbox exercise often struggle during audits. True resilience requires end-to-end visibility and tested recovery capabilities.
Preparing IT Teams for DORA Compliance
1. Map Critical Services to Technology
Identify which systems underpin which business services—and assess what happens if they fail.
2. Stress-Test Assumptions
Ask tough questions:
- What if this system is unavailable for 24 hours?
- What if a key SaaS provider goes offline?
- What if privileged access is compromised?
3. Operationalise Incident Response
Ensure playbooks are:
- Tested regularly
- Role-specific
- Practised under realistic conditions
4. Treat Resilience as Architecture
Design systems for:
- Redundancy
- Isolation
- Recovery—not just prevention
Final Thoughts: DORA Is a Cultural Shift, Not a Paper Exercise
DORA fundamentally changes how regulators view technology. IT failure is business failure, and resilience is non-negotiable.
For IT professionals, this presents both a challenge and an opportunity. Organisations that embrace DORA early will build systems that are:
- Robust
- Adaptable
- Compliant
- Truly resilient
Those that ignore it risk discovering, under regulatory scrutiny, that resilience cannot be retrofitted.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.