DORA Readiness and the Path to Digital Operational Resilience Testing

With the EU’s Digital Operational Resilience Act (DORA) taking effect in January 2025, financial institutions need to prove that their ICT systems can withstand cyberattacks and disruptions. 

At the center of DORA is Digital Operational Resilience Testing (DORT). The regulation makes it clear that deploying security controls or patching known vulnerabilities is not enough. 

Instead, organizations need to continuously test and validate their defenses, against threats, across critical systems, and often in cooperation with third-party providers. This testing-based approach aims to build confidence that Europe’s financial system can stay stable even in the face of sophisticated attacks or unexpected outages.

Key highlights

• DORA mandates proactive digital operational resilience testing (DORT). Financial entities must regularly test their critical ICT systems and security controls to ensure they can withstand cyber threats and operational disruptions.
• Vulnerability scanning alone isn’t enough for DORA compliance. Scans help identify known weaknesses, but DORA requires a holistic, risk-based approach including simulated attack exercises and continuous control validation to truly gauge resilience.
• Key DORA testing requirements include at least annual testing of critical systems (e.g., through vulnerability assessments and penetration tests) and for significant institutions, an advanced threat-led penetration test (TLPT) every three years. All vulnerabilities found must be prioritized and remediated to improve resilience.
• Cymulate supports DORA compliance by providing continuous, automated breach-and-attack simulations that validate security controls against the latest threats. This enables financial organizations to frequently assess their defenses and get detailed remediation guidance, effectively putting the “DORT” in DORA to strengthen digital operational resilience.

Key ICT risks driving DORA compliance

ICT disruptions in finance stem from four main risk areas. The largest share, around 60% comes from cyberattacks, including hacking, ransomware, and DDoS campaigns. 

An EU study found that two-thirds of financial firms list cyber threats as their top concern. ENISA’s recent report confirmed this trend, noting a surge in attacks across Europe’s financial sector, often tied to geopolitical tensions and supply-chain targeting.

The remaining risks come from software or IT failures (~20%), third-party service disruptions (~15%), and power or hardware issues (~5%). Internal glitches like failed system upgrades continue to cause downtime, while outages or breaches at fintech or cloud providers can quickly cascade across multiple banks. Even rare physical failures, such as data-center power losses, can cripple operations without proper backup. 

At a high level, we can roughly break down the risks to financial ICT systems into a few major categories:

• Cyber Attacks (~60%): Malicious activities like hacking, malware, ransomware or DDoS are by far the biggest source of ICT disruptions. A study found 64% of financial firms cite cyber threats as a top risk. Attacks on financial institutions are rising, a recent ENISA report counted hundreds of cyber incidents in Europe’s finance sector, including waves of DDoS linked to geopolitical events and ransomware targeting service providers.
• Software/IT Failures (~20%): Internal IT changes or software glitches can also cause outages. In one EU study of 488 publicly reported incidents, IT change management and failure issues accounted for about 64% of operational incidents. Based on this study, we can safely assume ~20% of attacks are caused due to IT failures.
• Third-Party Service Disruptions (~15%): Incidents originating from external providers or supply chain failures are another significant chunk. Many banks rely on third-party fintech services or cloud providers; if one of those providers has an outage or breach, it can impact the bank. Over 60% of European financial institutions have experienced operational disruptions due to third-party vulnerabilities, according to a 2024 industry report. However, the collective percentage stands around ~15% accounting other attacks. 
• Power/Hardware Failures (~5%): Physical infrastructure problems (power outages, hardware faults, etc.) make up the remainder of ICT risk. These are less frequent but can still cause serious downtime if not planned for (e.g. backup generators failing).

While the exact percentages will vary by organization and study, cyber attacks consistently emerge as the largest risk area for disruptive incidents in the financial sector. They are the driving force behind DORA’s introduction in our increasingly digital financial world. 

Vulnerability scanning and DORA compliance: What you need to know

Vulnerability scanning is a core part of DORA’s testing requirements, but it’s only one piece of the puzzle. Scanning tools help you find known software flaws, missing patches, and misconfigurations across your network. Regular scans are essential for spotting and fixing technical weaknesses before they’re exploited.

But scanning alone won’t make you DORA-compliant. DORA’s goal is not just to eliminate known vulnerabilities, it’s to prove your organization can withstand actual ICT disruptions, whether caused by a known CVE, a zero-day exploit, or a process failure. Simply running scans and applying patches doesn’t demonstrate that your defenses or recovery processes work under pressure.

A scan might flag that a database server is missing a patch, but it won’t show whether your controls (IPS, EDR, firewall) would detect or stop an attack that exploits it. Nor will it test how your incident response team reacts in real time. That’s why DORA explicitly calls for advanced testing and simulation exercises beyond routine scanning.

Why is DORA testing required?

Financial institutions across the globe invest heavily in ICT systems and technologies to protect the mission-critical financial applications and services that the world revolves around. 

But how do you know that these security controls and technologies are operating as intended and can stop a cyber attack from disrupting financial operations? How do you know that the controls are threat resilient.

The answer is DORA testing. 

While the chapters of the DORA regulations cover a lot of ground in terms of governance structures, competent authorities, management processes, and risk frameworks, it is the actual act of testing and validating ICT systems and security controls where the rubber truly hits the road.

It is the act of DORA testing using a simulated attack scenario that determines exactly how resilient ICT systems and controls are to the latest cyber threats. 

Relying on trust alone goes against the spirit of DORA. Instead, DORA requires financial institutions to:

• Test and validate your security controls (frequently) 
• Extend third-party risk management validation
• Validate exposures to identify weaknesses, deficiencies, and gaps in cybersecurity that need to be prioritized and remediated

This is exactly what the DORA Act was designed to do and exactly what the Cymulate platform delivers. 

Get our DORA compliance checklist to see where your organization needs to improve.

Why isn’t deploying security controls enough for DORA readiness? 

Organizations invest in security controls to stop cyber attacks before they become a cyber breach. These controls include technologies such as email/web gateways, endpoint security validation, and identity management. Examples include:

• Secure Email Gateways (SEG) 
• Secure Web Gateways (SWG) 
• Endpoint Antivirus Solutions (AV) 
• Endpoint Detection & Response Solutions (EDR) 
• Endpoint Protection Platforms (EPP) 
• Cloud Security Solutions (CWPP, CNAPP, CSPM) 
• Data Loss Prevention (DLP) 
• Identity & Access Management (IAM) 
• Multi Factor Authentication (MFA) 
• Security Information & Event Management (SIEM) 

When these controls are optimized based on the cyber risks facing an organization, that organization is more resilient to cyber attacks. But the cyber threat landscape is constantly evolving, and therefore, the controls require continuous security validation and optimization to remain effective. 

Key DORA testing requirements

DORA is a sweeping regulation, but one of its core pillars is what it calls Digital Operational Resilience Testing. In practical terms, DORA sets out two levels of testing that financial entities must perform to validate their cyber resilience.

Each DORA test aims to validate that critical ICT systems can withstand disruptions and recover quickly, ensuring continuous operational resilience across the financial ecosystem:

1: Regular resilience testing (at least annually)

All in-scope financial institutions must conduct a range of security tests on their critical ICT systems no less than once per year. This includes routine vulnerability assessments and scans, penetration testing, software code reviews and other types of evaluation of security controls. 

The tests should cover any applications, systems, or infrastructure that support the organization’s critical or important functions (i.e., anything whose failure would significantly impact operations or services). Each DORA test must demonstrate that these systems can operate securely and recover swiftly under real-world stress scenarios.

Importantly, DORA specifies that testing isn’t a one-and-done annual drill, you should also test before launching any new critical system or major change and ideally run tests continuously or frequently as part of ongoing risk management. The goal is to ensure that as your environment and threats evolve, your defenses keep pace.

2: Advanced threat-led penetration testing (every 3 years)

In addition to annual regular testing, DORA mandates a more intensive TLPT (Threat-Led Penetration Test) at least once every three years for certain “significant” financial institutions. These are essentially red-team style exercises designed to simulate a full-scale attack by sophisticated threat actors. 

TLPTs are intelligence-led, meaning they are tailored to current threat scenarios and must encompass not just IT systems but also people and processes (for example, phishing employees, attempting physical breaches, etc.). 

Under DORA, regulators will identify which organizations are “significant” enough to require TLPT (likely large banks, critical market infrastructures, etc.), and such entities may need to have an external expert team conduct the TLPT and report the results to authorities. 

Notably, each member state will designate a TLPT supervising authority to oversee these exercises. The TLPT is meant to validate that your ongoing yearly testing is effective; it’s a “test of the tests,” in a way.

Beyond these two broad requirements, DORA’s testing mandates have additional key points worth highlighting:

• Broad Testing Scope: The regulation specifies that digital resilience testing must use “a range of assessments, methodologies, practices and tools.” In other words, you should mix it up: use automated scans, manual pen-tests, scenario-based drills, etc., to cover different angles. The scope should include all critical on-premise and cloud systems and even extends to critical third-party services. If you rely on a cloud provider for a critical function, you may need to ensure that provider participates in testing or provides evidence of testing.
• Remediation and Retesting: Finding vulnerabilities is not sufficient, DORA says organizations must “fully address” any vulnerabilities identified by their testing. Regulators expect to see a clear process where issues uncovered in tests are logged, prioritized and fixed as well as that fixes are verified. This ties into the broader vulnerability management process (next section) and the principle of continuous improvement.
• Documentation and Reporting: Firms need to document their testing programs and maintain reports of each test conducted. In the event of an audit or regulatory review, you should be able to provide evidence that, for example, you ran a penetration test on all critical applications in the past year and here were the results and actions taken. Significant vulnerabilities or incidents discovered may also trigger obligations to report to authorities (overlapping with incident reporting rules).
• Proportionality: DORA’s requirements follow a risk-based approach; smaller institutions have to test annually but the depth and complexity of tests can be proportional to their size and risk profile. The most demanding tests (like TLPT) apply mainly to the largest, most critical entities. Nonetheless, even smaller firms must not neglect regular testing, as no exemptions from the annual testing requirement are given, they might just scope it appropriately.

DORA embeds the concept of continuous security validation into law. Rather than assuming your controls are effective, you need to prove it on a regular basis. 

This is a cultural shift for many in the financial sector who traditionally may have treated pen-testing as an annual checkbox. Under DORA, testing is part of ongoing operational resilience management. 

How to implement a vulnerability management process for DORA compliance

Achieving DORA compliance requires more than ad-hoc testing, it calls for a structured vulnerability management process integrated into your organization’s risk management framework. Here is a high-level roadmap for building such a process, which not only meets DORA’s requirements but also genuinely improves your cyber resilience:

1: Asset & risk identification

Start by maintaining a clear inventory of your IT assets and understanding which systems are critical or important (in DORA terms) to your operations. You can’t protect or test what you don’t know you have. Conduct an initial risk assessment to identify potential threats and vulnerable points in those assets. 

This includes mapping dependencies on third-party providers and software. DORA expects organizations to perform risk assessments of their ICT at least annually, so make this a foundational step.

2: Regular vulnerability scanning & discovery

Implement continuous or periodic vulnerability scanning across your networks, applications and endpoints. Use reputable scanner tools to automatically detect known vulnerabilities (missing patches, misconfigurations, outdated software, etc.) on an ongoing basis. Many organizations conduct automated scans weekly or monthly on critical systems as a best practice. 

Complement scanning with other discovery methods like open-source component analysis (to find vulnerabilities in third-party libraries) and cloud configuration assessments. 

Under DORA, vulnerability assessments should be run regularly and also before major deployments, so integrate scanning into change management (e.g., scan new systems before they go live).

3: Prioritize identified issues

Scanning will likely yield a long list of findings. A DORA-compliant approach requires you to prioritize vulnerabilities based on risk, not simply severity scores, but considering the likelihood of exploitation and impact on your business. 

Adopt a risk-based vulnerability management strategy: focus first on high-risk vulnerabilities on critical assets (for example, an unpatched remote code execution flaw on an internet-facing trading system is a top priority). 

DORA doesn’t explicitly dictate a prioritization method, but regulators will expect you to address the most dangerous issues promptly (“fully address” vulnerabilities per testing results). Use threat intelligence to gauge if a vulnerability is being actively exploited in the wild, and factor that in. The goal is to remediate what could truly disrupt operations first.

4: Remediation and mitigation

For each high-priority vulnerability, execute a remediation plan. This could mean applying security patches or upgrades, changing configurations, updating access controls or implementing compensating controls if a patch isn’t available. 

DORA also cares about response and recovery plans ensure you have workarounds or incident response playbooks in case a vulnerability gets exploited before it’s fixed. Track these actions in a vulnerability management system or register, linking them to the original findings.

5: Validation (Re-test)

Once fixes are applied, verify the effectiveness of remediation. This might involve rescanning the system to ensure the vulnerability is closed and crucially testing the security control in question. 

If you patched a critical bug in your web server, also consider running a quick penetration test or simulated attack to confirm that the patch indeed blocks the exploit vector. DORA’s emphasis on testing means you should close the loop: don’t just trust that a patch works, test it.

6: Continuous monitoring and improvement

Vulnerability management under DORA is not a one-time project; it’s an ongoing cycle. Incorporate these activities into a continuous monitoring program. Keep metrics e.g., number of vulnerabilities discovered vs. remediated, average time to fix, residual risk levels. Regularly report on these to management and use them to refine your process. 

DORA also requires governance oversight of ICT risk, so senior leadership should be aware of the organization’s vulnerability status and support allocation of resources to fix issues promptly.

7: Integrate testing exercises

Beyond technical scanning, plan regular test exercises as part of the process. This includes conducting penetration tests on high-risk systems (either with internal teams or external consultants) and red team exercises for critical scenarios. 

Also run incident response drills (for example, simulate how you’d handle a ransomware outbreak) to test your procedures. These exercises will often reveal process vulnerabilities (like a missing step in communication, or a failed detection by a SIEM) that pure vulnerability scanning wouldn’t catch.

8: Documentation and audit trail

Keep comprehensive records of everything, asset lists, scan reports, vulnerabilities found, risk ratings, remediation actions, test results and so on. DORA compliance will likely be assessed via audits or regulatory inquiries, so having an organized documentation trail is critical. 

Consider maintaining a DORA testing log that maps each requirement to evidence (e.g., “Annual penetration test completed on date X; results see report; critical findings addressed by date Y”). This not only proves compliance but also helps internally to track progress.

By following these steps, you create a repeatable vulnerability management lifecycle: discover → prioritize → fix → validate → improve, looping continuously. 

This approach aligns with the DORA ethos of continuous risk management and improvement. It also instills confidence that you’re not just checking boxes for regulators, but truly reducing risk in your environment.

It’s worth noting that people and processes are part of vulnerability management too. Ensure your staff are trained on DORA requirements and security best practices (awareness can prevent a lot of vulnerabilities from creeping in to begin with). 

Also, engage with your third-party vendors: ask them about their vulnerability management. DORA expects you to manage ICT third-party risk as well, which may include reviewing your providers’ security reports or requiring them to adhere to certain standards.

This is where Cymulate complements scanning with continuous testing. Once you have the basic vulnerability management in place (e.g., regular scanning and patching), Cymulate can take you to the next level by enabling simulated attacks and control validation on demand. In the next section, we’ll see how Cymulate’s solution fits into the DORA puzzle.

Support digital operational resilience testing with Cymulate

Here at Cymulate, we are putting the “DORT” in DORA to help financial institutions (and the third-parties that service them) meet these new EU regulations. 

The Cymulate platform delivers Breach and Attack Simulation (BAS) capabilities that validate whether your ICT security controls can stop the latest threats. In essence, Cymulate enables automated, continuous Digital Operational Resilience Testing so you can ensure your organization is truly resilient against cyberattacks fulfilling the spirit and letter of DORA.

Continuous control validation

The Cymulate platform automates the execution of a broad range of attack simulations. This allows financial institutions to run assessments as frequently as needed, even weekly or daily if desired. (While DORA requires tests at least yearly, many organizations are choosing to go above and beyond.) 

Each assessment is threat-informed, using the latest immediate threats identified by Cymulate’s research team and the wider cybersecurity community. In fact, new threat templates (including exploits for recently disclosed CVEs) are added to the Cymulate within 24 hours of their discovery, ensuring your tests are always up-to-date.

Comprehensive testing of controls

Cymulate provides a library of thousands of attack scenarios and techniques across the MITRE ATT&CK® framework and NIST categories. You can simulate anything from a phishing email dropping malware, to lateral movement inside the network, to exfiltration of data, all in a safe, controlled manner. 

These simulations exercise your security controls end-to-end: email gateways, web filters, EDR, SIEM, DLP, cloud defenses, etc., to see if they detect or block the malicious activity. If any control fails to stop a step of the attack, Cymulate will flag that gap. 

This is exactly the kind of threat-led testing that DORA envisions, moving beyond vulnerability scanning to actually mimicking threat behavior and seeing how your environment holds up.

Actionable resilience insights

Every Cymulate assessment generates detailed findings and reports that provide deep insight into your security posture. You won’t just get a list of “vulnerabilities”; you’ll see metrics and analytics on how your controls performed under attack. The platform gives you:

• Risk scores for each assessment, which quantify the overall efficacy of your controls in preventing the simulated attack (useful for tracking improvement over time).
• Exposure levels that show how far an attacker could get, highlighting if critical assets were at risk.
• Penetration ratios, indicating what percentage of the attack techniques were not stopped by your defenses (essentially, how “penetrated” your systems were).
• Breakdowns by attack type or kill-chain phase, to pinpoint which stages (e.g., initial access, privilege escalation, data exfiltration) are your weakest links.
• Mitigation guidance for each identified gap. Cymulate doesn’t just say “your web gateway missed malware X”, it will provide recommendations to optimize configurations or policies, helping your team quickly close those gaps.
• Detection & prevention rules suggestions, for example, if a certain behavior wasn’t caught by your SIEM, Cymulate might suggest a log rule or correlation to implement.

All of this output maps back to DORA compliance evidence. The reports from Cymulate effectively serve as proof and attestation that you conducted resilience tests in accordance with DORA’s requirements. They demonstrate to auditors or regulators that not only did you perform the tests, but you have quantified the results and are using them to drive continuous improvements.

Threat-ready, always:

One of the big advantages of Cymulate is how it keeps you ahead of emerging threats.

With Cymulate’s continuous updates (e.g., integrating the latest ransomware TTPs or vulnerability exploits as they arise), your testing program remains aligned with the current threat landscape without you having to constantly design new test cases. DORA’s guidance encourages leveraging threat intelligence in testing, Cymulate bakes that in by default.

In doing so, Cymulate puts you well ahead of the game for the January 17, 2025 compliance deadline. It enables you to:

• Assess your preparedness for handling ICT-related incidents stemming from cyber attacks, using real-world threat simulations.
• Identify weaknesses and gaps in your security controls that traditional assessments might miss, thereby improving your overall digital operational resilience.
• Implement corrective measures faster, guided by actionable recommendations to optimize controls and policies.
• Maintain a sound testing program for both your organization and any critical third parties, as required by DORA’s guidelines for a comprehensive resilience testing program.
• Use a wide range of attack techniques in a safe environment, fulfilling DORA’s expectation of diverse testing methods while ensuring production systems are not disrupted during tests.
• Leverage a risk-based approach to vulnerability management, focusing on the most relevant threats and exposures as highlighted by Cymulate’s assessments.

Cymulate Exposure & Security Validation platform operationalizes DORA’s testing requirements in a convenient, automated way. It delivers the continuous validation and evidence-based assurance that regulators will look for, and more importantly, it measurably strengthens your security posture against the #1 risk to financial institutions cyber attacks.

For more information on how Cymulate can help you meet DORA compliance, you can refer to our detailed solution brief or schedule a demo of the platform.