What is DORA?

DORA in plain English

Without IT, a bank today grinds to a halt: no transfers, no online banking, no card payments. If a major provider goes down, many people and businesses feel the impact. DORA is designed to prevent such outages or at least make them quickly manageable. The abbreviation stands for “Digital Operational Resilience Act” – officially, the EU regulation on digital operational resilience for the financial sector.

Resilience means the ability to withstand disruption. It is not just about fending off attacks but also about getting back up and running quickly after an incident. Think of fire protection in a building: smoke detectors, escape routes, fire extinguishers, and regular drills all belong together. DORA requires this kind of complete package for IT.

DORA’s official name is Regulation (EU) 2022/2554. It applies directly in all EU member states. In Germany, compliance is supervised primarily by BaFin, the Federal Financial Supervisory Authority.

What DORA requires

DORA applies to 20 types of financial entities – from credit institutions and payment service providers to investment firms, insurers, and crypto-asset service providers. Smaller companies don’t have to implement everything to the same extent; the principle of proportionality applies. The regulation rests on five pillars:

1. ICT risk management: ICT stands for information and communication technology. Companies need a documented framework to identify IT risks, protect systems, detect incidents, and recover from them. Ultimate responsibility explicitly lies with senior management.
2. Incident reporting: Major ICT-related incidents must be reported to the supervisory authority. As a rule, the initial notification is due no later than four hours after the incident has been classified as major and no later than 24 hours after the company became aware of it. Intermediate and final reports follow.
3. Resilience testing: Companies need a testing program – from vulnerability scans and source code reviews to penetration tests. Systems that support critical or important functions must be appropriately tested at least once a year; microenterprises are exempt from this requirement.
4. Managing third-party risk: Companies that use IT service providers remain responsible themselves. Contracts must contain specified minimum provisions, all arrangements are recorded in a register of information, and important services require exit strategies – plans for an orderly switch to another provider. Particularly significant providers, such as large cloud providers, are subject to direct oversight at the EU level.
5. Information sharing: Financial entities may exchange information on threats within trusted communities.

In addition, selected financial entities must conduct a threat-led penetration test – TLPT for short – at least every three years. The supervisory authority determines which companies these are. In a TLPT, a red team – experts who act like real attackers – targets the production systems, meaning the live systems in actual operation. The test is modeled on real threat actor groups; methodologically, it follows the European TIBER-EU framework.

A practical example

Here’s a typical scenario: A regional bank has its online banking operated by an external data center and uses a cloud service for email. As part of its DORA implementation, it records all IT service providers in its register of information. In the process, it notices that an older contract contains neither audit rights nor an exit clause. The contract is renegotiated.

At the same time, the bank reorganizes its testing program: the banking app and public interfaces undergo a penetration test every year, and internal systems are scanned regularly. An emergency drill also reveals that the reporting chain for major incidents doesn’t work on weekends. That is adjusted as well.

Why does this matter for businesses?

For financial entities, DORA is binding law. The supervisory authority reviews implementation and can impose measures and sanctions for violations. Because senior management bears ultimate responsibility, DORA is explicitly a top-management issue.

But DORA also affects companies outside the financial sector. IT service providers, software companies, and data centers that work for banks or insurers should expect new contract clauses: audit and access rights, support during incidents, participation in tests, and evidence of their own security.

For the financial sector, DORA is also considered the more specific law relative to NIS2: where DORA governs IT security, its requirements take precedence.

What businesses should do now

• Determine whether you’re affected: Check whether DORA applies to you directly as a financial entity or indirectly as a service provider.
• Analyze gaps: Compare your ICT risk management against the requirements and document responsibilities.
• Practice the reporting process: Make sure incidents are classified quickly and reported on time – including at night and on weekends.
• Record service providers: Keep your register of information complete and check contracts for the minimum provisions.
• Set up a testing program: Plan vulnerability scans, penetration tests, and scenario-based tests according to risk, and document the results and remediation.
• Prepare for TLPT: If a TLPT could apply to you, build a solid foundation with penetration tests and red teaming exercises.

Note: This article provides a general overview and does not constitute legal advice.

How Rootsektor can help

As a Germany-based security company, we perform penetration tests for financial entities and their service providers – designed to fit into your DORA testing program and covering everything from online banking and banking apps to interfaces and internal infrastructure. You’ll find details on our Financial Services page. We offer scenario-based attacks modeled on TIBER-EU through our Red Teaming & APT Simulation service. Our report and test certificate document scope, methodology, and results – for example, for presentation to auditors and business partners.