Vulnerability Scanning & DORA Compliance: What You Need to Know

DORA now covers more than 22,000 financial entities and an estimated 15,000 ICT third-party providers across the EU, according to the European Banking Authority, and vulnerability scanning sits right at the foundation of how most of them prove they’re managing ICT risk properly. It’s the recurring, lower-cost testing layer that DORA’s Pillar 1 and Pillar 3 both lean on, distinct from the far more intensive Threat-Led Penetration Testing that significant entities have to run periodically.

The oversight side of DORA has moved from paper to practice, too. The European Supervisory Authorities made their first Critical ICT Third-Party Provider designations on November 18, 2025, marking the point where direct EU-level scrutiny of major cloud and tech vendors started operating for real. This guide covers what DORA-aligned vulnerability scanning needs to cover, how it differs from TLPT, which tools do the job well, and how often scanning genuinely needs to happen.

What is vulnerability scanning under DORA? It’s the recurring, automated process of identifying unpatched software, misconfigurations, and known vulnerabilities across an entity’s ICT estate. Under DORA, it forms the baseline testing layer within Pillar 3, required at least annually, sitting alongside the far more advanced Threat-Led Penetration Testing that significant entities must run at least once every three years.

Scanning vs. TLPT: The Two Testing Tiers Under DORA

DORA’s resilience testing pillar isn’t a single requirement for DORA compliance. It splits into two tiers with very different depth, frequency, and purpose.

Treating these as interchangeable is a common mistake. A clean vulnerability scan doesn’t mean an entity would survive a real, targeted attack, and that gap is exactly what Threat-Led Penetration Testing (TLPT) is designed to expose.

What DORA-Aligned Scanning Needs to Cover

Blind spots are where attackers get in, so scanning scope has to span the full ICT estate rather than whatever’s easiest to reach.

Scanning any one of these in isolation leaves gaps. A fully patched application behind a misconfigured cloud storage bucket is still exposed, which is why DORA’s framing treats the ICT estate as one connected system rather than five separate DORA checklists.

Choosing the Right Scanning Approach

Not every scanning method fits every environment, and picking the wrong one creates either blind spots or unmanageable noise.

• Authenticated vs. unauthenticated scanning – Authenticated scans log in as a real user to find internal weaknesses; unauthenticated scans simulate an outside attacker probing the perimeter. A mature programme runs both, since they surface different classes of issues.
• Agent-based vs. agentless – Agent-based tools install lightweight software for continuous, real-time visibility, useful for servers and endpoints that don’t change often. Agentless scanning works over protocols like WMI or SSH, better suited to short-lived cloud instances that come and go.
• Risk-based prioritization – The best tools score findings by actual business impact and exploitability, not just CVSS severity in isolation, tying results to live threat intelligence so teams fix what’s genuinely dangerous first instead of chasing volume.
• Compliance-ready reporting – DORA-aligned tools should produce timestamped, audit-ready reports mapped to specific pillars, since that’s what examiners and internal risk committees both need to see without extra translation work.
• Low false-positive rates – Machine-learning-assisted tools that get tuned against your specific environment build trust in results over time. A scanner that cries wolf constantly gets ignored, which defeats the purpose.

How Often Should Scanning Happen

DORA sets annual scanning as the regulatory floor, not a target to aim for. In practice, most mature programmes scan far more frequently than that baseline, especially for internet-facing systems and anything handling customer data, where the cost of missing a new vulnerability for months is simply too high. The right cadence depends on asset criticality and how fast an entity’s environment changes; a system that gets updated weekly needs scanning closer to that same rhythm, while a stable, low-risk internal tool can reasonably sit on a longer cycle. What matters to examiners isn’t hitting a specific number. It’s showing the scanning frequency was a deliberate, risk-based decision, not an afterthought.

How Qualysec Helps With Vulnerability Scanning and DORA Compliance

Vulnerability scanning plays a very important role in DORA compliance as it enables financial entities to detect and mitigate ICT vulnerabilities before they impact their operational resilience. Qualysec integrates automated vulnerability detection with manual validation to validate vulnerability detections, minimize false alarms, and deliver actionable remediation advice to meet DORA’s security and resilience objectives.

DORA-Aligned Vulnerability Assessments

Qualysec runs vulnerability assessments across networks, cloud environments, and third-party connections, using automated scanning layered with manual verification to confirm findings are real and exploitable, not just theoretical. Results come with risk-scored prioritization and timestamped reporting mapped directly to DORA’s Pillar 1 requirements.

CREST-Accredited TLPT, When Scanning Isn’t Enough

For entities designated as significant, Qualysec delivers full Threat-Led Penetration Testing through CREST-accredited red team testers, simulating ransomware, supply-chain, and targeted attack scenarios against live systems. The CREST credential gives boards and regulators the independent assurance DORA’s advanced testing tier is built around.

Continuous Monitoring and DORA Roadmaps

Beyond point-in-time assessments, Qualysec builds ongoing scanning programmes mapped across all five DORA pillars, with dashboards tracking metrics like mean time to remediate, plus managed monitoring that flags new exposures as they emerge rather than waiting for the next scheduled scan.

Schedule a vulnerability scanning and DORA compliance consultation with Qualysec!

Key Takeaways

• Vulnerability scanning is the baseline testing layer under DORA’s Pillar 3, required at least annually for relevant ICT systems.
• It’s distinct from Threat-Led Penetration Testing (TLPT), the advanced, three-year testing cycle required of significant entities.
• Scanning needs to cover five asset categories: network infrastructure, endpoints, applications, cloud environments, and third-party or supply-chain systems.
• Risk-based prioritization matters more than raw scan volume. A long list of low-severity findings isn’t useful without context on what’s actually exploitable.
• CREST-accredited testing gives both scanning and TLPT results credibility that regulators and boards recognize without extra verification.

Conclusion

Vulnerability scanning is the part of DORA compliance that’s easy to underestimate precisely because it’s the less dramatic testing tier. It doesn’t get the same attention as a full TLPT engagement, but it’s the control that catches the everyday issues- an unpatched server, a misconfigured cloud bucket before they become the entry point for something much worse. Getting scanning scope and cadence right, and knowing exactly where it hands off to TLPT for significant entities, is what turns DORA’s testing requirements from a compliance obligation into a genuine reduction in attack surface.

Contact us at Qualysec if you want to develop a programme for vulnerability scanning aligned with DORA’s requirements.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Frequently Asked Questions

1. What is DORA compliance?

At its simplest level, it means having established and implemented the operational resilience outlined within DORA’s 5 pillars (ICT Risk Management, Incident Reporting, Resilience Testing, Third-Party Oversight and Information Sharing) throughout your organisation.

This can include everything from documentation of policies around these areas, regular testing activities such as Vulnerability Scanning and (for significant entities), TLPT, through to the capability to provide regulators with evidence that you are taking action on maintaining the resilience required by the directive.

2. What is vulnerability scanning?

Vulnerability scans automatically scan IT systems (networks, apps, cloud) for unpatched software, misconfigurations, and other known security problems. Scan results help identify critical issues needing urgent fixes. Tools rank findings based on severity and potential business impact. Teams then work through items to remediate them before being exploited by bad actors. This activity needs to happen frequently.

3. Is vulnerability scanning required for DORA compliance?

Yes! Vulnerability scanning falls squarely within two key pillars of DORA: the ICT Risk Management pillar and the Resilience Testing pillar. Entities will need regular tests documenting results as part of their audit trail, showing how these kinds of tests aren’t just an annual exercise, but deeply baked into existing processes.

4. How often should vulnerability scanning be performed under DORA?

Annual scanning satisfies regulatory requirements, but the appropriate cadence will depend on factors like your assets’ criticality and their associated risks. You can expect internet-facing systems and anything processing sensitive customer data to require more frequent scanning. In particular, don’t assume examiners care about how many times you run a scan. They’ll be more concerned with whether you’ve made a thoughtful, risk-based decision when determining how often to scan instead of using the absolute regulatory minimum for everything you touch.