Since vulnerability management became part of the cybersecurity protection process, it has typically been measured by annual penetration tests, quarterly scans, and periodic remediation programs.
In short, DORA has not changed what financial institutions need to do about vulnerabilities; it has changed how consistently they must do it, how broadly they must apply it, and how clearly they must prove it.
For most security teams, that is a fundamentally different operating model, not an upgrade to the one they already have.
Therefore, there is a greater requirement for a combination of continuous monitoring and risk-based prioritisation. It is also time to consider shift-left testing, where testing activities are performed earlier in the development lifecycle, providing a better opportunity to find vulnerabilities and reduce their impact and remediation costs later in the process.
Continuous Monitoring Replaces Point-in-Time Security
If you are able to continuously monitor for issues and see changes in real time, you are in a more secure position and better prepared for when an auditor calls.
Consider Article 9 of DORA. It requires financial services entities to move beyond periodic security assessments and instead continuously monitor, manage, and protect their ICT systems. This includes implementing security policies, procedures, tools, and controls that ensure the resilience, availability, integrity, authenticity, and confidentiality of systems and data, particularly those supporting critical business functions.
In essence, Article 9 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.
DORA's requirement for continuous monitoring and control means organizations must maintain ongoing visibility across their ICT environment, enabling them to identify, assess, and respond to vulnerabilities, threats, and operational risks in real time rather than relying on periodic assessments or point-in-time reviews.
Frankly, annual scans and quarterly reviews are no longer enough; DORA compliance requires an operating model change.
For example, one user was able to use Mondoo scan outputs to provide continuous evidence, replace static benchmarking, and establish baseline security requirements.
Shift-Left Security Is Now a Regulatory Requirement
This movement toward a more efficient approach to testing and project management, whereby code and applications are checked earlier and potential flaws identified sooner, is not new, but it has not always been widely adopted.
The concept of "test early and often" has been present since the start of the century. The 2016 State of DevOps Report showed that high-performing teams spend around 50 percent less time remediating security issues than those that do not. However, pressure to release projects rapidly and generally work faster has increased the likelihood of vulnerabilities entering production environments.
So why is this relevant to compliance with DORA? According to PwC UK, DORA builds on previous industry-specific guidelines to define requirements around ICT risk management, resilience testing capabilities (including threat-led penetration testing), and third-party risk management, ensuring the consistent provision of services across the entire value chain.
Therefore, even though it is not explicitly stated in the regulation, shift-left testing is encouraged because prevention is favored over detection. It allows development teams to become part of the compliance process, as finding vulnerabilities after release could create regulatory risk for a business that does not follow appropriate testing practices.
The Backlog Problem: Why More Findings Create More Risk
The reasons shift-left testing has not been more widely adopted are likely to include:
- Slowing down the development process
- Creating a backlog of vulnerabilities that need to be addressed
- The need for exploitability and asset-context analysis
The flaws that are found have to be fixed. Consider the regulator's viewpoint: "How many vulnerabilities did you identify?" and "How did you prioritize and remediate them?" An unmanaged backlog can become a compliance issue, as someone must take responsibility for fixing what is found.
Consider Article 10 of DORA on vulnerability and patch management, which encourages organizations seeking compliance to:
- Establish procedures for the responsible disclosure of vulnerabilities to clients, counterparties, and the public
- Prioritise the deployment of patches and other mitigation measures to address identified vulnerabilities
- Monitor and verify the remediation of vulnerabilities
- Record any detected vulnerabilities affecting ICT systems and monitor their resolution
The process of scanning code, software, and applications can generate additional findings, which also creates demands around patching and responsible disclosure. Therefore, while addressing issues earlier can save time and result in more secure outcomes, organizations should carefully consider how much additional risk and workload may be created as a consequence.
Factor this into your vulnerability management program and processes, and assess whether you have the capacity to deal with what you find, particularly if speed is critical within your development lifecycle. It may be worth assigning an additional person or team to manage vulnerabilities as they are identified in order to minimize remediation and reporting times.
Supply Chain Risk Has Entered the Compliance Perimeter
As well as considering your vulnerability discovery processes, your supply chain remains a key part of DORA compliance.
One of DORA's objectives is to strengthen digital operational resilience in financial services by addressing risks within the ICT supply chain. In particular, Article 29 stresses the need to maintain comprehensive supply chain visibility by identifying, classifying, and continuously monitoring all ICT service providers that support critical or important functions.
This includes vulnerabilities introduced through the supply chain and the extent to which your organization depends on open-source software, as well as providers that are themselves reliant on third-party services. If a critical service suddenly becomes unavailable, how will you continue serving clients and customers? You remain accountable regardless of which services you use, so this should be reflected in your risk profile when selecting suppliers.
Even when you do not directly control a vulnerable component, you remain responsible for reporting and remediating any vulnerabilities associated with it. This is how DORA extends vulnerability management far beyond internally developed systems, as many firms have traditionally not expanded their vulnerability management programs to encompass third-party dependencies.
An example lies with the compromise of Trivy back in March 2026. In that case, TeamPCP targeted Aqua Security's Trivy vulnerability scanner, its GitHub Actions and Docker images. Using stolen credentials - captured from a prior incident - allowed the attacker to exploit a misconfiguration in Trivy's GitHub Actions environment, extracting a privileged access token and establishing a foothold in repository automation and release processes.
Trivy is embedded in thousands of CI/CD pipelines, and as the incident affected millions of developers and hundreds of thousands of CI/CD pipelines, with potential long-term exposure due to credential theft and persistent malware. This forced Aqua Security to do a full investigation, where it admitted to failing to adequately protect its supply chain. The attack went on for several hours before it was detected and halted.
A subsequent investigation revealed the rotation was not fully comprehensive, allowing the threat actor to retain residual access via still-valid credentials. As the attackers modified existing version tags associated with trivy-action, they injected malicious code into workflows that organizations were already running.
As many CI/CD pipelines rely on version tags, these pipelines continued to execute without any indication that the underlying code had changed regardless of the change.
This incident is a timely reminder that supply chain risk does not stop at your software dependencies, and it extends to the security tooling itself.
As a result, regulators have taken note, and in January 2026, BaFin went further still by placing AI systems within DORA's ICT framework, stating that "the use of AI also entails greater risks" and that financial entities should define appropriate governance and organizational structures to mitigate ICT risks arising from AI systems.
This includes LLMs, copilots, and agentic systems, all of which increasingly require regular assessment and consideration of the impact their unavailability could have on business operations.
Audit Trails: The Difference Between Compliance and Proof
In order to achieve and maintain compliance with DORA, organizations need to maintain a continuous, machine-readable record of their activities. This enables them to demonstrate to regulators what was found, when it was found, and what actions were taken. Create a culture of proactively assembling an audit trail, as DORA requires this and doing so will save considerable time when an auditor calls.
Evidence of compliance should also be generated continuously rather than assembled hastily in the days leading up to an audit. DORA requires organizations to prove what happened, not simply state that it happened.
Conclusion: Vulnerability Management Has Become a Resilience Function
Ultimately, DORA has not changed what organizations need to do about vulnerabilities; it has changed how consistently they must do it, how broadly they must apply it, and how clearly they must prove it.
Those organizations succeeding under DORA are not necessarily finding fewer vulnerabilities; they are building processes that continuously demonstrate control, resilience, and accountability. Vulnerability management is no longer just about finding and fixing issues. It is about maintaining an audit trail, managing a supply chain, and understanding what is happening within your organization and how it affects operational resilience.
