DORA, digital resilience for financial firms
Meet the EU rules on ICT risk, incident reporting, testing and third-party providers.
Official sources
Use these official places to read the text and find the latest version.
Official website
The official text is free in the EU Official Journal. The European supervisory authorities publish technical standards.
Visit eur-lex.europa.eu (Regulation 2022/2554) ↗Get the document
Read the regulation free on EUR-Lex. The European supervisory authorities publish the technical standards.
Open the official page ↗What DORA is
The Digital Operational Resilience Act sets common rules for banks, insurers, investment firms, payment providers and other financial entities. It makes sure they can withstand and recover from ICT disruption.
It also reaches critical ICT third-party providers, such as cloud services.
How DORA got to where it is today
The milestones that changed what organisations have to do.
Proposed
Part of the EU digital finance package.
Adopted
Regulation published in December 2022.
Applies
Applies from 17 January 2025.
Dates are for orientation. The official website holds the authoritative record.
Do you need it?
If any of these sound familiar, probably yes.
You are a financial entity in the EU.
You provide ICT services to financial firms.
You rely on cloud providers for core services.
You must report ICT incidents.
What it asks of you
The requirements fall into six areas.
ICT risk management
Framework, policies and tools.
Incident reporting
Classify and report major incidents.
Resilience testing
Regular testing, advanced for some.
Third-party risk
Contracts and a register of providers.
Information sharing
Share threat information.
Governance
Management body responsible.
The 7 pillars, 13 article groups and 38 obligations
DORA gives EU financial entities one rulebook for digital resilience. It covers ICT risk management, incident reporting, resilience testing, control of ICT providers and information sharing.
13 article groups · 38 obligations
Scope and proportionality (Arts. 2-4)Who must comply and how far the rules scale with size.1 article group · 4 obligations
Scope and proportionalityDORA covers EU financial entities and applies in proportion to size and risk.4 obligations
- Art. 2
Confirm whether you are a financial entity covered by DORA, such as a bank, payment or e-money institution, investment firm, insurer, crypto-asset service provider or similar.
What you do
- Check your authorisation type against the scope list
- Record the outcome and review on change
- Art. 3
Know the key definitions, for example ICT risk, major incident and critical or important function.
What you do
- Adopt the definitions in your policies
- Train staff on them
- Art. 4
Apply the rules in proportion to your size, risk profile, nature, scale and complexity.
What you do
- Document how proportionality shapes each control
- Seek regulator confirmation if unclear
- Art. 16
Smaller or simpler entities may follow a simplified ICT risk management framework where eligible.
What you do
- Check eligibility conditions
- Record the decision
Evidence to keep
- Scope assessment listing entity type
- Proportionality justification
- Group and intra-group service map
p1Pillar 1: ICT risk managementA sound, documented framework owned by management.4 article groups · 11 obligations
Governance and framework (Arts. 5-6)The management body owns ICT risk.3 obligations
- Art. 5(2)
The management body defines, approves, oversees and is accountable for the ICT risk management framework.
What you do
- Table the framework for board approval
- Record oversight reviews
- Art. 6
Maintain a documented ICT risk management framework with strategies, policies and tools covering the whole ICT estate.
What you do
- Write a digital operational resilience strategy
- Review it at least yearly
- Art. 5
Management bodies keep up enough ICT knowledge to understand risk and keep it current.
What you do
- Provide leadership training
- Log attendance
Evidence to keep
- Board-approved ICT risk framework
- Management training records
- Digital resilience strategy
Systems, identification and protection (Arts. 7-9)Know your assets and protect them.3 obligations
- Art. 7
Use ICT systems, protocols and tools that are reliable, sufficiently capable and technologically resilient.
What you do
- Review capacity and obsolescence
- Plan upgrades
- Art. 8
Identify, classify and document ICT-supported business functions, assets and dependencies.
What you do
- Keep an asset register tied to business functions
- Review it after changes
- Art. 9
Protect and prevent through security policies, network controls, authentication, cryptography and change management.
What you do
- Apply least privilege and strong authentication
- Run a formal change process
Evidence to keep
- ICT asset and dependency inventory
- Policies for access, encryption and change
- Business function mapping
Detection, response and recovery (Arts. 10-12)Spot anomalies and recover.3 obligations
- Art. 10
Have mechanisms to detect anomalous activity, incidents and single points of failure promptly.
What you do
- Deploy logging and alerting
- Review alerts on a schedule
- Art. 11
Maintain an ICT business continuity policy and response and recovery plans, and test them.
What you do
- Set recovery time and point objectives
- Test at least yearly
- Art. 12
Define backup policies, restoration and recovery methods and test them.
What you do
- Keep segregated backups
- Record restore tests
Evidence to keep
- Monitoring and alerting records
- Response and recovery plans
- Backup and restoration test reports
Learning and communication (Arts. 13-14)Improve after events and communicate well.2 obligations
- Art. 13
Collect lessons from incidents and tests, monitor threats and run ICT security awareness and training.
What you do
- Hold a lessons-learned review after every major event
- Update controls from findings
- Art. 14
Have communication plans for disclosing incidents and vulnerabilities to clients, counterparts and the public.
What you do
- Draft templates and spokesperson roles
- Rehearse them
Evidence to keep
- Post-incident review reports
- Staff ICT security awareness records
- Crisis communication plan
p2Pillar 2: ICT incident management and reportingHandle, classify and report incidents.2 article groups · 6 obligations
Incident process (Arts. 17-18)A defined way to detect, classify and respond to ICT incidents.2 obligations
- Art. 17
Define, establish and implement an ICT-related incident management process covering detection, logging, escalation and root cause analysis.
What you do
- Write the process and assign roles
- Record each incident
- Art. 18
Classify incidents and significant cyber threats using set criteria, such as clients affected, duration, geographical spread and data loss.
What you do
- Embed criteria into triage
- Review classification quality
Evidence to keep
- Incident management procedure
- Classification criteria and records
- Root cause analyses
Reporting to authorities (Arts. 19-23)Report major incidents on a staged timeline to your competent authority.4 obligations
- Art. 19
Report major ICT-related incidents to your competent authority using initial, intermediate and final reports, and inform affected clients where their financial interests are involved.
What you do
- Pre-fill reporting templates
- Check the current deadlines in the technical standards
- Art. 19 (voluntary)
You may voluntarily notify significant cyber threats.
What you do
- Decide when to share them
- Record the rationale
- Art. 20
Use the standard forms and content for reports set by technical standards.
What you do
- Use the regulator's templates
- Keep them current
- Art. 23
Credit institutions, payment institutions and similar entities follow the extra rules for payment-related operational or security incidents.
What you do
- Check whether payment rules apply
- Align with existing payment incident reporting
Evidence to keep
- Major incident reports (initial, intermediate, final)
- Reporting templates
- Client notification records
p3Pillar 3: Digital operational resilience testingTest controls regularly, with advanced testing for some entities.1 article group · 4 obligations
Testing programme (Arts. 24-27)A risk-based programme of tests across ICT systems.4 obligations
- Art. 24
Maintain a risk-based digital operational resilience testing programme as part of your ICT risk framework.
What you do
- Plan tests by system criticality
- Fix findings by agreed deadlines
- Art. 25
Use appropriate tests such as vulnerability assessments, network security assessments, gap analysis, source code reviews, scenario tests and penetration testing.
What you do
- Schedule recurring scans and pen tests
- Test critical systems at least yearly where required
- Art. 26
Entities identified by authorities carry out threat-led penetration testing (TLPT) on live production systems at set intervals.
What you do
- Check whether authorities have designated you
- Plan scope and a red team provider
- Art. 27
Use testers who meet independence, skill, certification and insurance requirements for TLPT.
What you do
- Verify credentials and conflicts
- Agree rules of engagement
Evidence to keep
- Annual testing programme
- Test reports and remediation plans
- Tester independence and qualification records
p4Pillar 4: ICT third-party riskManage risk from ICT providers through contracts and oversight.3 article groups · 8 obligations
Third-party risk framework (Arts. 28-29)Keep full responsibility for outsourced ICT and know your dependencies.5 obligations
- Art. 28(2)
Adopt and review a strategy on ICT third-party risk, including a policy on providers supporting critical or important functions.
What you do
- Write the strategy and get board approval
- Review yearly
- Art. 28(3)
Keep a register of information on all contractual arrangements with ICT third-party providers, and report it to authorities as required.
What you do
- Build the register with provider, service, function and subcontractor details
- Update after each contract change
- Art. 28
Assess risk before signing, including concentration risk, and keep monitoring during the contract.
What you do
- Run due diligence checks
- Review critical providers regularly
- Art. 28(8)
Have exit strategies and transition plans for ICT services supporting critical or important functions.
What you do
- Document exit steps and test them
- Identify alternative providers
- Art. 29
Assess ICT concentration risk before relying heavily on one provider or closely connected providers.
What you do
- Map where one provider supports many functions
- Record the decision
Evidence to keep
- ICT third-party risk strategy and policy
- Register of information
- Due diligence and concentration risk assessments
- Exit plans
Contract terms (Art. 30)Contracts must contain set protections.2 obligations
- Art. 30(2)
Include in every ICT contract a clear description of services, locations, data protection, access and recovery rights, service levels, incident support, cooperation with authorities and termination rights.
What you do
- Use a standard DORA addendum
- Check legacy contracts
- Art. 30(3)
For services supporting critical or important functions, add stronger terms such as detailed service levels, testing participation, audit and access rights, exit support and subcontracting conditions.
What you do
- Prioritise critical contracts for amendment
- Track progress
Evidence to keep
- Contract clause checklist
- Executed contracts and amendments
- Subcontracting records
Oversight of critical providers (Arts. 31-44)EU authorities directly oversee designated critical ICT third-party providers.1 obligation
- Art. 31
Know that European Supervisory Authorities designate critical ICT third-party providers and oversee them directly.
What you do
- Check published designation lists
- Do not treat designation as a substitute for your own oversight
Evidence to keep
- Note of which of your providers are designated critical
p5Pillar 5: Information sharingShare cyber threat information in trusted communities.1 article group · 2 obligations
Information-sharing arrangements (Art. 45)Voluntary exchange of threat intelligence within trusted communities.2 obligations
- Art. 45
Financial entities may exchange cyber threat information and intelligence within trusted communities if data protection, confidentiality and competition rules are respected.
What you do
- Join a sector sharing group
- Set rules on what is shared and who can share it
- Art. 45 (notify)
Notify your competent authority when you take part in or leave such an arrangement.
What you do
- Record the notification
- Review membership yearly
Evidence to keep
- Arrangement or membership records
- Information sharing rules
- Notification to authorities of participation
Supervision and penalties (Arts. 46-56)Authorities supervise compliance and can impose measures.1 article group · 3 obligations
Competent authoritiesNational financial supervisors oversee DORA compliance.3 obligations
- Art. 46
Identify the authority responsible for supervising you under DORA.
What you do
- Record contact details
- Subscribe to its updates
- Art. 50
Authorities set administrative penalties and remedial measures for breaches.
What you do
- Track findings and remediation
- Report exposure to the board
- Art. 56
Be aware that supervisory cooperation with other EU authorities may occur.
What you do
- Keep documentation consistent across regulators
- Name a regulatory liaison
Evidence to keep
- Contact list for your competent authority
- Regulator correspondence log
Nothing matches. Clear the search or pick another pillar.
Outcomes and implementation examples are from Regulation (EU) 2022/2554, DORA (EUR-Lex), published by NIST. Descriptions of what to do and the evidence lists are our own plain-English guidance. Check the official source for the authoritative text.
Your path to getting started
Five steps from first look to ready. Effort depends on your size and starting point.
- 1
Confirm scope
Entity type and size.
- 2
Gap assess
Against the five pillars.
- 3
Build the provider register
All ICT third parties.
- 4
Set up incident reporting
Classification and templates.
- 5
Test and review
Yearly cycle.
How Optimus GRC helps
Each area maps to a part of the platform, so the work and the evidence sit together.
| What it asks | What you do in Optimus GRC |
|---|---|
| ICT risk management | Risk register and controls |
| Incident reporting | Incident workflow |
| Resilience testing | Test plans and results |
| Third-party risk | Provider register |
| Information sharing | Sharing log |
| Governance | Board records |
Free DORA readiness checklist
A one-page PDF you can print or share with your team. No sign-up needed.
Download the checklist (PDF)- Third-party register template
- Incident classification guide
- ICT risk policy
- Test plan
Share or cite this page
Writing about DORA? You are welcome to link to this guide. Copy the link below.
<a href="/frameworks/dora/">DORA explained in plain English - Optimus CyberX</a>Common questions
Who is covered?
Most EU financial entities, from banks and insurers to payment firms, and ICT providers designated as critical.
How does it relate to NIS2?
DORA is the financial sector rule and takes precedence for those firms.
Is there a certificate?
No. DORA is a law, not a certification scheme. You show compliance through your own documentation, testing and reporting, and regulators supervise it.
Who supervises?
National financial regulators and EU supervisory authorities.
Related frameworks
See how ready you are for DORA
Answer questions across every area. We email you a report showing where you comply and where you do not.