DORA Is Live: What Financial Firms Actually Have to Test Now

Since 17 January 2025, the question a European financial supervisor asks has changed. It is no longer "do you have security controls?" but "have you demonstrated that your critical service survives a real attack?" That shift — from attestation to evidence — is the whole point of DORA, Regulation (EU) 2022/2554 on digital operational resilience, and it reshapes how banks, fintechs, insurers and their technology suppliers plan, budget and sequence their security testing.

Who DORA actually reaches

DORA is a regulation, not a directive, which matters more than it sounds. A directive has to be transposed into national law, so each member state writes its own version and the clock runs differently everywhere. A regulation applies directly, in full, across the Union on the same date. There is no transposition gap to hide in.

Its scope covers essentially the entire European financial sector: credit institutions, payment and electronic money institutions, investment firms, fund administrators, insurers, crypto-asset service providers and market infrastructures. If you sit anywhere in that ecosystem, DORA is your problem.

Then there is the second ring, the one that is routinely underestimated: third-party ICT service providers. Hosting companies, cloud providers, core banking software vendors, payment processors, maintenance contractors. Even if you are not a financial entity yourself, you are inside DORA's blast radius.

For companies in Moldova, the practical route in is contractual rather than legislative. If you build or operate technology for an EU financial entity, your client is legally obliged to impose security requirements, audit rights and testing participation through the contract. The obligation reaches you through a signature, long before any local law catches up.

Note: DORA covers five areas — ICT risk management, incident reporting, digital resilience testing, third-party ICT risk, and threat intelligence sharing. Testing is only one pillar, but it is the one most teams are least prepared for.

The baseline testing programme

DORA requires a digital resilience testing programme applied at least annually to all ICT systems supporting critical or important functions. The important word is "programme." This is not one test you buy once and file away. It is a portfolio of activities that together give you coverage of different failure modes.

That portfolio includes vulnerability assessments, open-source scans, network security analyses, physical security assessments, questionnaires, source code reviews, compatibility testing, performance testing and penetration testing. Each of these finds different things. A vulnerability scan tells you a patch is missing; a penetration test tells you whether that missing patch is actually reachable and exploitable on the path to your payment engine. Auditors increasingly want both, plus the reasoning that connects them.

Two conditions cut across the entire programme and, in our experience, are where most organisations stumble first.

The first is independence. Testing must be performed by parties independent of the team that built the system — internal or external, but free of conflict of interest with the developers. A team testing its own code is not independent testing, no matter how rigorous the checklist.

The second is remediation discipline. Findings must enter a tracked remediation process, prioritised by risk to critical functions. A report with 200 findings and no owner, no deadline and no re-test is not evidence of resilience; it is evidence of a process that stops at the PDF.

TLPT: testing led by real threats

Above the baseline sits advanced testing for entities designated by competent authorities, selected on risk criteria and systemic importance. This is TLPT — threat-led penetration testing — and it is a different animal from the annual pentest most teams know.

TLPT runs at least once every three years, follows the European TIBER-EU framework, and diverges from a conventional penetration test in three fundamental ways.

First, it is built on real threat intelligence. A threat intelligence provider constructs the scenarios from the groups that are actually attacking your sector — their tooling, their tradecraft, their preferred initial access vectors. You are not testing against a generic attacker model; you are rehearsing against a specific adversary who has already been inside firms like yours.

Second, it executes against production systems, not a test environment. That is precisely why it carries strict governance and a tightly restricted control team inside the entity. A lab replica will not tell you whether your fraud detection trips when an attacker moves laterally through the real payment rail.

Third, it measures defence, not just offence. The blue team is not told the exercise is happening. The result includes how fast they detected the intrusion, how they responded, and where the signal existed but nobody looked.

A TLPT exercise typically runs for several months and closes with a replay phase: attackers and defenders walk the timeline together, minute by minute, to establish where telemetry was present and went unread. In practice, that replay produces more durable improvements than the vulnerability list ever does. Finding a hole is useful; discovering that your SIEM had the evidence for eleven days and no one acted on it is transformative.

Baseline versus TLPT: what changes

The two tiers are not interchangeable, and conflating them is a common planning error. The table below sets out the differences that determine scope, budget and sequencing.

The frequency column deserves emphasis. Annual baseline testing is mandatory for everyone in scope. TLPT is not — it applies only to designated entities, chosen on risk, size and systemic importance, principally institutions whose unavailability would threaten financial stability. If you have not been designated, you are not excused from testing; you are excused from the advanced tier only.

What to do before you attempt TLPT

A threat-led exercise on untested infrastructure produces a predictable and expensive report: the attackers reach critical functions quickly via mundane paths, and the genuinely useful conclusions drown in noise. The healthy order is the reverse of what urgency usually dictates. Close the obvious routes with classic testing first, then measure detection and response.

In practical terms, that sequence looks like this:

• Inventory your critical functions and the ICT systems that support them. Without this, the TLPT scope cannot be defined and the exercise will sprawl.
• Run classic external and internal penetration tests, and drive remediation all the way to re-test. A finding closed without a re-test is a finding you are guessing about.
• Maintain an ICT third-party register and ensure your contracts carry testing and audit clauses. If your critical function depends on a supplier who will not participate, that is a resilience gap, not a paperwork issue.
• Build real detection capability. If you have no centralised monitoring, TLPT will simply measure its absence — at considerable cost.

That last point is the one we see most often. Teams commission advanced testing expecting an attacker's-eye view of their perimeter, and receive instead a measurement of whether anyone was watching. If nobody was, the exercise has still done its job — but you have paid for an expensive way to learn something a monitoring gap assessment would have told you for a fraction of the cost.

Caution: TLPT is not a substitute for baseline testing, and it is not a first test. Running it on an untested estate burns budget on findings that routine penetration testing would have surfaced, and it wastes the scarce goodwill of the control team inside your organisation.

The supplier question, answered honestly

The question we hear most from technology vendors is whether DORA applies to them. The honest answer has two layers.

Directly, only if you are designated a critical ICT third-party service provider at European level — a small and specifically named group. Indirectly, almost certainly yes. The financial entity you serve is obliged to include security requirements, audit and access rights, resilience clauses and, for suppliers supporting critical functions, participation in resilience testing — including the client's TLPT exercises.

This means a Moldovan software house or hosting provider can find itself contractually required to support a TIBER-EU exercise run by a German bank, with no local statute compelling it. The leverage is commercial: refuse, and the contract does not renew.

Important: If you support a critical function for an EU financial entity, assume you will be asked to participate in testing. Negotiate the terms now — scope, notice periods, safe harbour and data handling — rather than during a live exercise under time pressure.

Timelines, cost and the case for sequencing

A complete TLPT exercise usually runs between three and six months, split across preparation, threat intelligence, the testing phase itself and closure with replay. Cost depends on the number of scenarios, the breadth of the perimeter and the involvement of external providers, and it sits significantly above a classic penetration test.

That price differential is exactly why sequencing matters. Every hour of remediation you complete before TLPT is an hour the red team spends on a genuinely hard problem rather than a default credential. The organisations that get the most from threat-led testing are the ones that treated it as the capstone of a mature programme, not the opening move.

There is a broader point here about what DORA is really asking. It does not demand that you be unbreachable — no serious regulator believes that is achievable. It demands that you know your critical functions, that you have tested them against realistic adversaries, that you can detect and respond when something gets through, and that you can prove all of it with tracked evidence. The firms that treat testing as a compliance artefact will pass audits and fail incidents. The firms that treat it as an operational capability will do the opposite, and they are the ones DORA was written for.