Does DORA set a fixed vulnerability-scan cadence for a digital bank?

For ICT assets supporting critical or important functions, yes — a fixed one. Article 10(2)(b) of the RTS on ICT risk management framework (Commission Delegated Regulation (EU) 2024/1774) requires automated vulnerability scanning and assessments on those assets 'on at least a weekly basis.' For everything outside that critical/important tier, the frequency is risk-based — 'commensurate to the classification established in accordance with Article 8(1)' of DORA and the asset's overall risk profile, with no fixed number attached.

Is this the same as DORA's annual testing programme under Article 24?

No, and conflating the two understates the actual requirement. Article 24(6) of DORA sets an 'at least yearly' floor for the digital operational resilience testing programme as a whole — a basket of tests reviewed and executed across the ICT estate. That annual programme-level requirement is a separate, higher-level obligation from the RTS's tool-specific weekly floor on automated vulnerability scanning for critical-function assets. A bank that only runs its testing programme once a year and treats that as covering vulnerability scanning is reading the annual figure into the wrong article.

Is this the same as DORA's threat-led penetration testing (TLPT) requirement?

No — different tool, different cadence, different scope. TLPT under Article 26/27 is a three-year-cycle, live-production, broad-scope red-team-style engagement that only applies to entities identified as systemically important by their competent authority. Weekly automated vulnerability scanning under RTS Article 10 applies far more broadly, to any financial entity with ICT assets supporting critical or important functions, and it's a scanning/assessment activity, not a red-team engagement. See NIS2 and DORA compliance without the consultant theatre for TLPT's cost and cadence in full — it isn't repeated here.

What counts as an ICT asset supporting a 'critical or important function'?

That classification is the output of your own DORA identification and classification exercise under Article 8(1) of Regulation (EU) 2022/2554 — every financial entity in DORA's scope has to inventory its ICT assets and tag which ones support critical or important functions. The RTS doesn't hand you a fixed list; it hands you the consequence of the tag you already assigned. If the classification exercise is stale or under-scoped, the weekly-scan obligation quietly doesn't reach assets that should be covered by it — this is a classification problem before it's a scanning-frequency problem.

How does this compare to the fixed quarterly cadence casinos use, or the risk-based cadence crypto exchanges use?

It's closer to the casino model in that it's a fixed number, not closer to the crypto-exchange model. PCI DSS 11.3.2 hands casinos a flat quarterly external-scan requirement, full stop. NYDFS 23 NYCRR 500.5(a)(2) hands crypto exchanges a risk-assessment-driven frequency with no calendar number attached. DORA's RTS does something in between: a fixed weekly floor for the critical/important-function subset of the estate, and a risk-based frequency for everything else — the fixed part is actually tighter than PCI's quarterly, and the risk-based part behaves like NYDFS's model. See how often an online casino should run a vulnerability assessment and how often a crypto exchange should run a vulnerability assessment for the other two cadence structures.

How often should a digital bank run a vulnerability assessment?

The short answer

For a digital bank in DORA's scope, vulnerability-scan frequency isn't left entirely to a risk assessment the way it is for a crypto exchange under NYDFS, and it isn't a single flat number the way PCI DSS sets one for a casino. Article 10 of the RTS on ICT risk management framework — Commission Delegated Regulation (EU) 2024/1774 — requires automated vulnerability scanning and assessments on ICT assets supporting critical or important functions "on at least a weekly basis." Assets outside that tier get a risk-based frequency instead, tied to the classification the bank has already assigned them under DORA Article 8(1). The weekly floor is a harder number than PCI's quarterly cadence, and it sits one legal layer below the "at least yearly" testing-programme requirement most banks quote first.

Who this is for

This is written for the CISO, Head of Security, or DORA programme lead at a digital bank, neobank, or other EU credit institution who is setting — or auditing — a Vulnerability Assessment schedule and needs to know which article actually sets the clock, rather than assuming the Article 24 "at least yearly" testing figure covers vulnerability scanning specifically.

It's not for you if your entity sits under a different regime — see how an online casino's PCI DSS quarterly rule or a crypto exchange's NYDFS risk-based rule work instead if either applies to your license footprint. It's also not for you if the question is whether you owe a threat-led penetration test (TLPT) rather than a vulnerability scan — that's a separate, narrower obligation covered below and in full in NIS2 and DORA compliance without the consultant theatre.

Two layers, not one number

DORA's testing obligations come in two legal layers, and the cadence question only makes sense once they're separated:

Regulation (EU) 2022/2554 — the Level 1 text. Article 24(6) requires that "appropriate tests are conducted on all ICT systems and applications supporting critical or important functions" at least yearly, as part of a broader digital operational resilience testing programme. Article 25(1) names vulnerability assessments and scans as one of the eligible tools in that programme's toolkit, alongside penetration testing, scenario-based tests, and others — but Article 25 itself attaches no separate frequency to vulnerability assessments specifically.
Commission Delegated Regulation (EU) 2024/1774 — the Level 2 RTS. This is where a vulnerability-scan-specific number actually appears. Article 10(2)(b) requires financial entities to "ensure the performance of automated vulnerability scanning and assessments on ICT assets," and the article's closing paragraph makes the number explicit: for ICT assets supporting critical or important functions, that scanning runs "on at least a weekly basis." For assets outside that tier, the RTS instead ties frequency to "the classification established in accordance with Article 8(1) ... and the overall risk profile of the ICT asset" — no fixed number, closer to a risk-based model.

The practical trap is treating the Article 24 annual figure as the answer to "how often do we scan for vulnerabilities." It isn't — it's the floor for the overall testing programme. The RTS's weekly floor for critical-function assets is a separate, materially stricter requirement sitting underneath it.

How the three regimes actually compare

Regime	Applies to	Cadence for VA/scanning	What sets it
PCI DSS 11.3.2	Online casino / card processor	Fixed: quarterly external scan	A flat number written into the standard
NYDFS 23 NYCRR 500.5(a)(2)	Crypto exchange with a BitLicense	Risk-based, no fixed number	The entity's own risk assessment
DORA RTS Art. 10(2)(b)	Digital bank (credit institution)	Fixed: at least weekly for critical/important-function assets; risk-based for the rest	A fixed floor for the highest-risk tier, risk-based below it

The weekly figure surprises most teams that assume "EU regulation" defaults to something closer to an annual cadence — DORA's Level 1 text does read that way in isolation, and the RTS is easy to miss if a compliance review stops at the Regulation itself and doesn't pull in the delegated act underneath it.

What "critical or important function" actually gates

The weekly obligation doesn't apply to every server a bank runs — it applies to ICT assets supporting functions the bank has classified as critical or important under its own DORA Article 8(1) identification exercise. That classification work is the bank's own output, not a list the RTS hands down. Two consequences follow directly:

The scanning obligation is only as good as the classification underneath it. An asset that should have been tagged critical or important but wasn't doesn't get the weekly floor applied to it — the gap shows up as a classification failure before it shows up as a missed scan.
Everything outside that tier still needs a documented cadence. The RTS's "commensurate to ... the overall risk profile" language for non-critical assets is a process requirement, not a free pass — it requires the same kind of defensible, documented reasoning that NYDFS expects from a crypto exchange's risk assessment, just applied to a narrower slice of the estate.

Not the annual programme, and not TLPT

Two DORA requirements are easy to confuse with the weekly RTS scanning floor, and neither is the same obligation:

The Article 24 testing programme is the yearly review-and-execute cycle for the whole toolkit named in Article 25 — vulnerability assessments, scenario-based tests, performance testing, and others. It's a programme-level cadence, not a per-tool one.
Threat-led penetration testing (TLPT) under Article 26/27 is a three-year-cycle, live-production, red-team-style engagement that only applies to entities their competent authority identifies as systemically important, and requires external testers for significant credit institutions. It's a different tool, a different cadence, and a much narrower population of entities than the weekly scanning requirement — see DDoS stress testing sign-off for a digital bank for how that distinction plays out for a different test type entirely, and the NIS2/DORA breakdown above for TLPT's cost and cadence detail in full.

What you get each cycle

A Vulnerability Assessment engagement runs 3–5 business days per cycle, with a recurring schedule built to match whichever cadence actually applies — weekly automated scanning for the ICT assets your DORA classification tags as critical or important, and a documented risk-based schedule for the rest of the estate. Every finding from automated scanning is manually validated before it reaches a report, so a weekly cadence doesn't mean a weekly flood of unverified noise landing on your team.

Limitations

This describes the RTS text, not a determination of your entity's specific scope. Whether your institution is in DORA's scope at all, and which of your ICT assets your own Article 8(1) classification tags as critical or important, are determinations for your DORA compliance function or legal counsel, not a testing vendor.
The RTS sets scanning frequency, not remediation SLAs. Article 10 also covers patch prioritisation and remediation tracking, but this post is scoped to the scanning-cadence question specifically.
This isn't a TLPT or penetration-testing cadence guide. Those sit under different articles with different triggers — see the FAQ and the linked posts above for that distinction.
A weekly technical floor still needs a working classification exercise underneath it. A scanning schedule built on a stale or incomplete Article 8(1) classification will under-cover the estate no matter how often the scans run.

Decision framework and next step

If your bank is in DORA's scope, don't default to the Article 24 "at least yearly" figure as your vulnerability-scan cadence — confirm which ICT assets your own Article 8(1) classification tags as supporting critical or important functions, put automated scanning on at least a weekly cycle for that tier, and build a documented risk-based schedule for everything else. If you're not sure your current classification or scan schedule would hold up against Article 10's actual text, tell us your estate and current schedule and we'll help you map it to the RTS requirement that actually applies.

Sources and review

Regulation (EU) 2022/2554 (DORA), Articles 24 and 25, are cited to the European Union's own legislative text. Commission Delegated Regulation (EU) 2024/1774 (the RTS on ICT risk management framework), Article 10 — including the "on at least a weekly basis" cadence for ICT assets supporting critical or important functions and the risk-based frequency for other assets — is cited to the European Commission's own published delegated act text (adopted as C(2024) 1532 final). The PCI DSS and NYDFS comparison figures referenced in the table repeat facts already sourced and cited in full in the linked casino and crypto-exchange vulnerability-assessment posts, and are not re-verified here. No customer results, case-specific figures, or SLA claims are cited. Author: AnySec Engineering. Published 2026-09-10.