DORA Compliance Checklist for Financial Institutions (2026)

The Digital Operational Resilience Act (DORA) has been fully applicable since 17 January 2025. For financial entities across the EU, it is no longer a project to plan — it is a baseline to demonstrate. This checklist breaks DORA down into its five pillars and the concrete, auditable items behind each one, so you can quickly see where your programme is solid and where the gaps are.

What is DORA and who does it apply to?

DORA — Regulation (EU) 2022/2554 — establishes uniform requirements for the security of network and information systems supporting the business processes of financial entities. Its goal is to make sure the EU financial sector can withstand, respond to and recover from all types of ICT-related disruptions and threats.

It applies broadly — to roughly twenty categories of financial entities, including:

• Credit institutions, payment institutions and electronic money institutions
• Investment firms and crypto-asset service providers (CASPs)
• Insurance and reinsurance undertakings and intermediaries
• Central securities depositories, central counterparties and trading venues
• Management companies, crowdfunding service providers and more

Critically, DORA also reaches ICT third-party service providers — and the European Supervisory Authorities (ESAs) can designate some as Critical Third-Party Providers (CTPPs) subject to direct oversight. A proportionality principle applies, so the depth of expected controls scales with the size and risk profile of the entity.

The five DORA pillars

Pillar 1 — ICT Risk Management (Articles 5–16)

The foundation. DORA requires a documented ICT risk management framework owned and overseen by the management body, covering the full lifecycle: identify, protect, detect, respond and recover. The management body is explicitly accountable — this is not a control you can fully delegate to IT.

• The management body has approved, and actively oversees, the ICT risk management framework
• A current ICT asset inventory is maintained (hardware, software, data flows and third-party dependencies)
• Security policies cover access control, encryption, patch management, network security, physical security and logging
• Business Continuity (BCP) and Disaster Recovery (DRP) plans are documented and tested
• Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined per critical or important function
• An Incident Response Plan (IRP) is in place and staff are trained on it
• Post-incident reviews feed lessons learned back into the framework

Pillar 2 — ICT Incident Management and Reporting (Articles 17–23)

You must detect, manage and classify ICT-related incidents, and report major incidents to your competent authority in three phases. Getting classification criteria documented up front is what prevents teams from arguing about whether to report while the clock is running.

• An incident classification matrix distinguishes major from non-major incidents using DORA criteria (clients affected, data losses, duration, geographic spread, economic impact)
• An incident register is maintained with all required fields
• Templates for the initial, intermediate and final reports are prepared in advance
• The competent authority and reporting channel are identified (routed via the national regulator to EBA / ESMA / EIOPA depending on entity type)
• Procedures exist for notifying affected clients of major incidents and significant cyber threats
• Staff know the classification criteria and the escalation path

Pillar 3 — Digital Operational Resilience Testing (Articles 24–27)

DORA mandates a risk-based testing programme for every entity, plus a more demanding regime for significant entities. The common failure here is producing findings that nobody remediates — DORA expects the full cycle, including tracked remediation.

Basic testing (all entities, at least annually):

• An annual testing programme covers vulnerability assessments, network security assessments, gap analyses and penetration testing
• Testing covers the ICT systems and services that support critical or important functions
• Findings are tracked and remediation is planned, owned and monitored to closure

Threat-Led Penetration Testing — TLPT (significant entities, at least every 3 years):

• Whether the entity is in scope for TLPT has been assessed with the competent authority
• TLPT scope covers critical functions running in live production
• Accredited threat-intelligence providers and testers are identified, with TLPT conducted on a TIBER-EU basis
• An attestation is obtained from the relevant authority once the test is complete

Pillar 4 — ICT Third-Party Risk Management (Articles 28–44)

The most operationally intensive pillar — and, for most institutions, the largest backlog. DORA sets out due-diligence expectations, mandatory contractual clauses (Article 30), and a structured Register of Information describing all contractual arrangements for the use of ICT services.

• An ICT third-party risk management policy is documented and approved
• All ICT third-party contractual arrangements are inventoried
• Arrangements supporting critical or important functions (CIFs) are clearly identified
• A Register of Information is maintained in the ESAs' prescribed format and is ready for supervisory reporting
• A pre-contractual due-diligence process is defined and applied to new providers
• Contracts are reviewed against Article 30 mandatory clauses — audit and access rights, service-level descriptions, data security, sub-contracting limits, business-continuity obligations and termination rights
• Concentration risk across providers is monitored
• Documented exit strategies and transition plans exist for providers supporting critical functions
• Providers designated as Critical Third-Party Providers (CTPPs) by the ESAs are tracked

Pillar 5 — Information Sharing (Article 45)

Voluntary, but strategically valuable. Participating in trusted cyber-threat-intelligence sharing arrangements reduces exposure and signals a proactive resilience posture to supervisors.

• The organisation is aware of relevant sharing networks (sector ISACs, ENISA, national CERTs)
• A documented decision exists on whether to participate and under what governance and confidentiality framework

The five gaps we see most often

1. Governance on paper only. DORA makes the management body genuinely accountable. Sign-off without understanding does not satisfy the intent — board members need to own ICT risk.
2. An incomplete asset inventory. Without an accurate, current map of ICT assets and dependencies, risk assessment and continuity testing rest on sand.
3. Legacy third-party contracts. Article 30 clauses are specific and rarely present in older agreements. Contract remediation is usually the single largest operational burden.
4. No classification matrix. Without documented criteria, teams debate whether an incident is "major" instead of triggering the reporting clock.
5. Testing without remediation. Pen-test and vulnerability findings that sit in a spreadsheet do not demonstrate resilience — DORA expects the loop to close.

How SephiraSec can help

SephiraSec offers independent DORA gap assessments, ICT risk management framework design, vulnerability and exposure management programmes, incident-response planning, and technical support for TLPT scoping and third-party register preparation. Based in Vienna, available across the EU, and working in English, German and Romanian.