DORA is now in force. As of January 17, 2025, the Digital Operational Resilience Act applies to all financial entities in the EU—including fintechs, payment institutions, and crypto-asset service providers.

If you're still figuring out what you need to have in place, this checklist breaks it down by DORA's five pillars with specific requirements from the regulation.

Who This Applies To

DORA covers:

Banks and credit institutions

Payment institutions and e-money institutions

Investment firms

Crypto-asset service providers

Crowdfunding platforms

Insurance undertakings

ICT third-party providers serving any of the above

If you're a fintech operating in the EU or serving EU financial entities, you're in scope.

The Five Pillars

Pillar	DORA Articles	Core Requirement
ICT Risk Management	Articles 5-16	Documented risk management framework
Incident Reporting	Articles 17-23	Report major incidents within 72 hours
Resilience Testing	Articles 24-27	Regular vulnerability and penetration testing
Third-Party Risk	Articles 28-44	Manage and report ICT provider dependencies
Information Sharing	Article 45	Participate in threat intelligence exchange

Digital operational resilience - interconnected systems

Pillar 1: ICT Risk Management (Articles 5-16)

This is the foundation. Article 6 requires a documented ICT risk management framework reviewed annually.

Governance (Article 5)

[ ] Management body accountability - Board/C-suite formally responsible for ICT risk

[ ] Defined roles - Clear ownership for ICT security, risk, and compliance

[ ] Adequate budget - Resources allocated for ICT risk management

[ ] Training - Management trained on ICT risks relevant to the business

Framework Requirements (Article 6)

[ ] ICT risk management policy - Documented, approved by management

[ ] Digital operational resilience strategy - How you'll implement the framework

[ ] Annual review - Framework reviewed and updated yearly

[ ] Internal audit - ICT risk framework audited by qualified auditors

[ ] Remediation process - Formal follow-up on audit findings

Risk Identification & Protection (Articles 7-9)

[ ] ICT asset inventory - All hardware, software, and data assets documented

[ ] Asset classification - Assets categorized by criticality

[ ] Risk assessment - Threats and vulnerabilities identified for critical assets

[ ] Threat modeling - Systematic identification of ICT threats (see STRIDE methodology)

[ ] Protection measures - Controls documented and implemented

Detection & Response (Articles 10-14)

[ ] Monitoring capabilities - Anomaly detection for ICT systems

[ ] Incident response procedures - Documented, tested response plans

[ ] Business continuity plan - Recovery procedures for ICT disruptions

[ ] Backup policy - Regular backups, tested restoration

[ ] Communication plan - Internal and external communication during incidents

Pillar 2: Incident Reporting (Articles 17-23)

Major ICT incidents must be reported to your national competent authority.

Classification

[ ] Incident classification criteria - Define what constitutes "major" based on:

- Number of affected clients/counterparties

- Duration of the incident

- Geographic spread

- Data losses

- Economic impact

- Criticality of affected services

Reporting Timeline

Report	Deadline	Content
Initial notification	4 hours after classification	Basic incident details
Intermediate report	72 hours	Analysis, impact assessment, mitigation steps
Final report	1 month	Root cause, total impact, remediation completed

Requirements

[ ] Incident log - All ICT incidents recorded (not just major ones)

[ ] Classification process - Procedure to assess if incident is "major"

[ ] Reporting templates - Pre-prepared templates for each report type

[ ] Contact points - Identified contacts at relevant competent authorities

[ ] Post-incident review - Root cause analysis after major incidents

Pillar 3: Digital Operational Resilience Testing (Articles 24-27)

Regular testing is mandatory. The depth depends on your entity's size and risk profile.

For All Entities

[ ] Vulnerability assessments - At least annually

[ ] Network security testing - Regular scans and assessments

[ ] Gap analysis - Compare current state to DORA requirements

[ ] Scenario-based testing - Simulate ICT disruption scenarios

[ ] Remediation tracking - Document and track findings to resolution

For Significant Entities (Article 26)

If designated as significant by your regulator:

[ ] Threat-Led Penetration Testing (TLPT) - Every 3 years minimum

[ ] TIBER-EU framework - TLPT must follow recognized framework

[ ] Independent testers - External or internal with independence

[ ] Scope coverage - Critical functions and supporting ICT systems

[ ] Purple teaming - Collaborative testing with red/blue teams

Testing Documentation

[ ] Testing policy - Documented approach, frequency, scope

[ ] Test results - Findings documented with severity ratings

[ ] Remediation evidence - Proof that findings were addressed

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

Your vendors are your risk. DORA requires formal management of ICT service providers.

Register of Information

Deadline: April 30, 2025 - Submit to national competent authority

[ ] Complete register - All ICT third-party service providers listed

[ ] Contract details - Service descriptions, data locations, subcontractors

[ ] Criticality assessment - Which providers support critical functions

[ ] Concentration risk - Identify over-reliance on single providers

Due Diligence

[ ] Pre-contract assessment - Evaluate provider before signing:

- Financial stability

- Technical capability

- Security certifications

- Business continuity arrangements

- Subcontracting practices

[ ] Ongoing monitoring - Regular review of provider performance

[ ] Right to audit - Contractual right to audit provider's controls

Contract Requirements (Article 30)

Contracts with ICT providers must include:

[ ] Service level descriptions - Clear, measurable SLAs

[ ] Data locations - Where data is processed and stored

[ ] Security requirements - Specific security obligations

[ ] Incident notification - Provider must report incidents to you

[ ] Audit rights - Your right to audit or request certifications

[ ] Exit strategy - Termination provisions and transition support

[ ] Subcontracting rules - Approval requirements for subcontractors

Exit Planning

[ ] Exit strategy documented - For each critical ICT provider

[ ] Transition plan - How to migrate to alternative provider

[ ] Data portability - Arrangements to retrieve your data

Pillar 5: Information Sharing (Article 45)

Voluntary but encouraged. Sharing threat intelligence strengthens collective resilience.

[ ] Sharing arrangements considered - Evaluate industry ISACs, FSB groups

[ ] Legal review - Ensure sharing complies with data protection

[ ] Threat intelligence feeds - Subscribe to relevant feeds

[ ] Internal distribution - Process to act on shared intelligence

Key Deadlines

Date	Requirement
Jan 17, 2025	Full DORA compliance required
Apr 30, 2025	Submit Register of Information to competent authority
Jul 2025	ESAs notify critical ICT third-party providers
Jan 17, 2026	European Commission review report due
Ongoing	Annual framework review, regular testing

Penalties

Non-compliance carries real consequences:

Entity Type	Maximum Penalty
Financial entities	2% of annual global turnover
Critical ICT providers	Up to EUR 5 million
Individuals	Up to EUR 500,000

Daily fines can apply for up to 6 months until compliance is achieved.

Beyond fines: increased regulatory scrutiny, reputational damage, and potential restrictions on EU market access.

How Threat Modeling Supports DORA

Articles 7-9 require systematic identification of ICT risks. Threat modeling delivers exactly that:

DORA Requirement	Threat Modeling Deliverable
ICT asset identification	Data flow diagrams
Risk identification	STRIDE threat analysis
Vulnerability assessment	Prioritized threat inventory
Protection measures	Documented mitigations
Audit evidence	Threat model documentation

A documented threat model provides the systematic, repeatable risk assessment that auditors expect under DORA.

Quick Compliance Assessment

Answer these to gauge your readiness:

1. Do you have a documented ICT risk management policy approved by management?

2. Can you produce a complete list of ICT third-party providers with contract details?

3. Do you have incident response procedures with defined timelines?

4. Have you conducted vulnerability assessments in the past 12 months?

5. Is there an annual review process for your ICT risk framework?

If you answered "no" to any of these, prioritize those areas.

Key Takeaways

DORA is now in force (January 17, 2025)—compliance isn't optional

Five pillars: ICT risk management, incident reporting, resilience testing, third-party risk, information sharing

April 30, 2025: Register of Information submission deadline

Penalties: Up to 2% of global turnover for financial entities

Documentation is critical: Auditors want evidence of systematic processes

Threat modeling supports Articles 7-9 risk identification requirements

Next Steps

Need help meeting DORA's risk identification requirements? Professional threat modeling provides the documented, systematic assessment that satisfies Article 6's framework requirements.

Get a DORA-ready threat model

Sources:

DORA Official Text - EUR-Lex

Article 6 ICT Risk Management Framework

EIOPA - Digital Operational Resilience Act

QuoIntelligence - DORA Explained

Bitsight - DORA Compliance Checklist

Found this helpful?

Share it with your network

Written by

Jeffrey von Rotz

Founder

Building tools to make threat modeling accessible to every development team.

Ready to automate your threat modeling?

Join security teams using Ansvar to build comprehensive threat models in days, not weeks.

Get Started