What DORA actually asks of your exercise program

If you own resilience testing at an EU financial entity, you have probably been pointed at Article 26 and told DORA requires scenario testing.

Article 26 is threat-led penetration testing. It applies only to entities a competent authority specifically identifies, it runs on a three-year clock, and it is carried out against live production systems. It is not the article that governs your exercise program, and the difference is not academic: it changes who owes the obligation, and how often.

What follows is what Chapter IV actually says, article by article, with the parts that summaries most often get backwards. Everything here is sourced to the regulation itself and cited in the footnotes.

Who this applies to

DORA's scope is Article 2, and "financial entity" is a defined term rather than a general description. Article 2(1) lists twenty-one categories of entity; Article 2(2) makes the first twenty — points (a) to (t) — the "financial entities" that Chapter IV's testing obligations are addressed to.³

Those twenty are: credit institutions; payment institutions; account information service providers; electronic money institutions; investment firms; crypto-asset service providers and issuers of asset-referenced tokens; central securities depositories; central counterparties; trading venues; trade repositories; managers of alternative investment funds; management companies; data reporting service providers; insurance and reinsurance undertakings; insurance, reinsurance and ancillary insurance intermediaries; institutions for occupational retirement provision; credit rating agencies; administrators of critical benchmarks; crowdfunding service providers; and securitisation repositories.³

**The twenty-first category, point (u), is ICT third-party service providers — and they are not financial entities.**³ That distinction is easy to lose and worth holding onto: providers are inside DORA's scope, but the testing programme in Articles 24 to 26 is addressed to the financial entity, not to its suppliers. A provider comes into a test through Article 26(3), which lets one be brought inside the entity's own threat-led test.²

Three carve-outs then sit on top of the list, and they matter to most readers more than the list does:

• Microenterprises are outside the general programme obligation and outside the yearly testing floor,¹ and are excluded from TLPT.² Article 25(3) allows them a risk-based approach.¹ DORA defines a microenterprise as a financial entity employing fewer than 10 persons with an annual turnover or balance-sheet total not exceeding EUR 2 million.³
• Article 2(3) excludes some entities outright — among them certain small managers of alternative investment funds, and institutions for occupational retirement provision operating schemes with no more than 15 members in total.³ That is not the complete list; check Article 2(3) against the text if you are near the line.
• CSDs and CCPs — central securities depositories and central counterparties — carry one obligation the rest do not: vulnerability assessments before deployment.¹

Requirements at a glance

Citations are to Regulation (EU) 2022/2554.¹ ² As of September 2026.

The part people get wrong: Article 26 is not the scenario-testing article

Article 26 is titled "Advanced testing of ICT tools, systems and processes based on TLPT." Paragraph 1 reads:

"Financial entities, other than entities referred to in Article 16(1), first subparagraph, and other than microenterprises, which are identified in accordance with paragraph 8, third subparagraph, of this Article, shall carry out at least every 3 years advanced testing by means of TLPT. Based on the risk profile of the financial entity and taking into account operational circumstances, the competent authority may, where necessary, request the financial entity to reduce or increase this frequency."²

Three things in that sentence are load-bearing, and all three are lost in the usual paraphrase:

It is not a general obligation. Two exclusions sit on the face of the text, and then a positive identification requirement: only entities identified by the competent authority owe a TLPT at all. If nobody has identified you, Article 26 is not your article.

The cadence is at least every three years — not annual. Your supervisor can raise or lower it on your risk profile.

It is adversarial testing against live production systems. DORA defines threat-led penetration testing, at Article 3(17), as:

"a framework that mimics the tactics, techniques and procedures of real-life threat actors… a controlled, bespoke, intelligence-led (red team) test of the financial entity's critical live production systems."³

Read that definition once and the misattribution becomes hard to sustain. This is a red-team engagement against production. It is not a facilitated discussion, and nothing about it describes an exercise programme.

The European Supervisory Authorities put the division plainly, twice, in their own final report: TLPT is advanced testing, and **"less advanced testing is already covered by Article 24 of DORA."**² That is the article your exercise program lives under.

What the yearly floor actually requires

Article 24(6):

"Financial entities, other than microenterprises, shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions."¹

Three qualifiers, each doing work:

"At least yearly" is a floor, and it is the only general-testing interval DORA states. It sets a minimum frequency for a body of testing, not a date for a single event.

"Appropriate tests" — the regulation does not name which test. An entity conducting vulnerability assessments and penetration testing on the right systems has conducted appropriate tests.

"All ICT systems and applications supporting critical or important functions" is a scope limit, not a scope expansion. The yearly floor attaches to critical-or-important-function systems, not to your whole estate.

That last phrase is where the real scoping work happens, and DORA defines it. Article 3(22):

"'critical or important function' means a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law."³

Three things in that definition decide how much of your estate the yearly floor reaches.

It is a test on the function, not on the system. Article 24(6) reaches the systems and applications supporting critical or important functions, so scoping runs in two steps: identify the functions that meet this definition, then find the systems behind them. Starting from a system inventory and asking which entries feel important inverts the order the regulation sets.

The threshold is "materially impair," and the routes in are alternatives. A function qualifies if its disruption would materially impair financial performance, or the soundness or continuity of services and activities, or if its discontinued, defective or failed performance would materially impair continuing compliance with the conditions and obligations of the entity's authorisation, or its other obligations under applicable financial services law. Any one route is enough.

The second limb is the one that gets missed. It is not a business-impact test. A function whose defective or failed performance would put the entity's authorisation or its obligations under financial services law at risk is critical or important on that ground alone — regardless of where it sits on financial performance. A criticality rating built around revenue and customer impact will not reliably find it.

Which leads to the sentence this page exists to get right:

DORA does not require an annual exercise, an annual tabletop, or an annual scenario test. It requires appropriate tests, at least yearly, on the systems supporting critical or important functions. Scenario-based testing is one of the appropriate kinds available to you — which is a different claim, and the honest one.

Where scenario-based testing actually sits

Article 25(1), in full:

"The digital operational resilience testing programme referred to in Article 24 shall provide, in accordance with the criteria set out in Article 4(2), 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."¹

Read structurally, that sentence says four things:

1. The obligation attaches to the programme, the one Article 24 requires. Article 25 does not create a separate duty; it says what the programme must provide for.
2. "Appropriate tests, such as" is an open enumeration. It is illustrative, not a checklist, and nothing in it says every listed test must be run by every entity.
3. Scenario-based tests sit mid-list, between source code reviews and compatibility testing, carrying no more weight in the text than physical security reviews or questionnaires.
4. What counts as appropriate is entity-dependent by the text's own terms — the paragraph executes in accordance with criteria set out elsewhere in the regulation, and Article 25(3) gives microenterprises a risk-based approach outright.

So scenario-based testing is named in the regulation, and it is named as one option inside the programme rather than as a standalone mandate on a clock of its own. That is a weaker claim than the one you will find on most vendor pages. It is also the one that survives contact with an examiner.

Who runs the test

Tests are undertaken by independent parties, whether internal or external, with conflicts of interest avoided at every stage.¹

Internal testers are explicitly permitted. Independence here means separation from the thing being tested; the regulation does not require an external engagement.

What has to happen after the test

This is the paragraph that gets skipped, and it is where most programmes are actually thin.

Article 24(5) requires procedures to prioritise, classify and remedy all issues revealed by testing, and to establish **internal validation that weaknesses are fully addressed.**¹

An exercise that ends in a report, a circulated deck and no closure loop does not meet that paragraph. The obligation does not stop at conducting the test; it runs through prioritisation, remediation, and evidence that the weakness is actually gone.

Where the regulation is deliberately open

Naming these is more useful than papering over them, because your supervisor may read them differently than you do.

• "Appropriate" is not defined. Neither Article 24(6) nor Article 25(1) quantifies what makes a test appropriate for a given entity; the judgement is yours to make and to document.
• No test type is designated. The Article 25(1) list is illustrative. Reading it as a required set is a common and expensive misreading in both directions.
• The proportionality criteria live elsewhere. Article 25(1) executes "in accordance with the criteria set out in Article 4(2)" — a cross-reference this guide reproduces but does not interpret.
• TLPT identification is the competent authority's call, and so is adjusting the three-year frequency in either direction.²
• The technical standards under Article 26(11) were developed by the ESAs in agreement with the ECB and in accordance with the TIBER-EU framework.² Check the current adopted instrument and its application date against the Official Journal before relying on a number for it — including any number quoted to you by a summary.

Why scenario-based tests should push back

DORA's programme doesn't end at the test. Article 24(5) requires procedures to prioritise, classify and remedy all issues revealed by testing, and to validate internally that each weakness is fully addressed.¹ That loop can only work on what the tests find.

Where your programme includes scenario-based tests, design them to find something. A test that follows a script mostly confirms the script. A scenario that adapts to what people decide shows where the response actually breaks: an escalation that stalls, a decision nobody owns, an assumption that fails once the situation moves. Those are issues 24(5) can prioritise and remedy, and adaptive exercises are one of the most direct ways to surface them.

Keep the testing types straight. A discussion-based exercise, however adaptive, tests people, decisions and coordination. It doesn't test the ICT systems themselves. That is the job of the technical tests in your programme, and TLPT, where it applies, is a different instrument again.

What Crewcible produces that maps to it

Crewcible is built for the exercise itself — designing it, running it, and capturing what came out of it. Three outputs line up against what Chapter IV asks for.

The exercise. Scenario-based tests are named in Article 25(1) as one of the appropriate tests a resilience testing programme provides for.¹ Global Library scenarios are facilitator-led and built on narrated, escalating disruption, which is the shape that test takes in practice. They are designed to support the obligations on this page.

The record. Crewcible captures decisions and reasoning per participant and per inject as the exercise runs, so what you retain is a record rather than a recollection written up a week later. Independence and conflict-of-interest expectations under Article 24(4) are easier to evidence when the record shows who decided what, and when.¹

The improvement plan. Article 24(5) is a remediation requirement, not a testing requirement: prioritise, classify, remedy, and validate internally that the weakness is fully addressed.¹ After-action output comes out of the exercise rather than being reconstructed after it, which is the half that most often goes thin.

The facilitator decides what gets released and when, so the judgement stays where the regulation assumes it is: with your people. AI enabled, human led.

Crewcible is built by experts who have supported crisis situations and exercises in the world's largest organizations.

For a ready-to-run financial-services starting point, see 48 Hours of Confidence: Anatomy of a Deposit Run in the Global Library. It is a financial-sector scenario offered as a starting point. It isn't built around DORA.

---

Regulatory references current as of September 2026. This guide is scheduled for re-verification by March 2027.

¹ Regulation (EU) 2022/2554 (DORA), Articles 24 and 25. Article 24(6) and Article 25(1) are quoted verbatim; the remaining paragraphs of Articles 24 and 25 are summarised.

² European Supervisory Authorities Joint Committee, Final Report on Draft Regulatory Technical Standards on threat-led penetration testing under Article 26(11) of Regulation (EU) 2022/2554 (JC 2024 29, 17 July 2024), which quotes Article 26(1) verbatim and states the Article 24 / Article 26 division. The report contains the draft standards as proposed by the ESAs; confirm the adopted instrument against the Official Journal.

³ Regulation (EU) 2022/2554 (DORA), Articles 2 and 3. Article 3(17) is quoted verbatim; the scope list, the exclusions and the definition of a microenterprise are summarised.