Contain, recover and report within DORA's deadlines.
DORA requirements make ransomware a test of operational resilience. Since 17 January 2025, banks, insurers, investment firms and other EU financial entities must contain ICT incidents, restore safely, report major incidents against fixed deadlines and test that it all works. Helm contains ransomware at the data layer, verifies recovery and records every step, so you have the proof each report needs.
For banks, insurers and payment firms, ransomware is more than an IT incident. Under DORA it is a test of operational resilience, with a reporting clock running, a supervisor expecting answers and the management body accountable for the outcome.
The pressure is real. In Sophos’ 2025 survey of 369 financial services organisations hit by ransomware, 59% of attacks ended in data encryption. Only 44% of victims could restore from backups, down from 62% a year earlier.
Containing an incident, restoring safely and reporting what happened are exactly what DORA asks financial entities to show. Since January 2025, the question is no longer whether you have a plan. It is whether you can prove it worked.
The Digital Operational Resilience Act (DORA) is an EU regulation, Regulation (EU) 2022/2554, that has applied since 17 January 2025. It covers credit institutions, payment and e-money institutions, investment firms, insurers and reinsurers, crypto-asset service providers and other financial entities, and brings critical ICT third-party providers under EU oversight.
DORA covers five areas, ICT risk management (Articles 5–16), incident management, classification and reporting (Articles 17–23), digital operational resilience testing (Articles 24–27), ICT third-party risk (Articles 28–44) and information sharing (Article 45). The management body defines, approves and is accountable for the ICT risk framework.
DORA or NIS2? For financial entities in scope, DORA is the sector-specific law and takes precedence over NIS2 for cybersecurity risk management and incident reporting. Many other organisations fall under NIS2.
DORA does not name ransomware. It sets technology-neutral rules for ICT incidents, and a ransomware attack is the incident most likely to test all of them at once.
Article 11 asks for response and recovery plans that contain an incident, limit the damage and resume critical functions quickly. Article 12 asks for backups you can restore, with restoration onto systems kept separate from the affected source. Article 13 asks you to review each incident and improve.
Articles 17 to 19 cover reporting. Every ICT incident is recorded and classified, and major ones are reported to your competent authority. The initial notification is due within four hours of classifying an incident as major, and no later than 24 hours after you become aware of it. An intermediate report follows within 72 hours, and a final report within one month.
Helm is not a full DORA compliance programme. It covers the moments DORA tests hardest, and gives you proof for each of them.
Containment (Article 11). Helm detects active encryption in under a second and isolates the compromised accounts and devices on fixed, readable rules your team sets, with no AI in containment. Critical services keep running.
Recovery (Articles 11 and 12). Helm verifies that systems are clean before they come back, so restoration starts from a safe point rather than a guess.
Testing (Articles 24–26). Helm can be part of your resilience testing, from scenario-based tests to threat-led penetration testing (TLPT), so you can show that detection and containment work under realistic attack conditions, with timestamped results for your test reports. [TBC]
Reporting and learning (Articles 13 and 17–19). Every detection, containment and recovery step is timestamped, showing which accounts, devices and files were involved. That gives you the facts for classification, the initial notification, and the intermediate and final reports, with your team in control of what is submitted. The same record feeds your post-incident review.
DORA asks financial entities to keep critical services running through an ICT incident and to show how they did it. With Helm, ransomware is contained in seconds, recovery is verified before systems return, and the record is ready the minute your board or regulator asks.
For how Helm fits banks, insurers and payment firms more broadly, see ransomware protection for financial services. To see the evidence for your own environment, talk to us.
