DORA Resilience Testing: Where Exercises Fit and How TLPT Differs

Reviewed 10 September 2026.

Your organisation needs to plan resilience testing, and several very different services are being described as a DORA exercise. One offer is a facilitated discussion. Another provides a technical training environment. A third concerns threat-led penetration testing against live systems.

The first commissioning decision is to identify which question you need the work to answer. A scenario can help people practise and demonstrate selected capabilities, but the word “exercise” does not establish its regulatory purpose or scope.

This guide explains the testing distinction and proposes a practical way for a financial entity to brief exercise specialists. The scoping worksheets and examples are recommendations. They are not a finding of compliance for a particular entity or evidence that ObsidianCorps is a TLPT provider.

Place testing within the wider DORA programme

DORA has applied since 17 January 2025. It covers ICT risk management, incident management, resilience testing and ICT third-party risk, alongside arrangements for information sharing. In Luxembourg, responsibilities depend on the entity and its competent authority. The CSSF's DORA guidance provides current official context and links to the applicable standards.

Testing is therefore one part of a wider operational-resilience programme. A well-designed exercise can inform that programme, but it does not establish that governance, incident reporting, third-party arrangements and all other obligations have been fulfilled.

Before commissioning work, ask the people responsible for the programme to identify the applicable entity, functions and requirements. Do not assume that two organisations using the same technology have the same regulatory scope. The European Supervisory Authorities' DORA information is another official starting point for the regulation and its implementation material.

Distinguish general resilience testing from TLPT

Articles 24 and 25 concern the general digital operational resilience testing programme. Article 25 includes scenario-based tests among the available methods. Test selection needs to reflect the applicable requirements and risks, rather than treating every exercise format as interchangeable. DORA, Articles 24–25.

TLPT is a separate advanced regime under Article 26 for identified financial entities. It involves live production systems and specific requirements for scope, testers, execution and remediation. The detailed rules are set out in Delegated Regulation (EU) 2025/1190.

The distinction matters when comparing proposals. A range exercise can give participants a controlled technical environment for practising or demonstrating selected tasks. That does not make it a TLPT engagement. A cyber range exercise alone does not establish DORA compliance or satisfy TLPT requirements.

The ECB updated TIBER-EU to align with DORA TLPT in February 2025. It describes how authorities, entities, threat-intelligence providers and red-team testers work together through a controlled process. These references explain the regulatory context; they are not ObsidianCorps credentials.

Choose a test by the evidence you need

Scenario-based testing is broader than a tabletop session. Begin with the capability or dependency you want to examine, then select a method that can produce the relevant evidence.

The following comparison is an editorial recommendation for scoping discussions. It is not an official regulatory classification or a determination that a particular test satisfies an obligation.

An exercise may combine discussion and technical activity when its objectives justify both. Agree the handoffs and the evaluation limits rather than assuming that a combined format automatically creates stronger regulatory evidence.

Start the exercise brief with the operation

ObsidianCorps begins with a deep investigation of the customer's industry and operational context. For a financial exercise, apply that principle to the function being considered: what it does, which systems and parties support it, and what disruption would mean for the people making decisions.

An illustrative brief might concern a service interruption with uncertain cause. The technical team needs to investigate, an operational owner needs to assess a workaround, and a decision-maker needs to understand the consequence of restricting access. This is a hypothetical planning example, not an ObsidianCorps financial-sector engagement.

Identify which parts require implemented behaviour. If the objective concerns a technical recovery, participants need an appropriate environment and an observable result. If it concerns a decision based on a represented disruption, exercise material may provide the necessary context. Document that distinction in the brief.

Bring existing range constraints into the conversation early. Software availability, access conditions, participant roles and custom development affect what can be represented and how much preparation is needed.

Define objectives and evidence before the scenario

The following worksheet is a recommended commissioning aid. The financial entity's responsible team should assess how the proposed work relates to its testing programme.

Use the worksheet to expose assumptions. If a proposed scenario depends on a supplier action, decide whether the supplier participates or is represented. If a recovery step is described but not performed, record the limit. If the exercise team also builds the environment, discuss the independent review arrangements required for the actual testing purpose.

Plan what observers should capture

A useful exercise record connects observations to objectives. Recommend recording the information available to participants, their significant decisions, the reasoning expressed and the effects of technical actions that can actually be checked.

Keep assistance and exercise faults visible. A facilitator's clue may be appropriate for learning but changes what can be concluded about independent performance. A broken range component should not become evidence that a participant lacks a capability.

Consider practical defence alongside decisions. Did the team investigate accurately? Did it verify the effect of a change? Could it explain the operational trade-off? Our guide to cyber exercise evaluation beyond scores offers a proposed rubric, explicitly separate from any claim of regulatory acceptance.

Avoid asking a supplier for an “audit-ready” report without defining what that means for the engagement. Agree the intended audience, evidence needs, scope limitations and review responsibilities. A polished document cannot compensate for a test that did not observe the required behaviour.

Keep incident-reporting practice correctly scoped

An exercise can include a decision about escalation or a simulated notification. The applicable classification criteria, recipients and timing must come from the entity's current obligations and procedures. Do not reuse a generic GDPR or NIS2 deadline as a DORA rule.

The CSSF publishes the relevant DORA incident-management and reporting material, including links to the technical standards and Luxembourg reporting arrangements. Use those primary sources with the responsible risk or compliance team when preparing the scenario.

For the exercise itself, recommend specifying what participants must produce and what observers will evaluate. A discussion about a notification may reveal uncertainty about ownership. Drafting an example notice may reveal missing information. Neither activity alone proves that a real notification would be complete, timely or accepted.

Use the Luxembourg context without assuming designation

The BCL and CSSF announced an updated TIBER-LU implementation document in June 2025 following the DORA and TIBER-EU developments. An entity considering TLPT should use its relevant supervisory instructions and current official material to determine the next steps.

A content guide cannot decide an individual entity's designation or resolve its scope from a sector label. If the requirement is TLPT, treat it as the separate procurement and supervisory process it is. Do not substitute a training-range proposal because both services use scenarios or adversarial activity.

For organisations commissioning a broader exercise, keep the service request concrete. You may need industry investigation, story development, range architecture, technical scenarios, participant guidance or evaluation. State which responsibility is missing and how it must connect to the wider programme.

Turn findings into a defined next step

After an exercise, recommend separating participant learning points, operational process issues and limitations in the test environment. Assign an owner to consider each priority finding and decide whether the response is further practice, a process change or another form of testing.

Where a later exercise is used to examine improvement, keep the objective comparable and record changes in conditions. Do not infer improvement from attendance or a higher score without checking what produced it.

ObsidianCorps offers cyber range consultancy, exercise design and delivery. If you need specialist exercise support within a wider resilience-testing programme, tell us about the operational context, objectives and required scope. Contact us.