DORA Compliance: What the Testing Pillar Actually Requires

The Digital Operational Resilience Act has applied since 17 January 2025, and it is a regulation, not a directive. Regulation (EU) 2022/2554 binds financial entities in every EU member state directly, with no national transposition to wait for and no room to read it as guidance.

Most of DORA can be satisfied on paper: policies, registers, contract clauses, reporting templates. One pillar cannot. Article 24(6) requires tests to actually run, at least yearly, on every ICT system supporting a critical or important function.

That is the part of DORA compliance a binder full of policies does not cover, and it is the part this guide treats in depth.

What is the Digital Operational Resilience Act?

DORA is the EU’s response to a plain observation: a financial institution can be perfectly solvent and still be down. Capital buffers say nothing about whether the e-banking front end survives a traffic surge or whether a core provider’s outage cascades through the sector.

The regulation was adopted on 14 December 2022, and Article 64 sets the application date: it applies from 17 January 2025. Since that date, supervisors can examine any in-scope entity against the full set of DORA requirements.

Article 3(1) defines digital operational resilience around a financial entity’s ability to build, assure and review its own operational integrity. The verb “review” does the real work in that definition.

DORA does not ask you to be resilient. It asks you to keep checking that you are, and to keep records of the checking.

Who does DORA apply to?

Article 2(1) lists twenty-one categories of entity, points (a) through (u). Credit institutions, payment institutions, e-money institutions and investment firms are the obvious ones. The list continues through crypto-asset service providers, central counterparties, trading venues, fund managers, insurance and reinsurance undertakings, occupational pension institutions, credit rating agencies, crowdfunding service providers and securitisation repositories.

Article 2(2) then does something worth noticing: points (a) to (t) are collectively defined as “financial entities”, while point (u), ICT third-party service providers, sits in scope separately. Providers designated as critical come under a dedicated EU oversight regime, which means a cloud or software vendor serving the financial sector can face supervisory attention without being a financial firm at all.

Microenterprises get proportionate treatment. Several testing obligations in Chapter IV open with “financial entities, other than microenterprises”, and Article 25(3) lets microenterprises combine a risk-based approach with strategic planning of their testing instead.

Swiss institutions are not directly in scope. Swiss groups still meet DORA through their EU subsidiaries and branches, and Swiss vendors meet it through the third-party pillar the moment an EU financial entity depends on them. More on the Swiss position below.

What are the five pillars of DORA?

The DORA requirements fall into five blocks, usually called the five pillars:

• ICT risk management. A documented risk-management framework owned by the management body: identify, protect, detect, respond, recover, learn.
• ICT-related incident management and reporting. Classify incidents against common criteria and report major ones to the competent authority on fixed timelines.
• Digital operational resilience testing. Chapter IV, Articles 24 to 27. A standing testing programme, yearly tests on systems behind critical or important functions, and advanced threat-led testing for designated entities.
• ICT third-party risk management. Contract requirements, a register of all ICT service arrangements, concentration-risk analysis, and EU-level oversight of critical providers.
• Information sharing. A legal basis for financial entities to exchange cyber threat intelligence within trusted communities, voluntarily.

Four of the five are mostly governance work. They produce documents, registers and reporting lines, and a capable compliance function can drive them.

The testing pillar is different in kind. It requires something to happen to production-relevant systems on a schedule, and it produces findings that someone must fix and then prove fixed.

What does DORA require for resilience testing?

Article 24 sets the frame. Financial entities other than microenterprises must establish, maintain and review a sound and comprehensive digital operational resilience testing programme, as an integral part of the ICT risk-management framework. The purpose is stated plainly: assess preparedness, identify weaknesses and gaps, and implement corrective measures promptly.

The article then adds four conditions that decide whether a programme survives supervisory scrutiny:

• Range. The programme must include a range of assessments, tests, methodologies, practices and tools, applied as Articles 25 and 26 describe (Article 24(2)). A single annual pentest does not make a programme.
• Risk basis. Testing follows a risk-based approach that accounts for the evolving ICT risk picture and the criticality of the assets involved (Article 24(3)).
• Independence. Tests are undertaken by independent parties, internal or external; internal testers need conflict-of-interest safeguards (Article 24(4)).
• Remediation. Entities need procedures to prioritise, classify and remedy every issue a test reveals, and internal validation that weaknesses are fully addressed (Article 24(5)). Findings that sit unresolved in a report are their own compliance failure.

Then comes the sentence that drives most testing calendars in the EU financial sector. 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.

Not a sample. All of them, every year.

Article 25(1) says what counts as testing, and the list is broad: 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. The list is introduced with “such as”, so it is illustrative rather than exhaustive, but it makes one thing clear: DORA’s idea of testing goes well beyond an annual penetration test. Availability under load belongs in it just as much as exploitable code does.

One sharper rule sits in Article 25(2): central securities depositories and central counterparties must perform vulnerability assessments before any deployment or redeployment of applications, infrastructure components or ICT services supporting critical or important functions. For market infrastructure, testing gates the release process itself.

What is threat-led penetration testing under DORA?

Article 3(17) defines TLPT as a framework that mimics the tactics, techniques and procedures of real-life threat actors. In practice it is a supervised red-team exercise built on live threat intelligence, and DORA turns it from a voluntary maturity exercise into a legal obligation for part of the sector.

Article 26 sets the terms. Designated financial entities must carry out advanced testing by means of TLPT at least every three years, and the competent authority can adjust that frequency up or down based on the entity’s risk profile.

Supervisors decide who is in, based on impact-related factors, financial stability concerns and the entity’s ICT risk profile and maturity. TLPT is not a universal DORA requirement; it is targeted at the entities whose failure would matter most.

The test itself is deliberately uncomfortable. It must cover several or all critical or important functions and be performed on live production systems.

Where those functions run on outsourced ICT, the third-party providers are included in scope, with the financial entity keeping full responsibility; where direct participation would endanger service quality or confidentiality, pooled TLPT across several financial entities is the fallback. The regulatory standards for how these tests run were developed by the European Supervisory Authorities in accordance with TIBER-EU, the ECB-originated framework for threat-intelligence-based red teaming.

Article 27 governs who may test. Testers need demonstrated expertise in threat intelligence, penetration testing and red-team operations, certification or adherence to formal codes of conduct, independent assurance on their own risk management, and professional indemnity insurance.

Internal testers are allowed, but Article 27 requires the competent authority’s approval and an external threat intelligence provider, and Article 26(8) adds that external testers must be contracted every three tests. Significant credit institutions must use external testers exclusively.

After the test, the authority issues an attestation confirming it was performed in accordance with the requirements, which other EU supervisors then recognise. That detail says a lot about DORA’s mindset: the output of a test is a verifiable artifact that travels between regulators, not a private slide deck.

What evidence do regulators expect?

Read Articles 24 to 27 again with an auditor’s eye and a pattern appears. The programme must be documented. Findings must be classified and prioritised.

Remediation must be validated, not asserted. TLPT results come with a formal attestation precisely so that a second authority can rely on them without re-running the exercise.

So the practical question for a compliance officer is not “did we test?” but “can we prove what we tested, what we found, and what we fixed?” A screenshot of a monitoring dashboard answers none of that. It has no independent origin and no tamper protection, and it says nothing about how the test was run.

Evidence that stands up in a supervisory review is generated by the test itself, by a party with no stake in the result, in a form that cannot be quietly edited afterwards. That standard is worth applying to every vendor in your testing programme, whatever they test. Ask how their report proves the test happened as described, and what stops anyone from touching the numbers between the run and the filing.

Where does DDoS resilience testing fit into DORA compliance?

Availability is the resilience property that denial-of-service attacks target, and the exposure keeps growing. Cloudflare’s 2026 Threat Report, published in March 2026, counted 47.1 million DDoS attacks mitigated across its network in 2025, a 121 percent increase over the previous year. The same provider’s Q1 2025 DDoS threat report had already logged 20.5 million attacks blocked in a single quarter, a 358 percent increase year over year, with banking and financial services climbing its ranking of most-attacked sectors.

For a bank, the systems those attacks aim at are the ones Article 24(6) names: the e-banking portal, the payment gateway, the trading front end. Systems supporting critical or important functions, due for appropriate tests at least yearly.

Look back at the Article 25(1) list and the fit is direct. A controlled DDoS simulation against your own infrastructure is a scenario-based test, a performance test and an end-to-end test of the availability path, all at once. It answers the question none of the paper exercises can: does the defence stack you paid for actually hold when realistic attack traffic arrives?

Our guide on how to test your DDoS protection covers how to structure that first run, and our DDoS stress test explainer covers what a controlled run looks like in practice.

Obsidio runs exactly this class of test, built for the constraints regulated entities operate under. Domain ownership is verified by DNS TXT record before any traffic flows, so no simulation can ever touch infrastructure you do not control. Runs ramp up gradually and can be aborted live.

Traffic comes from 100,000+ globally distributed real devices rather than a handful of datacenter IPs, which is what makes the result meaningful: defences that key on source concentration behave very differently against one machine than against a realistic distributed pattern. Ten simulation types cover application-layer floods, slow attacks, connection exhaustion and protocol-specific vectors, so the yearly programme can rotate scenarios instead of repeating one.

The evidence side is where the DORA fit becomes concrete. Obsidio produces cryptographically attested, tamper-evident reports generated inside Trusted Execution Environments and mapped to DORA, FINMA and NIS2.

The report of a run is filing-grade: an independent, verifiable record of what was tested, when, at what intensity and with what outcome, which is precisely the shape of evidence Articles 24(5) and 24(6) assume. Retesting after remediation then closes the validation loop the regulation asks for.

Strength is proven, not promised. DORA turned that from a principle into a legal test: since 17 January 2025, the question a supervisor asks is not whether you believe your critical systems are resilient, but what evidence you can put on the table.

What about Swiss institutions?

Switzerland is not an EU member state, so DORA does not apply to Swiss entities directly. The Swiss regulator got there on its own track: FINMA’s Circular 2023/1 on operational risks and resilience for banks, in force since 1 January 2024, embeds the Basel Committee’s operational resilience principles, with transition periods for the resilience provisions running until the start of 2026. The supervisory expectation on both sides of the border now points the same way: identify critical functions, test the systems behind them, and evidence the results.

The EU’s NIS2 Directive (Directive (EU) 2022/2555) rounds out the picture. Member states had to transpose it by 17 October 2024, and it covers essential and important sectors well beyond finance. For financial entities, DORA takes precedence as the more specific regime, so a bank’s ICT risk and testing obligations run through DORA rather than NIS2, while group companies outside the financial perimeter can still be caught by NIS2 itself.

For a Swiss institution with EU operations, that is three regimes with one common denominator. A resilience test worth running should produce evidence portable across all of them, which is why Obsidio maps every attested report to FINMA, DORA and NIS2 at once rather than to a single framework.

How do you make a testing programme DORA-ready?

The sequencing follows from the articles themselves:

• Map your critical or important functions first. Article 24(6) is scoped to the systems supporting them, so the function map decides what must be tested at all.
• Inventory those systems, including the ones running at third parties.
• Build a yearly calendar that draws on the Article 25(1) range rather than repeating one test type, and put availability scenarios on it alongside vulnerability work.
• Route every finding into a tracked remediation process with validation at the end, because Article 24(5) treats an unremedied finding as an open obligation.
• Plan the TLPT cycle early if you are in the population your supervisor designates. Article 27 makes qualified testers a gating requirement, and the three-year clock needs tester contracts in place.

To put an authorized DDoS resilience test on that calendar, with evidence you can file rather than vouch for, see the Obsidio platform or get in touch with the team. Independent, neutral, verifiable: resilience you can prove.