DORA

DORA applies to financial entities across the sector: credit institutions, payment and electronic money institutions, investment firms, insurers and intermediaries, trading venues, crypto-asset service providers, fund managers and others, plus the ICT third-party providers that serve them. Critical ICT third-party providers are supervised directly at European level, which is unusual and is one of the regulation’s more consequential features.

It is built on five pillars. ICT risk management, with an explicit governance duty on the management body. ICT-related incident management, including classification and reporting of major incidents to the competent authority. Digital operational resilience testing. ICT third-party risk management, including a contractual register and requirements on what agreements must contain. And information sharing arrangements between entities.

The testing pillar is the one that concerns an offensive security practice directly, and it has two levels. All entities in scope must run a testing programme proportionate to their risk, covering the usual range from vulnerability assessment through to scenario-based testing. On top of that, significant entities identified by their competent authorities must carry out advanced testing based on threat-led penetration testing at least every three years, on live production systems, covering critical functions.

That last requirement is what makes DORA different from every other European framework. It does not ask whether you test. It names the method, sets the cycle, requires it against production, and imposes requirements on who is allowed to perform it.

The most common failure is treating it as a compliance documentation project owned by risk, with the technology function contributing evidence. The regulation is about operational resilience, and the questions it asks are operational: can this critical function continue, how quickly is an incident detected and classified, what happens when a provider fails. Those are answered by exercises and by measurement, not by a policy register.

The second is the third-party register. Entities discover, usually late, that they cannot produce a complete inventory of ICT arrangements with the required detail, because contracts sit with different business units and some services were bought on a card. Assembling it is a genuine project and it is consistently underestimated.

The third is concentration risk, which the regulation is explicitly concerned with and which most entities have not measured. Several critical functions depending on the same provider, or on the same region of the same provider, is precisely the pattern the resilience requirements are aimed at.

The fourth is the testing itself. Threat-led testing on production, against critical functions, with a control group that knows and a defensive team that does not, is a serious undertaking. Entities that have only ever bought scoped penetration tests are frequently surprised by the governance around it: the threat intelligence phase, the involvement of the authority, the requirements on the testers, and the fact that it runs against live systems. Starting that conversation six weeks before the deadline does not work.

Entities often ask whether their existing testing satisfies the advanced requirement. Usually it does not, and the reasons are structural rather than about quality.

The practical consequence is sequencing. An entity that will be identified for advanced testing should not make that exercise its first experience of adversarial testing. The order that works is scoped penetration test work to fix the obvious, then detection engineering, then purple team exercises to verify detections, and only then a threat-led exercise, whose value depends entirely on there being a defence worth measuring.

Assuming it is only for large banks. The scope covers payment institutions, insurers, intermediaries, fund managers, crypto-asset service providers and more, and it reaches their ICT providers contractually.

Leaving the third-party register to last. It is the item that most often delays a programme.

Treating the testing requirement as a procurement line. It has governance, intelligence and authority involvement attached.

Ignoring concentration risk. Multiple critical functions on one provider is the exact scenario the regulation targets.

Running it separately from NIS2 work. The control substance overlaps heavily and the evidence is largely shared.

Confirm the entity’s status and whether it is likely to be identified for advanced testing, since that single question changes the size of the programme. Ask the competent authority rather than inferring.

Build the ICT third-party register properly, with the detail the regulation requires, and use it to measure concentration. That register is also what makes the contractual work tractable, since the required clauses have to be introduced at renewal and you need to know which contracts exist first.

Fix incident classification and reporting against the regulation’s own criteria, and rehearse it. The question that matters in an exercise is not whether the report can be written but whether the entity can classify an incident correctly while it is still ongoing.

Build the testing programme as a ladder rather than as a single annual event, and keep the evidence trail for each rung: what was tested, what was found, what was remediated, what the retest showed. That trail is what a supervisor reads.

And treat the resilience question directly: for each critical function, what is the tolerance for disruption, what happens when the primary provider is unavailable, and when was that last exercised. Those answers are the substance of the regulation, and they sit closer to incident response planning than to any control checklist.

For the testing pillar, the evidence is the exercise: its scope, the intelligence that shaped it, the rules of engagement, what was executed, what the defenders detected and when, what was found, and what changed afterwards. Reports are structured so that the detection and response narrative sits alongside the findings, since the regulation cares about both.

We are explicit about what we do and do not provide. We perform the technical exercise and produce the evidence. We do not determine regulatory scope, we do not decide whether an entity is identified for advanced testing, and we do not file with authorities. Where an entity needs a formally recognised threat-led engagement, the requirements on providers and on the process apply and should be confirmed with the competent authority before scoping.

Severity in these reports is written against the critical function affected, not against the technical asset, because that is the unit the regulation and the reader both work in.

The advanced testing requirement points directly at adversary emulation carried out against production and against a live defence, which is the only form of testing that answers the question the regulation is asking.

Who does DORA apply to? Financial entities across the sector, from credit institutions and payment providers to insurers, investment firms, fund managers and crypto-asset service providers, plus the ICT third-party providers serving them. Critical providers are supervised directly at European level.

Is DORA a directive or a regulation? A regulation, so it applies directly across member states without national transposition. That is a meaningful difference from NIS2, where the obligations reach you through national law.

How often does threat-led testing have to be done? Entities identified by their competent authorities must carry out advanced testing based on threat-led penetration testing at least every three years. Other entities still need a testing programme proportionate to their risk profile.

Does our annual penetration test satisfy DORA? It contributes to the general testing programme. It does not satisfy the advanced requirement, which is intelligence-led, runs against live production and critical functions, is not announced to defenders, and carries requirements on who performs it.