DORA Compliance for Financial Entities: What You Actually Need to Do

What is DORA?

The Digital Operational Resilience Act (Regulation 2022/2554) is the EU’s regulation on ICT risk management for the financial sector. It entered into application on 17 January 2025. There is no transition period. If you are in scope, compliance is already mandatory.

DORA exists because financial regulators observed that a single IT failure at a cloud provider or payment processor can cascade across the entire financial system. The regulation forces financial entities to treat ICT risk as seriously as credit risk or market risk - with dedicated governance, testing, and reporting requirements.

For compliance officers and IT directors in financial institutions, this is not another checkbox exercise. DORA requires demonstrable operational resilience, not just documented policies.

Who is in scope?

DORA applies to a wide range of financial entities and their critical ICT service providers.

Entity Type	In Scope?	Notes
Credit institutions (banks)	Yes	Full DORA requirements
Payment institutions	Yes	Including payment service providers
Investment firms	Yes	MiFID-authorized firms
Insurance and reinsurance undertakings	Yes	Supervised by EIOPA
Crypto-asset service providers	Yes	Under MiCA and DORA
Central securities depositories	Yes	Full requirements
Trading venues	Yes	Regulated markets, MTFs, OTFs
Central counterparties	Yes	Full requirements
ICT third-party service providers	Yes, if designated “critical”	Subject to oversight framework
Microenterprises (<10 staff, <EUR 2M turnover)	Simplified	Lighter requirements under Article 16

Key point: If your company provides cloud hosting, data analytics, or software services to financial entities and is designated as a “critical ICT third-party service provider,” you are also in scope - even if you are not a financial institution yourself.

The five pillars of DORA

1. ICT Risk Management (Articles 5-16)

This is the foundation. Financial entities must establish and maintain an ICT risk management framework that includes:

• Governance: The management body must approve, oversee, and be accountable for the ICT risk management framework. This is not delegable to IT alone.
• Identification: Maintain an inventory of all ICT assets, systems, and dependencies. Map business functions to ICT systems.
• Protection and prevention: Implement policies for access control, encryption, network security, and patch management.
• Detection: Deploy monitoring systems to detect anomalous activities and ICT-related incidents.
• Response and recovery: Define and test response procedures. Maintain business continuity and disaster recovery plans with documented RTO/RPO targets.
• Learning and evolving: Conduct post-incident reviews. Feed lessons back into the framework.

What auditors look for: A documented, board-approved ICT risk management framework that is reviewed at least annually. Evidence that the management body received regular reports on ICT risk posture. Evidence that identified risks have mitigation plans with assigned owners and deadlines.

Common failure: Treating the ICT risk framework as a document that sits in a folder. DORA requires active management - if your last framework review was 14 months ago, that is a finding.

2. ICT-Related Incident Management (Articles 17-23)

Financial entities must classify, manage, and report ICT-related incidents using criteria defined in the regulation:

• Classification criteria: Duration, geographical spread, data losses, criticality of services affected, economic impact.
• Major incident reporting: Major incidents must be reported to the competent authority using standardized templates. Initial notification within 4 hours of classification. Intermediate report within 72 hours. Final report within one month.
• Voluntary notification: Entities may voluntarily report significant cyber threats.

What auditors look for: An incident classification procedure that maps to DORA criteria. Evidence of incident reports filed with regulators. A log of all ICT incidents, not just major ones.

3. Digital Operational Resilience Testing (Articles 24-27)

All in-scope entities must conduct regular testing of ICT systems. The requirements scale by entity size:

• Basic testing (all entities): Vulnerability assessments, network security testing, gap analysis, software security testing, source code review where feasible.
• Threat-Led Penetration Testing (TLPT) (significant entities): Advanced testing at least every three years, conducted by qualified external testers under the TIBER-EU framework.

What auditors look for: A testing program with documented scope, results, and remediation tracking. For TLPT, evidence that tests covered critical functions and that findings were remediated.

4. ICT Third-Party Risk Management (Articles 28-44)

This pillar addresses concentration risk in ICT supply chains:

• Contractual requirements: All contracts with ICT service providers must include specific clauses on service levels, data location, audit rights, exit strategies, and subcontracting restrictions.
• Register of information: Maintain a register of all ICT service provider arrangements. Submit this to regulators (deadline: April 2025 for initial submission).
• Concentration risk: Assess whether reliance on a single provider or a small number of providers creates unacceptable systemic risk.
• Critical ICT third-party providers: Providers designated as “critical” by ESAs are subject to a direct oversight framework with inspections, recommendations, and potential penalties.

Common failure: Legacy contracts with ICT providers that lack DORA-compliant clauses. Renegotiating or amending these contracts takes time - if you have not started, you are behind.

5. Information Sharing (Article 45)

DORA encourages (but does not mandate) financial entities to share cyber threat intelligence with each other. This is the least prescriptive pillar, but entities that participate in recognized threat intelligence sharing arrangements may receive regulatory credit.

DORA vs NIS2: the overlap and the differences

Both DORA and NIS2 address cybersecurity in the EU, but they serve different purposes.

Dimension	DORA	NIS2
Legal instrument	Regulation (directly applicable)	Directive (requires national transposition)
Sector scope	Financial sector only	18 sectors including energy, health, transport, digital infrastructure
Relationship	DORA is lex specialis for financial entities	NIS2 is the general cybersecurity framework
Incident reporting	4-hour initial notification	24-hour early warning
Testing requirements	Mandatory TLPT for significant entities	General obligation to test, no TLPT mandate
Third-party oversight	Direct oversight of critical ICT providers	Supply chain risk management obligations
Penalties	Up to 2% of global turnover; EUR 5M for critical ICT providers	Up to EUR 10M or 2% of global turnover

Key point: If your entity falls under both DORA and NIS2, DORA takes precedence for ICT-related requirements (lex specialis principle, Article 4 NIS2). You do not need to comply with both for the same obligations - but you do need to understand which regulation applies to which requirement.

Key metrics you must track

DORA does not prescribe specific RTO/RPO numbers, but it requires that these targets exist, are documented, and are tested:

• Recovery Time Objective (RTO): How quickly must each critical function be restored? Your RTO must be defined per business function, not as a blanket number.
• Recovery Point Objective (RPO): How much data loss is acceptable? This drives your backup frequency.
• Incident detection time: How quickly do you detect ICT incidents? DORA expects continuous monitoring.
• Incident classification time: You have 4 hours from classification to initial regulatory notification for major incidents.
• Testing frequency: Basic ICT testing at least annually. TLPT at least every three years for significant entities.
• Third-party register completeness: Regulators will check whether your register of ICT provider arrangements is complete and current.

How to start preparing

1. Determine your scope: Are you a financial entity under DORA? Is your entity classified as significant (requiring TLPT)?
2. Gap analysis: Compare your current ICT risk management framework against DORA Articles 5-16. Identify missing elements.
3. Contract review: Audit all ICT provider contracts for DORA-compliant clauses. Prioritize critical providers.
4. Incident management: Verify your incident classification procedure maps to DORA criteria and your reporting chain can meet the 4-hour initial notification window.
5. Testing program: Establish or update your ICT testing program. If TLPT is required, begin scoping and vendor selection.
6. Board engagement: Ensure the management body formally approves the ICT risk management framework and receives regular reporting.

AuditFront and DORA

AuditFront is building a structured DORA compliance assessment module, scheduled for Q2 2026. It will cover all five DORA pillars with control-level assessments, gap identification, and remediation planning - the same assessment-first approach we use for ISO 27001, GDPR, and NIS2.

If you want to be notified when the DORA module launches, create a free account and we will notify you directly.

In the meantime, organizations preparing for DORA can use AuditFront’s existing ISO 27001 and NIS2 assessments to address overlapping ICT risk management requirements. Many DORA controls map directly to ISO 27001 Annex A controls - work done on one framework reduces effort on the other.