The Digital Operational Resilience Act (DORA) became directly applicable across the EU on 17 January 2025. Unlike NIS2, which covers critical infrastructure broadly, DORA targets financial entities specifically — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and the ICT third parties that serve them.
DORA's ICT risk management framework (Chapter II) imposes specific obligations on vulnerability scanning, patch management, and risk assessment that go significantly further than most financial firms' existing practices. This guide breaks down what you need to have in place.
Who is in scope under DORA?
The DORA articles that govern vulnerability management
Identification of ICT risks
Financial entities must maintain an up-to-date inventory of all ICT assets and map the dependencies between them. This forms the foundation for any vulnerability scanning programme — you cannot assess risk for assets you do not know exist.
Protection and prevention
Article 9(4)(b) explicitly requires "policies and procedures for ICT vulnerability and patch management." This must include: defined scanning frequency, risk-based prioritisation of findings, remediation timelines with SLAs, and documented exceptions when immediate patching is not possible.
Detection of anomalous activities
Vulnerability management and threat detection must work in concert. DORA requires that firms monitor their ICT systems for anomalous activity — newly published CVEs exploited in the wild should trigger immediate re-assessment of affected assets.
Advanced testing — TLPT
Significant financial entities must conduct Threat-Led Penetration Testing (TLPT) at least every three years. Vulnerability scanning data is essential input for scoping and prioritising TLPT exercises.
Patch management SLAs under DORA
The DORA Regulatory Technical Standards (RTS) published by the European Supervisory Authorities (ESAs) provide guidance on expected SLA timeframes. While exact numbers remain risk-context-dependent, the consensus expectation across the three ESAs is:
Third-party ICT risk and vulnerability management
DORA imposes an obligation that most firms have not yet operationalised: you must assess the vulnerability posture of your critical ICT third-party providers (CTPPs). DORA Chapter V gives the ESAs direct oversight powers over designated CTPPs, but the contractual requirements flow down to financial entities: you must require your key suppliers to disclose vulnerability and patching status relevant to the services they provide.
In practice, this means building a supplier vulnerability questionnaire into your third-party risk management (TPRM) process, and ensuring your contracts include clauses covering vulnerability notification timelines and patch SLAs.
Common questions
What is the penalty for DORA non-compliance?
For financial entities, national competent authorities can impose periodic penalty payments of up to 1 % of average daily global turnover for each day of non-compliance. Critical ICT third-party service providers face fines up to €5 million or 1 % of global annual turnover.
Does DORA replace NIS2 for financial entities?
DORA is lex specialis — it takes precedence over NIS2 for financial entities in areas of overlap. Banks subject to both do not need to comply twice, but must follow the more stringent DORA requirements.
How often must vulnerability scans be conducted under DORA?
DORA does not prescribe a specific frequency, but the RTS guidance and supervisory expectations point to continuous scanning for critical assets and at minimum monthly scanning for all in-scope systems.
Can we use existing VM tools to comply with DORA?
Your existing scanner (Qualys, Tenable, etc.) can discover findings, but DORA compliance requires the layer above the scanner: risk-based prioritisation, SLA tracking, third-party risk integration, and board-level reporting. That is where Centraleyezer fits.