Module 6: Digital Operational Resilience Testing and TLPT

Step 1 – Where Testing Fits in DORA’s Overall Architecture

Positioning Testing Within DORA

Regulatory context (as of December 2025)

• DORA (Regulation (EU) 2022/2554) entered into force in 2023 and applies from 17 January 2025.
• Testing requirements are mainly in Title II, Chapter IV (Articles 24–27) and Article 26 for TLPT, plus related RTS/ITS and ESAs guidelines.

You should connect this module with:

• Module 4 (Governance & ICT Risk Management Framework) – the management body must approve the digital operational resilience testing (DORT) programme and ensure resources and independence.
• Module 5 (Incident Management & Reporting) – testing should simulate, reveal, and help prevent the types of incidents that would later trigger DORA classification and reporting.

Core Idea

DORA moves the sector from ad‑hoc penetration tests and DR drills to a structured, risk‑based, and governance‑anchored testing programme that:

1. Covers the full ICT estate and critical business services.
2. Uses a graduated approach: baseline tests for all; Threat‑Led Penetration Testing (TLPT) for a subset of important entities.
3. Is tightly linked to remediation, lessons learned, and continuous improvement.

Keep in mind throughout: testing is not an audit formality; under DORA it is a continuous, intelligence‑driven learning loop that must be demonstrably effective when supervisors review it.

Step 2 – Baseline Testing Obligations Under DORA

2.1. The Digital Operational Resilience Testing Programme

Every in‑scope financial entity must maintain a risk‑based testing programme. At minimum, it must include:

• Vulnerability assessments and scans
• Regular automated scans of networks, systems, and applications.
• Coverage of known vulnerabilities (e.g., CVEs), misconfigurations, and missing patches.

• ICT security assessments
• Targeted tests on specific systems (e.g., secure configuration reviews, code reviews, security architecture reviews).
• Can include focused penetration tests, but not necessarily full TLPT.

• Scenario‑based tests
• Simulations of realistic disruption scenarios (e.g., ransomware outbreak, loss of a critical data centre, cloud outage).
• Cross‑functional: ICT + business + third‑party management + communications.

• Business Continuity Plan (BCP) and Disaster Recovery (DR) tests
• Regular BCP exercises: can staff work from alternate sites, invoke manual workarounds, maintain critical services?
• DR tests: failover to backup data centres, restoration from backups, RTO/RPO validation.

• End‑to‑end testing of critical or important functions
• Not just individual systems, but full service chains (e.g., customer payments from front‑end app through core banking to settlement and reporting).

2.2. Frequency and Depth

DORA does not prescribe a single frequency (e.g., “annual for all”), but expects:

• At least annual coverage of key ICT assets and critical services by some form of testing.
• Higher frequency and depth for:
• High‑risk systems and services (e.g., real‑time payment platforms).
• Systems with many external interfaces or high change velocity (DevOps environments).

In practice, supervisors expect a multi‑layered calendar: e.g., quarterly vuln scans, annual BCP/DR tests, annual or bi‑annual targeted pen tests, and periodic scenario exercises.

Your mental model: Baseline testing = broad coverage, relatively standardised techniques, and risk‑scaled frequency.

Step 3 – Worked Example: Baseline Testing Programme Design

Example: Mid‑Size EU Bank (No TLPT Obligation Yet)

Profile

• Medium retail bank operating in two Member States.
• Uses core banking on‑prem, cloud‑based CRM, and an outsourced payment processor.
• Not (yet) designated as a TLPT‑eligible entity by its competent authority.

Risk‑based testing design (illustrative)

1. Vulnerability Management

• External perimeter scans: monthly.
• Internal network scans: quarterly.
• Web app scans on internet‑facing apps: monthly, plus after major releases.

1. Penetration Testing (non‑TLPT)

• Internet‑facing apps and APIs: annual pen test; scope rotated to cover all major customer‑facing channels within a 2‑year cycle.
• Payment gateway integration: annual focused test on authentication and message integrity.

1. Scenario‑Based Exercises

• Ransomware on file servers: annual tabletop, every second year combined with a technical drill (e.g., simulate isolating segments).
• Cloud CRM outage: annual simulation with customer service, ICT, and vendor management.

1. BCP/DR Testing

• Data centre failover of core banking: annual live DR test during a low‑volume weekend.
• Backup restore test: quarterly restore of selected databases to a test environment.

1. End‑to‑End Critical Service Test

• Once per year, run an integrated test of the “card payment service”: from card transaction initiation to authorization, clearing, and posting to customer accounts, including failure scenarios.

1. Governance and Reporting

• Testing plan approved annually by the management body.
• Quarterly testing status report to the risk committee, highlighting uncovered assets, recurring findings, and overdue remediation.

This example illustrates how baseline testing can be structured, documented, and risk‑based, even without TLPT.

Step 4 – Advanced Layer: Understanding TLPT Under DORA

4.1. What is TLPT?

Threat‑Led Penetration Testing (TLPT) under DORA is a red‑team style test where:

• Threat scenarios are built on current threat intelligence (TTPs of real adversaries).
• Testers emulate sophisticated attackers against live production systems.
• The focus is on critical or important functions and their supporting ICT assets.
• The goal is to test the full kill chain: reconnaissance, initial access, lateral movement, privilege escalation, data exfiltration or service disruption, and detection/response.

DORA’s TLPT regime is conceptually similar to TIBER‑EU and some national frameworks (e.g., CBEST in the UK), but now harmonised across the EU for in‑scope financial entities.

4.2. Who Must Perform TLPT?

Not all entities must do TLPT. According to DORA and the Level 2 rules:

• Competent authorities (often the national supervisors) identify which entities are subject to TLPT, based on:
• Systemic importance.
• Criticality and complexity of services.
• ICT risk profile and substitutability.
• Typically, larger, more complex, or systemically important institutions (e.g., major banks, market infrastructures, large insurers) are selected.

Entities not explicitly designated for TLPT are still encouraged to adopt TLPT‑like techniques for high‑risk areas, but full DORA TLPT requirements (including regulator coordination) do not apply.

4.3. TLPT Cycle and Frequency

• TLPT must be conducted on a regular basis, generally every 3 years or more often if required by supervisors.
• The scope can be rotated across cycles, but each test must focus on critical or important functions.

Key contrast: Baseline tests are broad and recurrent; TLPT is deep, adversarial, and selective, involving regulators and external specialist providers.

Step 5 – Thought Exercise: TLPT Eligibility and Scope

Exercise: Would TLPT Apply, and How Would You Scope It?

You are given three entities:

1. Entity A – A large pan‑EU bank with significant cross‑border payments and securities services, designated as an “other systemically important institution (O‑SII)” by its national authority.
2. Entity B – A small payment institution operating only domestically, with limited volumes and simple infrastructure.
3. Entity C – A major cloud service provider that has been designated as a critical ICT third‑party provider under DORA.

Reflect on the following questions before reading the hints:

1. Eligibility: Which of these is most likely to be subject to mandatory TLPT as a financial entity under DORA? Why?
2. Scope drivers: For the entity you selected, which critical or important functions would you prioritise for TLPT?
3. Third‑party angle: How might the status of Entity C as a critical ICT third‑party influence the TLPT design for Entity A or B?

---

Hints (unfold mentally, do not just skim):

• Eligibility: DORA’s TLPT applies to financial entities, not directly to ICT third‑party providers (though they may be involved as part of the test).
• Scope: Think of functions whose disruption would have systemic impact (e.g., TARGET2‑linked payments, central securities depository links).
• Third‑party: Consider how contracts and cooperation obligations enable testing through or with critical providers, without jeopardising their other clients.

Try to write down a 2–3 sentence justification for your chosen scope before moving on.

Step 6 – Governance, Independence, and Use of External Testers

6.1. Governance Expectations

Under DORA, the management body must:

• Approve the overall testing strategy, including TLPT where applicable.
• Ensure independence of testers from the systems and processes being tested.
• Oversee risk management of the tests themselves (e.g., avoiding undue disruption of live services).

Key governance artefacts:

• Testing policy: principles, risk appetite for testing, independence rules, approval thresholds.
• Annual/rolling testing plan: schedule, scope, resources, dependencies.
• Reporting templates: standard formats for findings, severity, remediation deadlines.

6.2. Independence and Segregation of Duties

• Testing teams (internal or external) must be operationally independent from system owners and developers.
• In TLPT, blue team (defenders) should not know specific attack paths in advance, to preserve realism.

6.3. External Testers and Accreditation

For TLPT in particular:

• Entities must use qualified external providers that meet criteria set by ESAs and/or national authorities (experience, certifications, methodologies, ethical and legal safeguards).
• In many Member States, TLPT providers are pre‑approved or registered by supervisors.

Key contractual elements with external testers:

• Scope and rules of engagement (RoE): time windows, systems excluded, maximum tolerated impact, communication channels.
• Confidentiality and data protection: handling of sensitive data, logs, and evidence.
• Liability and incident handling: what happens if a test accidentally causes an outage?
• Obligation to cooperate with supervisors: sharing test plans and reports where required.

6.4. Coordination with Regulators

• For TLPT, entities typically must notify and coordinate with their competent authority in advance.
• Supervisors may:
• Approve or adjust the test scope.
• Observe parts of the test or debrief.
• Receive sanitised or full reports, depending on national implementation.

This coordination is crucial: TLPT is not just a security exercise, but a supervisory tool.

Step 7 – Quick Check: Baseline vs TLPT

Test your understanding of the difference between baseline testing and TLPT under DORA.

Step 8 – Designing a Risk‑Based Testing Strategy (Step‑by‑Step)

8.1. Step‑By‑Step Strategy Design

Below is a structured approach you can apply in exam scenarios or real‑world design tasks.

Step 1 – Map Critical and Important Functions (CIFs)

• Use your ICT risk register and business process maps from Module 4.
• Identify services whose disruption would cause material impact on customers, markets, or the entity’s safety and soundness.

Step 2 – Map Supporting ICT Assets and Dependencies

• For each CIF, map: applications, databases, networks, identity services, and third‑party providers (including cloud and data centres).
• Capture single points of failure and cross‑entity dependencies (e.g., market infrastructures).

Step 3 – Assess ICT Risk and Control Maturity

• Rate each CIF and its supporting stack on likelihood × impact and control strength (e.g., patching maturity, monitoring, segmentation).
• Higher risk + lower control maturity → more intensive testing.

Step 4 – Allocate Testing Techniques to Each CIF

For each CIF, decide on a mix of:

• Vulnerability scanning (how often? internal/external?).
• Targeted penetration testing.
• Scenario‑based exercises (technical and organisational).
• BCP/DR tests (including failover and restore).
• TLPT (if entity is in scope) or TLPT‑like red teaming.

Step 5 – Build a Multi‑Year Testing Roadmap

• Ensure that all CIFs receive adequate coverage annually, but deep tests (e.g., TLPT) are staggered over a 3‑year horizon.
• Align with change projects (e.g., major system migrations → pre‑ and post‑go‑live testing).

Step 6 – Integrate with Incident Management (Module 5)

• Use incident data and near misses to update test scenarios (e.g., if phishing incidents rise, increase social‑engineering components).
• After major incidents, run post‑incident scenario tests to validate improved controls.

Step 7 – Formalise Governance and Reporting

• Define KPIs/KRIs: test coverage %, average remediation time, repeat findings, detection rate in TLPT.
• Establish a testing steering group (CISO, CIO, business, risk, internal audit) to review progress and approve adjustments.

This structured approach is what DORA expects in practice when it refers to a “comprehensive, risk‑based testing programme”.

Step 9 – Apply the Framework: Mini Design Challenge

Scenario: Designing Tests for a Critical Payment Service

You are the ICT risk manager of a bank whose instant payment service has been classified as a critical or important function. The service relies on:

• A mobile banking app and API gateway.
• A real‑time payment engine hosted on‑prem.
• Connectivity to an EU‑wide instant payment scheme.
• An external cloud‑based fraud detection engine.

Task (take 3–4 minutes):

1. Risk drivers: List three key ICT risks for this service (e.g., availability, integrity, confidentiality, third‑party).
2. Testing mix: For each risk, propose at least one testing technique (baseline or TLPT) that would meaningfully address it.
3. Prioritisation: If you had a limited budget, which two tests would you prioritise in Year 1, and why?

Try to write your answers in bullet points. Then compare with the indicative solution below.

---

Indicative solution (high‑level, not exhaustive):

• Risk 1 – Service unavailability due to payment engine failure or connectivity loss
• Tests: DR failover test for the payment engine; network failover simulations; scheme disconnection scenario exercise.

• Risk 2 – Compromise of mobile app or API leading to fraudulent payments
• Tests: web/mobile/API penetration testing; secure code review; TLPT scenario focusing on account takeover and lateral movement into payment systems.

• Risk 3 – Dependency on external fraud engine (third‑party risk)
• Tests: scenario‑based exercise simulating fraud engine outage; review of provider’s own testing evidence; contract‑enabled joint test of failover arrangements.

Year 1 priority examples:

• End‑to‑end DR/BCP test for instant payments (validates availability).
• Deep penetration test or TLPT scenario on mobile/API and payment engine (validates integrity and detection).

Step 10 – From Findings to Remediation and Continuous Improvement

10.1. Closing the Loop

DORA places strong emphasis on using test results to improve resilience, not just producing reports.

Required practices include:

• Structured findings management
• Classify findings by severity, likelihood, and potential business impact.
• Assign clear owners and deadlines for remediation.
• Track progress in a central tool (e.g., GRC platform), with regular status reporting.

• Risk acceptance vs remediation
• For high‑severity findings, risk acceptance must be an exception, justified and approved at an appropriate level (often the management body or its committee).
• DORA supervisors will challenge entities that repeatedly accept the same critical risks.

• Lessons learned and control enhancement
• After each major test (especially TLPT), run a lessons‑learned workshop with ICT, business, and risk.
• Update policies, procedures, monitoring rules, and training based on test outcomes.

10.2. Metrics and Evidence for Supervisors

To demonstrate compliance and maturity, entities should maintain:

• Test inventory: what was tested, when, by whom, and with what methodology.
• Coverage metrics: % of CIFs covered by at least one major test per year; % of critical assets tested in the last 12–24 months.
• Remediation metrics: average time to fix high‑severity findings; % of overdue actions; recurrence rate of similar issues.
• Effectiveness metrics: detection rate during TLPT (how many attack steps were detected in real time), mean time to respond during exercises.

Supervisors increasingly look not just at whether tests occurred, but at whether resilience measurably improved as a result.

Step 11 – Key Term Flashcards

Flip the cards (mentally or with a partner) to reinforce core terminology from this module.