DORA - the Digital Operational Resilience Act - is an EU regulation that makes operational resilience a binding requirement for financial entities and, critically, extends supervisory reach to the ICT providers that serve them. Because it is a regulation rather than a directive, it applies directly across member states without national transposition.
Who is in scope
- Banks, payment and electronic money institutions
- Investment firms, trading venues and central counterparties
- Insurance and reinsurance undertakings and intermediaries
- Asset managers, crypto-asset service providers and crowdfunding platforms
- Credit rating agencies and data reporting providers
- ICT third-party service providers serving those entities - including cloud, software and data providers, with the most systemically important designated as critical and supervised directly
That last category is what makes DORA unusual: a technology vendor with no financial licence can still find itself inside a financial regulatory perimeter.
The five pillars
1. ICT risk management
A documented framework covering identification, protection, detection, response and recovery - with the management body accountable and required to maintain sufficient knowledge.
2. ICT incident management and reporting
Classify incidents by defined criteria and report major ones to the competent authority on a staged timeline: an initial notification, an intermediate report as understanding develops, and a final report with root cause and remediation.
3. Digital operational resilience testing
A regular testing programme - vulnerability assessments, scenario-based testing, penetration testing - and, for significant entities, threat-led penetration testing (TLPT) modelled on real adversary behaviour.
4. ICT third-party risk management
Maintain a register of information covering all contractual arrangements for ICT services, apply specific contractual requirements, assess concentration risk, and plan credible exit strategies for critical providers.
5. Information sharing
Voluntary exchange of cyber threat intelligence between financial entities within trusted communities.
Build your DORA evidence base once
GRC Copilot assesses you against DORA, maintains your ICT third-party register alongside your vendor risk programme, and reuses evidence from your existing frameworks.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
The register of information
This is where many programmes stall. Supervisors expect a complete, structured inventory of every ICT contractual arrangement - not a spreadsheet of major vendors. Expect to record the provider and its identifiers, the service and the function it supports, whether that function is critical or important, the contract details, data locations and processing countries, subcontractors in the chain, and the substitutability and exit plan for each critical arrangement.
Most organisations discover their vendor inventory is far less complete than they believed, particularly for shadow IT and for subcontractors behind their direct suppliers.
How to approach it
- Confirm scope - including whether you are captured as an ICT provider to financial entities.
- Build the register of information first; it is the longest lead-time item.
- Classify functions as critical or important - this drives obligations across every pillar.
- Align incident classification to DORA criteria and rehearse the reporting timeline.
- Plan the testing programme, and determine whether TLPT applies to you.
- Review contracts against DORA's required clauses and renegotiate where needed.
- Document exit strategies for critical providers - regulators ask how you would actually leave.
DORA overlaps heavily with ISO 27001, ISO 22301 and existing outsourcing rules. The genuinely new work is usually the register of information, the exit strategies and the testing regime.
Frequently asked questions
Does DORA replace existing outsourcing guidance?
It consolidates and raises the bar for ICT risk and third-party arrangements, superseding parts of earlier sectoral guidance. Confirm the interaction with your regulator's current expectations.
We are a SaaS vendor, not a bank. Does DORA affect us?
Very likely, indirectly. Financial customers must include DORA clauses in contracts, register your service, assess concentration risk and hold an exit plan - so expect contractual and due diligence demands even if you are never designated critical.
What is threat-led penetration testing?
Advanced testing that simulates realistic adversary tactics against live production systems, following a prescribed methodology. It applies to entities identified as significant, not to everyone in scope.
How does DORA relate to NIS2?
DORA is sector-specific for finance and, as the more specialised regime, generally takes precedence for entities it covers. NIS2 applies more broadly across other sectors.
Key takeaways
- DORA applies directly across the EU and reaches ICT providers, not just financial firms.
- Five pillars: ICT risk, incident reporting, resilience testing, third-party risk, information sharing.
- The register of information is the biggest practical workload - start it early.
- Exit strategies for critical providers are explicitly expected.