From Periodic Scans to Continuous Resilience
How financial entities can build a DORA-compliant vulnerability management program, moving from periodic point-in-time scans to continuous resilience across their ICT estate.
Introduction
Since it began applying in January 2025, the Digital Operational Resilience Act (DORA) has provided a framework for financial institutions to strengthen their cybersecurity and operational resilience. Rather than relying on annual audits or periodic compliance exercises, DORA requires organizations to maintain continuous evidence of resilience. Security teams must be able to demonstrate the effectiveness of their controls at any point in time, providing auditors with accurate, up-to-date evidence on demand rather than scrambling to assemble documentation ahead of an assessment.
Fundamentally, DORA did not create a new compliance problem; it created an exposure management challenge that organizations must address. The emphasis has shifted from proving that controls exist to proving that they are continuously operating and effectively reducing risk across increasingly complex environments.
One of the biggest changes is the move from periodic vulnerability scanning to continuous vulnerability management. Data from Mondoo shows that organizations adopting continuous approaches can reduce mean time to remediate (MTTR) to under 16 days. By comparison, traditional periodic scanning often results in much longer remediation cycles due to manual ticketing, context switching, and reporting delays.
Most security programs were never designed to produce continuous evidence. The purpose of this guide is to demonstrate, step by step, how to build a program that meets DORA’s expectations while improving overall cyber resilience.
What DORA Actually Requires
Described as a regulation introduced by the European Union to strengthen the digital resilience of financial entities, DORA is intended to safeguard financial services organizations against ICT-related incidents, including taking steps on protection, detection, containment, recovery, and repair. It explicitly details ICT risk management, incident reporting, and resilience testing amongst its guidance, and its five pillars are:
Among DORA’s 64 articles are two with key guidance on detection, and on protection and prevention. Article 9 requires financial entities to move beyond periodic security assessments and instead continuously monitor, manage, and protect their ICT systems. It shifts ICT security from a reactive, point-in-time activity to an ongoing operational discipline designed to reduce cyber risk and maintain operational resilience at all times. The article mandates implementing security policies, procedures, tools, and controls to ensure the resilience, availability, integrity, authenticity, and confidentiality of systems and data, especially those supporting critical business functions. Robust access controls, strong authentication, network security measures, encryption, patch and vulnerability management processes, and formal change management procedures are also required.
Article 10 states that financial entities shall have mechanisms in place to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents, and must devote sufficient resources and capabilities to monitor user activity, ICT anomalies, and ICT-related incidents. It also mandates developing and documenting formal procedures covering vulnerability and patch management: identifying, testing, and deploying software and hardware fixes, and dictating how patches and other risk-mitigation measures are prioritized against identified vulnerabilities. Organizations must formally record detected vulnerabilities affecting their ICT systems and monitor and verify their remediation.
Where Most Programs Fall Short
Too many periodic scans are built for when the auditor comes, not to fit within the DORA framework. In the recent case of a European bank, before it used Mondoo as part of becoming DORA compliant, it had a risk-oriented vulnerability management process in place, alongside manual key risk indicator collection and Excel spreadsheets to keep track of what was happening. There were too many media breaks between systems, manual Excel-based workflows where automation should have been in place, and a methodology a regulator could not trace from one step to the next. The bank also had no hardening baselines at all, and the metrics in its information security management system were weak and assembled by hand. None of that would withstand DORA scrutiny.
With the methodology correct, firms can show what they found to a DORA auditor. However, only a few can actually show what action they have taken, and the finding-to-fixing gap becomes wider the less action you take.
There are also blind spots where programs rely on open source and SaaS tools, both of which come with their own issues. Open source tools require patching and management that often depends on volunteers and not-for-profit organizations without permanent resources. For SaaS tools and any form of shared infrastructure, consider how an outage or lack of availability could affect the way you operate.
Finally, BaFin issued guidance at the start of this year on the use of AI within financial entities, to help organizations manage ICT risks in accordance with DORA. It recognized that implementing and operating AI systems can entail significant regulatory risks. Beyond specific safeguards for ICT assets, AI systems must be included within the existing ICT risk management framework: given the complexity of the models, the amount of data processed, and the integration of software from ICT third-party providers, internally and externally developed AI systems must be analysed and tested to the same standards.
Five Things A DORA-Compliant VM Program Must Have
Knowing how vital a DORA-compliant vulnerability management program is, the next step is to make sure it has the correct content and coverage. These are the five elements it must include.
First Factor: Full Environment Coverage
The program must span the entire ICT estate, including cloud, on-premise, endpoints, SaaS, network devices, and CI/CD pipelines, because DORA applies to all of it. This requires asset discovery and documentation, the ability to map all internet-facing infrastructure so exposure points are found before an attacker does, and a shift away from point-in-time periodic scans toward real-time continuous assessment and agentless workload scanning. The goal is continuous monitoring of all assets, with nothing left uncovered.
Second Factor: Risk-Based Prioritization
This needs to go beyond CVSS scores to consider real-world exploitability and internet exposure. Consider asset criticality: which of your assets are most critical to your environment, and what would cause the most issues if exploited. Also consider which vulnerabilities pose the most risk. If a vulnerability requires physical access to an endpoint or server, ask yourself how likely that is to happen. If an exploit affects a component you barely use or sits on an unexposed server, how critical is that patch, and would applying it disrupt operations at all?
Third Factor: Remediation Tracked To Closure
This is the lifecycle of identifying, prioritizing, assigning, and verifying the fix for security vulnerabilities. Remediation tracking ensures gaps don’t remain open or abandoned without independent validation, and can be justified for an auditor’s visit to demonstrate what has been found and resolved.
Every vulnerability needs an owner accountable for how it was found and dealt with, a remediation action recording what was done, and a tracked closure date demonstrating how the flaw was ultimately resolved. The engineering handoff is where most programs stall; actionable remediation guidance alongside every finding removes that friction.
Fourth Factor: Continuous Compliance Evidence
The audit trail must exist passively, with continuous and current data and findings ready to be presented upon request, not just collated in response to a review.
Fifth Factor: Board-Level Reporting
The program needs board-level recognition to be taken seriously, and technical exposure has to translate into business risk, in language a board member can engage with. A raw CVE count cannot be used here: reporting must be plain-language, understandable, and jargon-free.
Four-Stage Implementation Roadmap
With the content of the program defined, the next question is how it gets implemented and operated. The rollout follows four stages that deserve the time to be implemented properly.
Map the current program against the five requirements above. Does what you do translate into board-level language, does it have full environment coverage, and can it produce evidence of continuous compliance? Use the initial scan output as the baseline and document the gaps for evidence. Do not build a complex mapping exercise at this stage.
Identify and close any coverage gaps discovered in the first stage. Focus on internet-facing systems first, then move to cloud workloads, on-premise, SaaS and AI assets, as well as any legacy servers or networks.
Fix the engineering handoff: get findings into developer workflows with risk context and ownership attached, to reduce time to remediate. Define SLAs by asset criticality, know which assets demand the most attention, and track findings to closure so nothing gets lost in the pipeline.
Arguably the most critical part: prepare evidence for the auditor with a continuously compliant infrastructure. At this stage evidence generation is automated and board-ready reporting is in place, so a sudden audit request finds you in the best position to respond.
What It Looks Like In Practice
In the case of the European bank from our example, its pursuit of DORA compliance led it to use Mondoo for its vulnerability management. Previously the company relied on manual key risk indicator collection, Excel-based workflows, and internal audit findings. An audit of the ICT risk management process found too many media breaks between systems, manual workflows where automation should have been in place, and a methodology a regulator could not trace from one step to the next.
Using Mondoo, the bank was able to continuously collect evidence, meet its exposure management requirements, and contribute evidence to the requirements adjacent to them. Mondoo provides the ICT governance framework with up-to-date information from the infrastructure and gives the operational team a risk-weighted way to prioritize patch and vulnerability management. KRIs and KPIs now flow automatically from Mondoo into the ICT risk management process and the ICT risk register; each metric has a defined profile covering how it is composed, what the target value is, and how it is collected.
The bank had no hardening baselines, so it took the Mondoo scan results and declared them its requirement. From that basis it has a traceable orientation for where it stands across the entire landscape with its different systems. The situation now is a continuous, always-auditable evidence trail, where compliance evidence is a by-product of daily operations.
Closing
DORA has not changed what financial institutions need to do about vulnerabilities. It has changed how consistently they must manage them, how broadly they must apply exposure management principles, and how clearly they must prove their capabilities.
The steps in this white paper enable you to implement compliant vulnerability management with continuous recording for an auditor’s approval. Using Mondoo, the European bank ran continuous scanning across cloud, on-premise, endpoints, SaaS, and network devices, moved away from manual processes, and gained a continuous, always-auditable evidence trail: with an automated audit trail, it was always ready to present evidence. With risk-based prioritization and remediation tracked to closure, you are well on the way to fitting within DORA’s guidelines and meeting an auditor’s demands without a major upheaval of the way you work.
Resilience you can prove, every day of the year.
Audit-ready every day, not once a year.
See how Mondoo maps DORA requirements to continuous, evidence-backed monitoring.
