DORA Vulnerability Management for Financial Services: A Practical Guide

The Digital Operational Resilience Act (DORA) has applied since January 17, 2025, establishing a comprehensive ICT risk management framework for the EU financial sector. If your organization is a bank, insurance company, investment firm, payment institution, or crypto-asset service provider operating in the EU, DORA’s vulnerability management requirements apply to you.

What DORA requires for vulnerability management

DORA’s Chapter II (Articles 5 to 16) requires financial entities to implement an ICT risk management framework that includes the identification, classification, and mitigation of ICT-related vulnerabilities. Specifically, DORA requires:

• Continuous identification of ICT vulnerabilities that could affect business-critical systems
• Risk-based prioritization, not all vulnerabilities require the same urgency
• Timely remediation with documented evidence of actions taken
• Regular testing including vulnerability assessments and penetration testing (Articles 24-27)
• Third-party ICT risk management, your vendors’ vulnerabilities are your risk too (Articles 28-30)

Unlike NIS2, which is broad and principles-based, DORA is prescriptive. The technical standard on the ICT risk management framework, Commission Delegated Regulation (EU) 2024/1774, spells it out. Its Article 10 asks for automated vulnerability scanning and assessment of ICT assets, at least weekly for the assets that support critical or important functions, with the results tracked through to remediation. If you can only answer one question for your supervisor, make it this one: which assets support critical functions, and where is the evidence that they were scanned every week? (official text)

DORA vs NIS2: what’s the difference?

Financial entities in the EU are subject to both DORA and NIS2. However, DORA takes precedence as the sector-specific regulation (lex specialis). In practice:

• DORA governs your ICT risk management, including vulnerability handling
• Incident reporting also runs under DORA: major ICT-related incidents go to your financial supervisor, not through NIS2
• Your national financial supervisor (BaFin in Germany, Banca d’Italia and CONSOB in Italy, depending on the type of entity) enforces DORA compliance

What financial regulators will examine

During a DORA audit, expect regulators to review:

1. ICT asset inventory: Complete catalog of hardware, software, and network components supporting critical business functions
2. Vulnerability identification process: How you discover vulnerabilities, how frequently, and which sources you use
3. Prioritization methodology: Your criteria for determining which vulnerabilities to remediate first
4. Remediation SLAs: Defined timeframes for addressing vulnerabilities based on severity
5. Evidence of execution: Timestamped records proving vulnerabilities were identified, assessed, and resolved
6. Third-party risk: How you monitor vulnerabilities in ICT services provided by third parties

A practical approach for smaller financial entities

Tier 1 banks have dedicated security operations centers with seven-figure budgets. But DORA applies equally to smaller entities, payment processors, fintech startups, insurance intermediaries, and crypto service providers. These organizations need a proportionate approach.

Focus on what matters: KEV + CVSS + EPSS

The most efficient vulnerability prioritization combines three data sources:

• CISA KEV: Confirms active exploitation (the highest urgency signal)
• CVSS: Technical severity scoring (how bad the vulnerability is)
• EPSS: Exploitation probability (likelihood of future exploitation)

A vulnerability in the KEV catalog with a CVSS of 9.0 and an EPSS of 95% should be remediated within days. A CVSS 7.0 vulnerability not in KEV with an EPSS of 2% can wait for the next maintenance window.

On-premises: a requirement, not a preference

Many financial entities, particularly those regulated by FINMA (Switzerland) or operating under strict data residency requirements, cannot send their ICT asset inventory to cloud-hosted vulnerability scanners. The inventory itself, which software runs where, is sensitive operational data.

On-premises deployment ensures your vulnerability management data stays within your controlled infrastructure. This is not just a privacy preference; for many regulated entities, it’s a compliance requirement.

How SentriKat supports DORA compliance

SentriKat provides financial entities with a focused, on-premises vulnerability management platform:

• Daily CISA KEV sync with CVSS and EPSS scoring for risk-based prioritization
• Vendor advisory integration (OSV.dev, Red Hat, Microsoft MSRC, Debian) for accurate patch detection
• Executive summary PDFs with risk scores and KPIs suitable for board-level reporting
• Audit trail documenting every vulnerability lifecycle event with timestamps
• SIEM integration via syslog (CEF, JSON, RFC 5424) for correlation with your existing security monitoring
• On your own servers if you choose, so your data never leaves your infrastructure; or in our cloud, hosted in the EU
• Air-gapped deployment support for the most restricted environments

Getting started

DORA compliance is not optional, and enforcement is underway. If your organization hasn’t yet implemented structured vulnerability management, the gap is widening with every month.

Request a demo of SentriKat to see how KEV-focused vulnerability management works for financial services. We’ll walk through DORA-specific reporting and integration with your existing security stack.

SentriKat is a Swiss on-premises vulnerability management platform built for organizations that require data sovereignty and regulatory compliance.