DORA Compliance Checklist: What Financial Sector Security Managers Need to Know in 2025

The Digital Operational Resilience Act came into force on 17 January 2025. If your organisation is a financial entity operating in or serving the EU, compliance is not optional, and the penalties for getting it wrong are material. This guide explains what DORA actually requires from a security operations perspective, what continuous monitoring has to do with it, and gives you a practical 20-item checklist to audit your current posture.

What is DORA and Who Does It Apply To?

The Digital Operational Resilience Act (Regulation EU 2022/2554) is EU legislation designed to ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions, including cyberattacks, system failures, and third-party incidents. It entered into application on 17 January 2025, with no transitional period: the European Supervisory Authorities explicitly stated that financial entities were expected to be fully compliant from day one.

DORA applies to a broad range of financial entities, including:

• Banks and credit institutions
• Payment and electronic money institutions
• Investment firms and fund managers
• Insurance and reinsurance companies
• Crypto-asset service providers
• Central securities depositories and trading venues
• Credit rating agencies and data reporting service providers
• ICT third-party service providers designated as critical (CTPPs)

Crucially, DORA's reach extends beyond EU-headquartered entities. Non-EU ICT service providers that supply services to EU-based financial entities must also comply where their services are considered critical to those entities' operations. If your organisation provides cloud, data analytics, or other technology services to EU financial clients, DORA obligations may apply to you even if you are based outside the EU.

Proportionality applies, but does not mean exemption. DORA includes a proportionality principle: smaller and less complex financial entities may tailor their compliance efforts relative to their size, risk profile, and systemic importance. However, the five core pillars apply to all in-scope entities. Proportionality affects how you implement requirements, not whether you implement them.

20+ Types of financial entity in DORA's scope

17 Jan 2025 Full compliance required, no transitional period

2% Maximum fine of global annual turnover for financial entities

€5M Maximum fine for critical ICT third-party providers

DORA's 5 Pillars: What Each One Actually Requires

DORA is structured around five core pillars. Understanding what each pillar requires in practice, rather than in regulatory language, is the foundation of any compliance programme.

Pillar 1: ICT Risk Management

Establish and maintain a comprehensive ICT risk management framework. Identify all ICT-supported business functions, assets, and dependencies. Implement controls, policies, and governance structures. Board-level accountability is mandatory. Ultimate responsibility for ICT risk sits with senior management.

External monitoring relevance: Asset discovery and vulnerability scanning are core ICT risk identification tools under this pillar.

Pillar 2: ICT Incident Reporting

Detect, manage, classify, and report significant ICT-related incidents to national competent authorities. Initial notification required within 4 hours of classification as major. Intermediate report within 72 hours. Final report within one month. Maintain internal incident logs and root cause documentation.

External monitoring relevance: Continuous monitoring accelerates detection, ensuring the 4-hour notification clock starts as early as possible.

Pillar 3: Digital Operational Resilience Testing

Conduct regular testing of ICT systems including vulnerability assessments, open-source analyses, network security assessments, and gap analyses. Advanced testing via Threat-Led Penetration Testing (TLPT) required for significant entities at least every three years. Testing must reflect real-world threat scenarios.

External monitoring relevance: Continuous external scanning provides the baseline evidence that testing builds on, and demonstrates ongoing assessment between formal test cycles.

Pillar 4: ICT Third-Party Risk Management

Maintain a Register of Information covering all ICT third-party service providers. Conduct risk assessments before onboarding and continuously thereafter. Contractual agreements must include specific DORA provisions on security, incident reporting, and exit strategies. Critical ICT TPPs face enhanced oversight.

External monitoring relevance: Vendor risk monitoring directly satisfies the continuous monitoring requirement for third-party providers.

Pillar 5: Information Sharing

Financial entities are encouraged (and in some contexts required) to participate in information sharing arrangements about cyber threats, vulnerabilities, and indicators of compromise. Sharing must comply with data protection obligations and not compromise the security of participants.

External monitoring relevance: Threat intelligence feeds that surface sector-relevant threat actor activity directly support this pillar.

The External Risk Monitoring Requirements Hidden Inside DORA

When security managers read DORA for the first time, they often focus on the incident reporting timelines and the testing obligations. What is less immediately obvious, but equally important, is how much of DORA's ICT risk management framework depends on having continuous, documented visibility of your external attack surface.

The ICT risk management framework under Pillar 1 requires financial entities to:

• Maintain a complete and up-to-date inventory of all ICT assets, systems, and external-facing components
• Identify and document all network and information system components supporting critical functions
• Implement continuous monitoring of security controls and ICT infrastructure
• Detect and respond to anomalies and vulnerabilities on an ongoing basis
• Ensure early warning mechanisms for threats and vulnerabilities are in place

Each of these obligations points to the same operational requirement: you need to know what your external-facing infrastructure looks like at any given moment, and you need to be alerted when it changes or when new vulnerabilities are disclosed that affect it.

This is not satisfied by an annual penetration test. A penetration test provides a point-in-time assessment of your posture on the day it was conducted. DORA's language ("continuous monitoring," "ongoing basis," "early warning mechanisms") describes a programme, not an event. The regulation explicitly expects that you are monitoring continuously, not reviewing annually.

The documentation imperative: DORA requires financial entities to be able to demonstrate their ICT risk management programme to regulators. This means documented evidence of monitoring activity, findings discovered, and remediation taken, not just assertions that monitoring is happening. A monthly external risk report creates exactly this audit trail.

DORA Third-Party Risk: Your Register of Information Obligations

Pillar 4 is where many mid-market financial entities find their largest compliance gap. The ICT third-party risk management requirements are extensive and operationally demanding, particularly the Register of Information obligation.

What the Register of Information Requires

DORA requires all in-scope financial entities to maintain a comprehensive Register of Information covering every ICT third-party service provider they use. This register must be available at entity, sub-consolidated, and consolidated levels, and must be reportable to national competent authorities and the European Supervisory Authorities (ESAs) on request.

The register must include, for each ICT TPP:

• Identity of the provider and description of services
• Classification of whether the function supported is critical or important
• Date of contractual arrangement and next review date
• Evidence of security assessment and ongoing monitoring
• Sub-contractor information (where applicable)
• Exit strategy and substitutability assessment

Financial entities were required to submit their initial Register of Information to competent authorities by 30 April 2025. Ongoing maintenance and annual reporting is now a standing obligation.

Continuous Monitoring of Vendors

Beyond maintaining the register, DORA requires continuous monitoring of ICT third-party service providers, not just a one-time assessment at onboarding. This means tracking the security posture of critical vendors on an ongoing basis, being alerted to incidents affecting them, and being able to demonstrate that your vendor oversight programme is active rather than theoretical.

What "Continuous Monitoring" Means Under DORA in Practice

The phrase "continuous monitoring" appears repeatedly in DORA, in the ICT risk management framework requirements, in the third-party risk pillar, and in the resilience testing obligations. But what does it actually mean in an operational context for a mid-market financial entity without a large security team?

The regulation does not prescribe specific tooling. What it prescribes is an outcome: that vulnerabilities, threats, and anomalies are detected in a timely manner and that the organisation can demonstrate ongoing vigilance. In practice, this translates to:

External Attack Surface Monitoring

Continuous scanning of all internet-facing assets associated with your organisation, identifying new assets, new vulnerabilities in existing assets, expired or misconfigured SSL certificates, open ports that should not be accessible, and software versions with known CVEs. This should update frequently enough that a vulnerability disclosed today is reflected in your monitoring within hours, not weeks.

Credential and Dark Web Monitoring

Ongoing monitoring of your organisation's email domain against dark web breach databases, stealer log repositories, and credential marketplaces. DORA's ICT risk management framework requires identification of risks from compromised credentials, and credentials circulating on dark web markets are a documented ICT risk that point-in-time assessments will miss.

Third-Party Security Monitoring

Automated tracking of the external security posture of your critical ICT third-party providers, detecting changes in their vulnerability profile, SSL configuration, or security rating that could signal increased risk to your operations before an incident occurs.

Documented Outputs

Critically, "continuous monitoring" under DORA is not just about having the capability. It is about producing documented outputs that demonstrate the capability is active. A monthly security report that captures your monitoring findings, the actions taken, and the trend in your risk posture creates the audit evidence that regulators expect to see. An undocumented monitoring programme is, from a compliance perspective, the same as no monitoring programme.

The monthly report as compliance evidence: Under DORA's ICT risk management framework, organisations must be able to demonstrate ongoing monitoring to supervisory authorities. A structured monthly external risk report covering vulnerability findings, dark web exposure, vendor risk changes, and brand monitoring is exactly the kind of documented evidence that satisfies this requirement without requiring bespoke regulatory reporting infrastructure.

The Penalties for Non-Compliance

DORA is enforced at the national level by each EU member state's competent authority (for example, the FCA equivalent in each jurisdiction, the ECB for systemic banks, EIOPA for insurers). The penalties are significant and multidimensional.

2%: Maximum fine of total annual worldwide turnover for financial entities

€1M: Maximum individual fine for a responsible natural person at a financial entity

€5M: Maximum fine for critical ICT third-party providers

1%/day: Daily fines for CTPPs for up to 6 months until compliance is achieved

Beyond financial penalties, DORA empowers competent authorities to:

• Publicly disclose non-compliance, creating reputational damage that can affect customer trust and market position
• Suspend or prohibit contracts between financial entities and non-compliant ICT third-party providers
• Impose criminal penalties at each member state's discretion
• Require immediate remediation with supervisory oversight until compliance is demonstrated

Enforcement is now active. Supervisory reviews began immediately following the January 2025 application date. While the first wave of enforcement actions is likely to target the most egregious gaps, particularly around incident reporting and third-party registers, organisations should not interpret the absence of early fines as a signal that enforcement is not coming.

Your DORA Compliance Checklist: 20 Actionable Items

Use this checklist to audit your current posture against DORA's five pillars. Each item maps to a specific pillar and indicates whether it is satisfied by a point-in-time activity, a continuous programme, or both.

Pillar 1: ICT Risk Management Framework

• [ ] Board-approved ICT risk management policy in place, with named senior management accountability [P1]
• [ ] Complete and current inventory of all ICT assets supporting critical or important business functions [P1]
• [ ] External attack surface mapped: all internet-facing assets, subdomains, and cloud resources identified [P1]
• [ ] Continuous monitoring programme in place with documented outputs (not annual-only assessments) [P1]
• [ ] Vulnerability management process defined with SLAs for Critical, High, Medium findings [P1]

Pillar 2: ICT Incident Reporting

• [ ] Incident classification criteria defined: what constitutes a "major ICT incident" under DORA thresholds [P2]
• [ ] Incident reporting process documented: 4-hour initial notification, 72-hour intermediate, 1-month final [P2]
• [ ] Incident log maintained with root cause documentation for all significant events [P2]
• [ ] Competent authority contact and notification channel confirmed and tested [P2]

Pillar 3: Digital Operational Resilience Testing

• [ ] Annual vulnerability assessment and network security assessment scheduled and documented [P3]
• [ ] Threat-Led Penetration Testing (TLPT) programme in place for significant entities (3-year cycle) [P3]
• [ ] Continuous external scanning in place to bridge gap between formal test cycles [P3]

Pillar 4: ICT Third-Party Risk Management

• [ ] Register of Information completed and submitted to competent authority (deadline: 30 April 2025) [P4]
• [ ] Critical and important functions identified and mapped to ICT third-party providers [P4]
• [ ] Existing vendor contracts reviewed and updated to include DORA-required provisions [P4]
• [ ] Security assessments completed for all critical ICT third-party providers [P4]
• [ ] Continuous monitoring programme in place for critical vendor security posture [P4]
• [ ] Exit strategies documented for each critical ICT third-party provider [P4]

Pillar 5: Information Sharing

• [ ] Participation in sector-relevant threat intelligence sharing arrangements assessed and, where appropriate, enrolled [P5]
• [ ] Threat intelligence feed in place to receive early warning of sector-relevant threats and TTPs [P5]

How External Risk Monitoring Satisfies Multiple DORA Pillars at Once

One of the most practical observations about DORA compliance for mid-market security teams is that a well-implemented continuous external monitoring programme does not just satisfy one pillar. It generates evidence and capability that addresses obligations across Pillars 1, 2, 3, 4, and 5 simultaneously.

For a security manager at a mid-market financial entity, typically working without a large team and under pressure to demonstrate compliance across five regulatory pillars, this multi-pillar coverage is significant. A single continuous monitoring platform does not replace your incident response plan, your resilience testing programme, or your vendor contracts. But it provides the ongoing operational evidence that underpins all of them, and it does so in a format (monthly report) that is directly usable for regulatory and board-level reporting.

The Bottom Line

DORA is live, enforcement is active, and the compliance gaps most likely to attract early supervisory attention are the ones that are most visible: missing or incomplete Register of Information submissions, absent third-party monitoring programmes, and the inability to demonstrate that continuous monitoring is actually happening rather than just described in policy documents.

For a mid-market financial entity, the path to defensible DORA compliance does not require building an enterprise security operations centre from scratch. It requires having the right monitoring in place, producing documented outputs, and being able to walk a regulator through what you found, what you did about it, and how your risk posture has changed over time. That story is told by your monthly reports, not by your policy library.

Frequently Asked Questions

What is DORA and when did it take effect?

DORA (the Digital Operational Resilience Act, Regulation EU 2022/2554) is EU legislation requiring financial entities to withstand, respond to, and recover from ICT-related disruptions. It entered into full application on 17 January 2025 with no transitional period, meaning all in-scope entities were expected to be fully compliant from day one.

What does DORA require for ICT risk monitoring?

DORA's ICT risk management framework under Pillar 1 requires financial entities to maintain a complete inventory of all ICT assets, implement continuous monitoring of security controls, and detect anomalies and vulnerabilities on an ongoing basis. These obligations cannot be satisfied by annual penetration tests alone; the regulation explicitly expects continuous, documented monitoring activity.

How does continuous monitoring help with DORA compliance?

Continuous monitoring satisfies requirements across all five DORA pillars simultaneously, from asset discovery and vulnerability detection under Pillar 1 to vendor oversight under Pillar 4. It also produces timestamped, structured evidence that supervisory authorities expect to see during regulatory reviews, turning operational security into documented compliance proof.

Does DORA apply to third-party ICT service providers?

Yes. DORA's scope extends to ICT third-party service providers designated as critical (CTPPs), and non-EU providers that supply services to EU-based financial entities must also comply where their services are considered critical. Financial entities are required to maintain a Register of Information covering all ICT third-party providers and to monitor their security posture continuously, not just at onboarding.