Learn
Article 24 is short. Six paragraphs. Most of what gets attributed to it is not in it, so this guide quotes the text and then says plainly where the rest comes from.
The digital operational resilience testing programme sits in Chapter IV of Regulation (EU) 2022/2554, across Articles 24 to 27. Article 24 sets the programme obligation, Article 25 lists the kinds of test, and Articles 26 and 27 govern threat-led penetration testing. DORA has applied since 17 January 2025.
Three things you will read elsewhere that are worth checking before you build a programme around them: that Article 24 requires board approval of the testing programme, that Article 25 mandates a fixed list of ten test types, and that a penetration test is required every three years. The first is true only through a chain of reasoning that is worth seeing. The second and third are not true at all.
| The programme obligation | Article 24(1). Applies to financial entities other than microenterprises. |
| The only fixed frequency in Article 24 | Article 24(6): at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions. |
| Who runs the tests | Article 24(4): independent parties, whether internal or external. Internal testers require dedicated resources and managed conflicts of interest. |
| The test types | Article 25(1) offers an illustrative list, introduced by the words "such as". It is not a mandatory checklist of ten. |
| Threat-led penetration testing | Article 26(1): at least every 3 years, but only for entities identified by their competent authority under Article 26(8). |
| What DORA says testing costs | Nothing. It sets no figures. See the section on costs below. |
What Article 24 actually says
Article 24(1) requires financial entities, other than microenterprises, to "establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk-management framework referred to in Article 6". That last clause is the load-bearing one, and we come back to it when we get to the board.
The rest of the article, in brief and in its own terms:
| Paragraph | What it requires |
| 24(1) | Establish, maintain and review the programme, as an integral part of the ICT risk management framework. Microenterprises are outside this. |
| 24(2) | The programme includes a range of assessments, tests, methodologies, practices and tools applied in accordance with Articles 25 and 26. |
| 24(3) | Follow a risk-based approach, considering the evolving ICT risk landscape, specific risks, and the criticality of information assets and services. |
| 24(4) | Tests are undertaken by independent parties, internal or external. Internal testers need sufficient dedicated resources, with conflicts of interest avoided across design and execution. |
| 24(5) | Establish procedures and policies to prioritise, classify and remedy all issues revealed by testing, and internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed. |
| 24(6) | At least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions. |
Note what is absent. Article 24 does not mention the management body. It does not set frequencies other than the yearly test in 24(6). It does not empower a regulatory technical standard. If you have seen a citation to "the RTS under Article 24(2)", there isn't one; the RTS that matters in this chapter is the one for TLPT, mandated by Article 26(11).
Does the board really have to approve the testing programme?
Yes, but not because Article 24 says so, and the distinction matters when someone asks you to point at the sentence. Article 24 is silent on the management body. The obligation arises from two provisions read together:
Article 24(1): the testing programme is "an integral part of the ICT risk-management framework referred to in Article 6".
Article 5(2): "The management body of the financial entity shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework referred to in Article 6(1)."
The programme is an integral part of the framework. The board must approve all arrangements related to the framework. Therefore the board must approve the programme.
That is a sound chain, and it is how supervisors will read it. But it is a chain, not a single sentence, and you should know that going in rather than discovering it when challenged. Article 5(2) does list specific approval duties at points (a) to (i), and the testing programme is not one of the named items. What the list does name, and what you should therefore expect to evidence separately, includes the digital operational resilience strategy at point (d), the ICT business continuity policy and response and recovery plans at (e), the ICT internal audit plan at (f), the budget at (g), and the ICT third-party policy at (h).
Two further provisions are worth putting in front of the board itself. Article 5(4) requires members to "actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk", including specific training on a regular basis. And Article 50(5) provides that Member States shall confer on competent authorities the power to apply administrative penalties and remedial measures, subject to national law, "to members of the management body, and to other individuals who under national law are responsible for the breach".
So personal exposure is real, but it is real in the specific way the regulation constructs it: through national law, under Article 50(5). It is not a free-floating threat, and describing it accurately is more persuasive with a board than describing it luridly.
Article 25: an illustrative list, not a mandatory ten
This is the most consequential misreading in circulation. Article 25(1) says the programme "shall provide ... for the execution of appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing."
"Such as" is illustrative. The obligation is to execute appropriate tests, selected through the risk-based approach that Article 24(3) requires. It is not a compliance checklist of ten items you must tick, and a programme that mechanically runs every listed technique against every system without a risk rationale is arguably further from Article 24(3) than one that reasons about what is appropriate and writes the reasoning down.
Below is the Article 25(1) list in full, with a cadence column. The cadences are ours, offered as a starting point. DORA sets no frequency for any of these except the yearly obligation in Article 24(6). If you adopt them, adopt them as your decision, not as a regulatory requirement.
| Test type (Article 25(1) wording) | Illustrative cadence (ours, not DORA's) | Note |
| Vulnerability assessments and scans | Continuous or monthly | Central securities depositories and central counterparties have a specific obligation under Article 25(2) to run these before any deployment or redeployment. |
| Open source analyses | Continuous | Often omitted from summaries of Article 25 entirely, though it is named in the text. |
| Network security assessments | Quarterly or semi-annual | Segmentation, firewall rules, access paths. |
| Gap analyses | Annual | Feeds the Article 6(5) framework review. |
| Physical security reviews | Annual | Named explicitly in Article 25(1); frequently forgotten in ICT-only programmes. |
| Questionnaires and scanning software solutions | As appropriate | Also named in the text, and also usually missing from the "ten types" lists. |
| Source code reviews, where feasible | Per release | The words "where feasible" are in the regulation. Document the rationale where it is not. |
| Scenario-based tests | Semi-annual or annual | Tabletops and simulations. |
| Compatibility testing | Per material change | Interoperability after updates and migrations. |
| Performance testing | Quarterly or semi-annual | Load, stress, capacity. |
| End-to-end testing | Semi-annual or annual | Full process chains including failover and restoration. |
| Penetration testing | Annual for critical systems | An ordinary penetration test. Not the same thing as TLPT, and DORA sets no separate frequency for it. |
Two claims to strike from your programme document. First: "penetration testing must be performed at least every three years." DORA says no such thing. The three-year cycle in Article 26(1) belongs to threat-led penetration testing, and only for entities identified under Article 26(8). Ordinary penetration testing has no DORA frequency of its own; what governs it is Article 24(6), which requires appropriate tests at least yearly on systems supporting critical or important functions. Second: "Article 25 uses shall include language, so all types are mandatory." It uses "such as".
Who is actually in scope
Worth being careful here, because the carve-outs are commonly stated wrongly and they are not all the same carve-out.
- The Article 24 programme obligation applies to financial entities other than microenterprises. Microenterprises are outside the programme requirement itself.
- Article 25(3) tells microenterprises how to approach the tests in Article 25(1): by combining a risk-based approach with strategic planning, balancing resources and time against urgency, type of risk and criticality. So they are not exempt from testing, they are governed differently.
- Article 16(1) is a separate thing again: a simplified ICT risk management framework for a specific closed list of entities, including small and non-interconnected investment firms and certain exempted payment and e-money institutions. It is not a microenterprise regime, and conflating the two is a common error.
- TLPT under Article 26(1) excludes both microenterprises and the Article 16(1) entities, and then applies only to those entities a competent authority has identified under Article 26(8).
If you are unsure which of these you are, that determination is itself a piece of evidence a supervisor may ask for. Write it down and date it.
Building the annual programme
A compliant programme is not a list of tests. It is a governed document tying testing activity to your ICT risk landscape, with owners, timelines and a route from finding to remediation to board. Six components, in the order they depend on each other.
1. Scope
Start from the critical or important functions, because that is what Article 24(6) keys the yearly obligation to. DORA defines a critical or important function at Article 3(22) as one whose disruption "would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities". Every ICT system and application supporting one of those is in scope for at-least-yearly testing, including where the supporting service is provided by a third party.
2. Calendar
Map each chosen test type to a cadence, and mark clearly which cadences are regulatory and which are yours. Exactly one is regulatory: the yearly test on systems supporting critical or important functions under Article 24(6). For entities identified under Article 26(8), TLPT runs at least every three years. Everything else on your calendar is a risk-based choice you made and must be able to justify under Article 24(3).
3. Who runs the tests
Article 24(4) requires independent testers, internal or external. Where they are internal, you must dedicate sufficient resources and avoid conflicts of interest across both the design and the execution of the test. TLPT tightens this considerably: under Article 27(2), using internal testers for a TLPT requires the competent authority to have approved it, to have verified that you have sufficient dedicated resources and managed conflicts of interest, and the threat intelligence provider must be external to the entity. Article 26(8) adds that entities using internal testers must contract external testers every three tests, and that credit institutions classified as significant may only use external testers.
4. Prioritisation
Article 24(3) requires the risk-based approach, and names what to weigh: the evolving ICT risk landscape, the specific risks the entity is exposed to, the criticality of information assets and services, and any other factor the entity deems appropriate. That last clause gives you latitude, and latitude you use without writing down your reasoning is latitude you cannot defend.
5. Findings
Article 24(5) is the paragraph most often paraphrased into something it does not say. Here is the actual text: financial entities "shall establish procedures and policies to prioritise, classify and remedy all issues revealed throughout the performance of the tests and shall establish internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed."
Two obligations, not one. Prioritise, classify and remedy the issues; and validate that they are fully addressed. The second is the one programmes skip, and it is why closing a finding on the strength of an engineer's assurance is not enough. Severity bands and remediation deadlines by severity are sensible practice, but they are yours to set: DORA prescribes none.
6. Board reporting
Define what reaches the management body and when. Article 5(2)(i) requires reporting channels that keep the board informed about, among other things, at least major ICT-related incidents and their impact, as well as response, recovery and corrective measures. Testing outcomes are the natural companion to that. Critical findings should not wait for a quarterly cycle.
What testing costs, and why this article no longer tells you
An earlier version of this article quoted figures: EUR 15,000 to 50,000 for an external penetration test, EUR 150,000 to 500,000 for a TLPT engagement, six to twelve months of elapsed time. Those numbers have been removed, and it is worth saying why rather than quietly deleting them.
They could not be sourced. DORA sets no figures. The ECB's TIBER-EU framework and the TLPT technical standard describe the phases and the required roles, but publish no costs. Neither do the ESAs. What exists in the market is a scatter of vendor and consultancy estimates that disagree with each other by a factor of several, which tells you they are quotes for different scopes rather than a measurement of anything. Repeating one of them with a euro sign in front of it would have dressed a guess as a fact, and a board that budgets from it and then discovers the real number has been badly served.
What can be said with a source is narrower and more useful. Article 5(2)(g) makes budget a board duty in its own right: the management body must "allocate and periodically review the appropriate budget to fulfil the financial entity's digital operational resilience needs in respect of all types of resources", including ICT security awareness programmes and resilience training and ICT skills for staff. So the board is required to fund resilience adequately and to revisit that funding. What "adequate" costs in your case is a function of your scope, your estate and your providers, and the only reliable way to know it is to scope the engagement and take quotes.
The cost driver that is visible from the regulation is the shape of the work. TLPT requires an external threat intelligence provider where internal testers are used, involves the competent authority, runs against live production systems under Article 26(2), and follows the phases in the TLPT technical standard. That is structurally more expensive than a scan. You do not need an invented figure to tell a board that.
Managing the programme in Venvera
Venvera has a resilience testing module, and here is precisely what it does. Tests are recorded with a type, a scope, a methodology, a testing provider, a scheduled date and a status, drawn from a library of DORA test types that carries a recommended frequency and scope guidance for each. There is a schedule for recurring tests, and the dashboard surfaces what is planned, what is running and what is late.
Findings hang off the test that produced them, each with a severity, an assignee, a due date, a remediation plan and a remediation status, so an open finding has an owner and a date rather than a line in a report. That is the machinery Article 24(5) asks for on the "prioritise, classify and remedy" half of the obligation.
The validation half, the internal methodology that ascertains a weakness is fully addressed, is a discipline you still have to run. The module tracks the status you set; it does not decide for you that a fix is proven, and we would rather say so than let you assume a gate exists that does not.
DORA is one of several regimes most financial entities carry at once, and resilience testing evidence is some of the most reusable material across them. The crosswalk engine lets evidence produced once serve its counterparts under NIS2 or ISO 27001 rather than being rebuilt. For the TLPT side specifically, see our guide to threat-led penetration testing under Articles 26 and 27.
Frequently Asked Questions
Does DORA Article 24 require the board to approve the testing programme?
Not in those words, and Article 24 does not mention the management body at all. The obligation is real but it arrives by a chain of two provisions. Article 24(1) makes the testing programme "an integral part of the ICT risk-management framework referred to in Article 6", and Article 5(2) requires the management body to define, approve, oversee and be responsible for the implementation of all arrangements related to that framework. Approval of the programme follows from the two together. Note that Article 5(2) does list specific approval duties at points (a) to (i), and the testing programme is not among the named items, so anyone claiming Article 24 mandates board approval on its own face has not read Article 24.
Are the ten test types in Article 25 all mandatory?
No. Article 25(1) introduces its list with the words "such as", which makes it illustrative rather than exhaustive or mandatory. The actual obligation is to execute appropriate tests, chosen using the risk-based approach Article 24(3) requires. The list also has more than ten items and includes open source analyses and "questionnaires and scanning software solutions", both of which are routinely dropped from the "ten mandatory types" tables in circulation. Choose what is appropriate to your risk, and document why.
How often does DORA require penetration testing?
DORA sets no frequency for ordinary penetration testing. The claim that a penetration test is required every three years is a confusion with threat-led penetration testing, which Article 26(1) requires at least every three years and only of entities identified by their competent authority under Article 26(8). The frequency that does bind you is in Article 24(6): at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions. Whether the appropriate test for a given system is a penetration test is a risk-based judgment under Article 24(3).
What does DORA say a resilience testing programme costs?
Nothing. DORA sets no cost figures, and neither the ECB's TIBER-EU framework nor the ESAs publish any. Figures circulating for penetration tests and TLPT engagements come from vendor and consultancy estimates that vary by a wide margin because they price different scopes. What the regulation does say is at Article 5(2)(g): the management body must allocate and periodically review the appropriate budget to fulfil the entity's digital operational resilience needs across all types of resources. Budget is a board duty; the number is a scoping exercise, not a citation.
Does the testing programme apply to microenterprises?
The Article 24 programme obligation applies to financial entities other than microenterprises, so microenterprises sit outside the programme requirement itself. They are not exempt from testing: Article 25(3) requires them to perform the tests referred to in Article 25(1) by combining a risk-based approach with strategic planning of ICT testing, balancing the resources and time allocated against the urgency, type of risk and criticality of information assets and services. Keep this separate from Article 16(1), which is a different carve-out entirely, providing a simplified ICT risk management framework for a specific closed list of entities.
What exactly does Article 24(5) require for findings?
Two things, and the second is the one usually missed. In the regulation's own words, entities "shall establish procedures and policies to prioritise, classify and remedy all issues revealed throughout the performance of the tests and shall establish internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed." So you need a triage and remediation process, and you also need a validation methodology that establishes a finding is genuinely closed. Severity bands and per-severity remediation deadlines are sensible, but they are your choice: DORA prescribes none.
Primary sources
Every article reference, quotation and frequency in this guide was checked against the texts below. The cost figures previously carried in this article were removed because no primary source supports them.
- Regulation (EU) 2022/2554 (DORA) - Articles 3(22), 5, 6, 16, 24, 25, 26, 27 and 50. It contains 64 articles and applies from 17 January 2025.
- Commission Delegated Regulation (EU) 2025/1190 - the RTS on threat-led penetration testing: criteria, tester requirements, scope, phases and methodology.
- Commission Delegated Regulation (EU) 2024/1774 - the RTS on ICT risk management tools, methods, processes and policies.
- ECB TIBER-EU framework - the threat intelligence-based ethical red teaming framework underpinning TLPT. Publishes no cost figures.
Put the testing programme somewhere the board can see it
Scheduled tests, findings with owners and due dates, and board-ready reporting, kept alongside the rest of your obligations.
Book a demo →Last updated: July 2026. General information, not legal advice. Test cadences suggested in this article are Venvera's illustrative defaults, not regulatory requirements; the only frequency DORA fixes in Article 24 is the yearly test in Article 24(6). Confirm article references against the current text and your competent authority's guidance.
