DORA: Proving Digital Resilience in the Financial Sector

What Is DORA?

DORA is an EU regulation and therefore applies directly — without national transposition laws. It harmonizes the requirements for digital operational resilience across the entire European financial sector. In Germany, BaFin is the competent supervisory authority; at EU level, the three supervisory authorities EBA, EIOPA, and ESMA additionally oversee critical ICT third-party providers directly.

The underlying idea: financial entities today depend heavily on ICT — on their own systems as much as on cloud providers and software vendors. DORA shifts the focus from capital adequacy alone to whether an institution can withstand, report, and recover from severe ICT disruptions. For financial entities, DORA is the more specific regime relative to NIS2 (lex specialis): organizations in scope of DORA meet their cybersecurity obligations primarily there.

The regulation is fleshed out by regulatory and implementing technical standards (RTS/ITS) from the ESAs — for example on the ICT risk management framework, incident classification, and the register of information.

Who Does DORA Apply To — and Who Not?

DORA applies to you if …

… your organization belongs to one of the roughly 20 categories of financial entities covered by the regulation. These include, among others:

• Credit institutions, payment institutions, and e-money institutions.
• Investment firms, trading venues, and fund managers.
• Insurance and reinsurance undertakings as well as larger insurance intermediaries.
• Crypto-asset service providers under MiCA.
• Institutions for occupational retirement provision, credit rating agencies, and crowdfunding service providers.

… or if you provide ICT services to financial entities — for example as a cloud, software, or data center provider. Your customers must agree DORA-compliant contractual provisions (Art. 30) with you and include you in their register of information. ICT third-party providers designated as critical are additionally subject to direct oversight by the ESAs.

DORA follows the principle of proportionality: the scope and depth of measures depend on size, risk profile, and complexity. A simplified ICT risk management framework applies to microenterprises and certain categories of institutions.

DORA does not apply to you if …

… your organization is neither a regulated financial entity nor an ICT provider to one. Some exemptions also exist within the sector — for example for insurance intermediaries below certain size thresholds or very small occupational pension institutions.

The caveat: as soon as a financial entity is among your customers, the DORA requirements reach you indirectly through its third-party risk management — even without being supervised yourself.

The Five Pillars of DORA

• ICT risk management (Art. 5–16). A documented risk management framework with clear accountability of the management body: identification of critical functions, protection and detection measures, backup and recovery concepts.
• ICT incident handling and reporting (Art. 17–23). Incidents must be recorded, classified against uniform criteria, and major incidents reported to the authority within set deadlines — with an initial, intermediate, and final report.
• Digital operational resilience testing (Art. 24–27). A risk-based testing program for all entities; for designated institutions additionally threat-led penetration testing (TLPT) at least every three years.
• ICT third-party risk management (Art. 28–44). Assessment and monitoring of all ICT providers, mandatory contractual provisions (Art. 30), exit strategies — and the register of information covering all contractual arrangements, to be provided to the supervisor on request and on an annual cycle.
• Information sharing (Art. 45). Voluntary exchange of cyber threat information between financial entities.

The Typical Challenge in DORA Implementation

• The register of information as a permanent construction site. Maintaining hundreds of ICT contracts, subcontractor chains, and critical functions in spreadsheets is error-prone — and the submission to the supervisor comes due every year.
• Reporting deadlines without a rehearsed process. Whether an incident is reportable is decided against defined classification criteria — under time pressure. Without prepared procedures and responsibilities, every disruption turns into a crisis project.
• Duplicate work alongside existing standards. Much of what DORA requires already exists in an ISO 27001 ISMS or in C5 evidence — but is documented separately instead of being linked.

How Sightadel Simplifies DORA Implementation

Sightadel is the compliance portal within the Pervigon Security Suite. It represents the DORA requirements along the five pillars as a structured catalog to which you assign measures, owners, and evidence — including the register of information and incident processes.

DORA with Sightadel in Practice

1. 1
   Record.Inventory critical functions, ICT systems, and all ICT providers; build the register of information.
2. 2
   Assess.Gap analysis against the five pillars, a prioritized action plan with owners and deadlines.
3. 3
   Implement.Document the risk management framework, set up incident and reporting processes, plan the testing program, review contracts for Art. 30 conformity.
4. 4
   Maintain.Keep the register current, run tests and reviews on a recurring basis, and keep evidence retrievable for the supervisor and internal audit at any time.

Digital Resilience as a State, Not a Project

DORA has been living supervisory practice since January 2025: register submissions, incident reports, and tests recur. Sightadel keeps your DORA status continuously current — structured, auditable, and without every supervisory request triggering a new project.