DORA: Requirements for Digital Operational Resilience in the Financial Sector

DORA: What the Digital Operational Resilience Act Means for IT Decision-Makers in the Financial Sector #

The Digital Operational Resilience Act has been directly applicable EU law since 17 January 2025. Unlike a directive, DORA does not need to be transposed into national law: Regulation (EU) ²⁰²²⁄₂₅₅₄ applies directly in all member states. For IT managers, CISOs, and compliance officers at banks, insurance companies, and payment service providers, this means: the obligations are live, and supervisors are checking.

This article explains who DORA affects, what specific requirements apply to data backup and disaster recovery, how DORA relates to NIS2, and what penalties organisations face for non-compliance.

Reading time: approx. 8 minutes | Updated: April 2026

---

1. What Is DORA? Scope and Affected Organisations #

DORA stands for Digital Operational Resilience Act. The regulation establishes a unified framework for ICT risk management in the European financial sector and aims to ensure that financial institutions can withstand a broad spectrum of operational disruptions, from cyberattacks and system failures to third-party service provider failures.

Who Is Affected? #

An estimated 22,500 financial entities and ICT service providers in the EU fall within DORA’s scope, including:

• Credit institutions: banks, savings banks, cooperative banks
• Investment firms: brokers, trading houses
• Payment service providers: acquirers, issuers, PSPs
• Electronic money institutions: prepaid card providers, digital wallets
• Insurance and reinsurance undertakings: all lines
• Investment funds and asset management companies: UCITS, AIFs
• Crypto-asset service providers: exchanges, custodians (under MiCA)
• Data reporting services: trading and reporting systems
• Critical ICT third-party service providers: cloud providers, data centres, software vendors with systemic relevance

Micro-enterprises (fewer than 10 employees, less than EUR 2 million turnover) are exempt from certain requirements, but the core of the regulation applies to the vast majority of the sector.

---

2. The Five Pillars of DORA #

DORA structures its requirements across five areas. Each area establishes independent operational obligations.

Pillar 1: ICT Risk Management (Art. 5 to 16) #

Financial institutions must establish, document, and regularly test a comprehensive ICT risk framework. This includes: risk identification and classification, protective measures, anomaly detection, response capabilities, and recovery procedures. The management body bears responsibility, personally.

Pillar 2: ICT-Related Incident Management and Reporting (Art. 17 to 23) #

Major ICT incidents must be classified, documented, and reported to the competent national authority (in Germany, for example, BaFin). Deadlines are tight: under the implementing technical standards, the initial notification is due within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, with an intermediate report and a final report following.

Pillar 3: Digital Operational Resilience Testing (Art. 24 to 27) #

Regular baseline tests are mandatory for all affected entities, including threat-led penetration testing (TLPT) for significant institutions. Tests must be documented, vulnerabilities remediated, and results made available to supervisors.

Pillar 4: ICT Third-Party Risk (Art. 28 to 44) #

Contracts with ICT third-party service providers must include specific DORA-compliant clauses: availability guarantees, exit rights, audit rights, sub-contractor arrangements. Critical ICT third-party service providers are supervised directly by the European supervisory authorities (ESAs).

Pillar 5: Information Sharing (Art. 45) #

Financial institutions may, and are encouraged to, share information about cyber threats and vulnerabilities. Voluntary participation in information-sharing arrangements is explicitly provided for and regulatorily protected.

---

3. DORA and Data Backup: What Art. 9 and Art. 12 Specifically Require #

Backup and recovery are not a peripheral topic in DORA; they are explicitly regulated. Organisations with gaps here have a demonstrable compliance problem.

Art. 9: Protection and Prevention #

Art. 9 requires financial institutions to protect their ICT systems against data loss, unauthorised access, and manipulation. This includes segmentation, access controls, and, where technically appropriate, the physical or logical isolation of security-critical data copies.

Art. 12: Backup Policies and Recovery Procedures #

Art. 12 is the central backup standard under DORA. The requirements in overview:

• Documented backup policy: set out in writing, reviewed regularly
• RTO/RPO targets: must be defined, documented, and tested
• Backups of critical data: frequency aligned with the criticality of the data; for critical systems this means short intervals
• Isolated backup environment: backup systems must be protected against attacks spreading from the production network
• Testing obligation: recovery procedures must be tested regularly
• Restoration from secured environments: when restoring data, the entity must use systems that are segregated from the compromised environment

Particularly relevant: DORA does not only require that backups exist, but that they work. Proof of recoverability is subject to documentation requirements.

Isolation as a Protection Requirement #

The logic of Art. 12 is clear: backup copies must survive an attack on the production environment. For financial institutions that include ransomware scenarios in their risk analyses, isolated or offline copies are not a theoretical recommendation; they are a minimum expectation of supervisors.

---

How do you implement DORA-compliant data backup in practice? FAST LTA offers hardware-based air gap and immutable secondary storage architectures for the financial sector. Speak with our experts. Request a demo | Silent Brick System

---

4. DORA in Relation to NIS2 #

A common question in practice: which framework applies when both are in scope?

• Legal form: DORA is a regulation (directly applicable); NIS2 is a directive (national transposition required)
• Scope: DORA is financial sector specific; NIS2 is cross-sector
• Applicable since: DORA since 17 January 2025; NIS2 through national acts (transposition deadline was 17 October 2024; Germany, for example, since 6 December 2025)
• Relationship: DORA is lex specialis for the financial sector; NIS2 sets the general cybersecurity baseline
• Overlap: incident reporting and risk management overlap significantly

DORA applies as lex specialis: for financial institutions falling under both DORA and NIS2, DORA takes precedence within its regulatory scope. The more specific DORA obligations for ICT risk management and incident reporting supersede the general NIS2 requirements, provided an equivalent or higher level of protection is achieved.

---

5. Penalties and Liability #

DORA has teeth. The sanctions are stricter than in many other compliance frameworks.

Penalties for Critical ICT Third-Party Service Providers #

The European supervisory authorities (EBA, EIOPA, ESMA) can impose periodic penalty payments of up to 1% of average daily worldwide turnover of the preceding business year on critical ICT third-party service providers, applied daily until the breach is remediated. For large cloud providers or data centre service providers, this adds up rapidly to substantial amounts.

Sanctions Against Financial Institutions #

For regulated financial institutions, sanctions are the responsibility of national supervisory authorities (in Germany: BaFin). Possible measures range from warnings and remediation orders through to restrictions on business activity. Member states define the fine frameworks in national law.

Personal Liability of the Management Body #

A point that deserves attention in practice: DORA directly addresses the management body. Under Art. 5, boards and executive management bear responsibility for the ICT risk framework and must maintain sufficient knowledge of ICT risk. Where violations are established, supervisors can take measures against responsible persons. The era when ICT compliance was solely the IT department’s concern is regulatorily over.

---

6. Five Concrete Implementation Steps #

Organisations that have not yet fully addressed DORA should prioritise the following steps:

Step 1: Gap Analysis Against the Five DORA Pillars #

Assess your current ICT risk framework systematically against Art. 5 to 16. Documentation gaps and missing tests are the most common weaknesses. Use a structured mapping, ideally with external support from an audit firm or compliance adviser with DORA experience.

Step 2: Define and Test RTO and RPO in Writing #

Art. 12 requires documented recovery targets. Define concrete RTO and RPO values for each critical system and test recoverability regularly. A backup that has never been tested does not count as a reliable backup under the regulation.

Step 3: Ensure Backup Isolation #

Verify that your backup systems are genuinely isolated from the production network, not just logically, but physically or through galvanic separation. Systems reachable over the same network as primary systems provide no reliable protection in a ransomware scenario.

Step 4: Review and Update ICT Third-Party Contracts #

Go through all contracts with material ICT service providers. DORA prescribes specific contractual clauses: audit rights, availability guarantees, exit arrangements, sub-contractor management. Contracts concluded before 2025 will in most cases not meet DORA requirements.

Step 5: Establish and Rehearse Reporting Processes #

A few hours from classification to initial notification: that is little time if no tested process exists. Define now: who classifies? Who reports? What information is needed? Test the process with a tabletop exercise before a real incident forces the issue.

---

Conclusion: DORA Is Not a Project, It Is an Operational State #

DORA has been applicable law since January 2025. There is no transition period remaining. Financial institutions still in the gap-analysis phase are already in default. The backup and recovery requirements of Art. 12 in particular (isolated copies, tested RTO/RPO targets, segregated restore environments) are technically demanding and cannot be resolved through software configuration alone.

Physically isolated secondary storage architectures, as provided by the Silent Brick System and Silent Cubes, address exactly these requirements: hardware-based air gap, immutable data storage, and demonstrable recoverability, all on-premises and under full control of the institution, without dependency on cloud providers or external third-party services.

---

Further Resources #

→ IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → NIS2 Explained: Requirements, Fines, First Steps (/en/blog/nis2-einfach-erklaert/) → DORA ICT Third-Party Management (/en/blog/dora-ict-third-party-management/) → Defining RTO and RPO: How to Set Realistic Recovery Targets (/en/blog/rto-rpo-definieren/) → Incident Response Plan Template (/en/blog/incident-response-plan-vorlage/) → Silent Brick System (/en/produkte/silent-brick-system/) → Silent Cubes (/en/produkte/silent-cubes/)