DORA threat-led penetration testing

DORA threat-led penetration testing: who it applies to and why it differs from a standard test

DORA threat-led penetration testing (TLPT) is a scenario-based test of live production systems that a competent authority can require from financial entities it identifies, under Article 26 of Regulation (EU) 2022/2554. The regulatory technical standards that govern how it is run are Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025 and aligned with the TIBER-EU framework. If your competent authority has notified you, or you expect to be identified, the first task is to read the notification and the delegated regulation together, then confirm with the authority which entity, which ICT services and which timeline apply to you. Do not assume that a large institution is in scope or that a smaller one is out, because identification is the authority's decision.

TLPT is not the annual testing that Article 24(6) requires. Article 24(6) asks financial entities other than microenterprises to test all ICT systems and applications supporting critical or important functions at least yearly, and that testing can be a conventional vulnerability assessment or penetration test scoped by the entity. TLPT, by contrast, is threat-led: the scenarios are built from threat intelligence about actors who are likely to target the entity, it covers live production systems and the functions that matter most to the business, and it is repeated on a cycle of at least every three years for identified entities. The test also depends on the people who defend the entity, so detection and response are part of what is measured. A standard test that checks whether known weaknesses exist in a defined scope will not answer the same question.

The risks TLPT is designed to examine include undetected paths from initial access to critical functions, weaknesses in detection and response that allow an intruder to operate without alerting the security operations team, and exposure through third-party ICT providers whose access or systems sit on the route to those functions. The test does not promise that any of these will be found or closed. What it gives a board and a supervisor is evidence of how a realistic threat would have moved through the environment, which is why the preparation work, including the threat intelligence and the agreed scope of critical functions, carries as much weight as the active testing itself. Confirm early with your authority and your testing provider how third-party ICT providers in scope will be engaged, because their participation is a planning decision, not a detail to settle later.

Which entities must run TLPT and how the designation works

DORA separates a general yearly testing duty from threat-led testing, which applies only to entities a competent authority identifies. The cards below walk through the decisions that determine whether your organization is in scope, what the test perimeter includes, and what to confirm in writing before planning begins.

Two different testing duties

Article 24(6) applies to all financial entities other than microenterprises and requires yearly testing of ICT systems and applications that support critical or important functions. Article 26 is narrower: threat-led penetration testing applies only to entities the competent authority identifies. Many firms will carry the yearly duty without ever receiving a TLPT designation, so do not treat the TLPT cycle as your baseline testing program.

Confirm designation in writing

Designation is made by your competent authority, not by self-assessment. Ask the authority to confirm your status in writing and record the date, the entity covered and any conditions attached. Confirm the designation criteria and any authority-specific process against the Article 26 text and the authority's own guidance rather than relying on secondhand summaries, because the process can differ between member states.

Map ICT third-party providers into the perimeter

Check early whether critical ICT third-party providers that support your critical or important functions fall within the test perimeter. Contracts, access arrangements and provider consent all take time to settle, so raise this with your providers and your authority before the scope is fixed. Do not assume a provider's own testing or certifications cover your TLPT obligation without confirming the scope and terms with the authority.

Plan around the three-year interval

Where TLPT applies, Article 26 requires testing at least every three years. Confirm with your authority when the current cycle started, how it counts the interval, and whether the authority expects testing in a particular year. Build the cycle into your plan for the yearly Article 24(6) testing so that the two programs share evidence and do not duplicate effort.

Check for group-level testing

Where a financial group has entities in several jurisdictions or several legal entities share ICT systems, ask whether the authority expects one group-level test, separate entity tests, or a mix. Identify which ICT systems and functions are shared, which entity owns each one, and how findings and remediation records will be attributed. Confirm the approach with each relevant authority, since group arrangements are handled through the authority's own process.

How a TLPT engagement runs under Delegated Regulation 2025/1190

The sequence moves from agreed scope and threat intelligence to live testing under controlled rules, then to defender-facing closure, reporting and remediation, so the financial entity and its competent authority can see what was tested, how, and what changed. Exact requirements for each phase sit in the regulation itself, so confirm them against the text before scoping.

Agree preparation and scope with the entity and authority
The financial entity, its competent authority and the test provider settle which critical or important functions, and the ICT systems and services that support them, fall within the test. The entity identifies its internal and external stakeholders and confirms who is accountable for the programme. Before work starts, the parties should check the scope, the required testing structure and the minimum content of each deliverable against the text of Delegated Regulation (EU) 2025/1190, and record the agreement in writing. The step is done when the scope and governance are signed off and the authority has been informed as its process requires.
Gather threat intelligence and tailor scenarios
The provider builds a threat landscape specific to the entity, drawing on sector and jurisdictional threat information, the entity's own risk assessment and the systems in scope. From this, the team designs test scenarios that describe realistic attacker objectives against live production services, rather than generic vulnerability checklists. The entity reviews the scenarios for business impact and for anything that could affect third parties or regulated services. The step closes when the scenario set is documented and approved, and the rules for how each scenario will be investigated are recorded.
Establish the test team and white team governance
The red team, which carries out the attack scenarios, is separated from a white team, which is the small group of entity staff and advisers who know the test exists and control it. The white team approves the testers, holds the authority to pause or stop activity, and keeps a confidential record of what was launched and when. Testers must meet the tester requirements in the regulation and the entity should confirm how their independence and qualifications are evidenced. The step is complete when roles, escalation paths and the stop mechanism have been tested in a dry run and documented.
Execute active testing under rules of engagement
Testers run the approved scenarios against live systems within the active testing window that the regulation sets, following written rules of engagement. These rules define permitted techniques, time windows, data handling, the conditions that trigger a pause, and how sensitive data and third-party services are protected. The white team monitors the activity and records key decisions in a log. The step ends when the active window closes or all planned scenarios are complete, and the provider has documented the attack paths attempted, the outcomes and any incidents caused during testing.
Close out testing with purple teaming
After active testing, red team and defenders, including the entity's security operations staff, review what was detected, what was missed and why. This purple teaming phase is collaborative and aims to improve detection and response, not to score individuals. Findings about monitoring coverage, alert handling and response playbooks are recorded alongside the technical results. The step is complete when the debrief has been held and the detection and response improvements are logged as actions for the entity to own.
Deliver reporting and remediation plan
The provider issues the test report and the supporting material that the regulation requires, covering the scenarios, the findings, the severity of each attack path and the evidence supporting each conclusion. Because the report may be shared with the competent authority, the entity should confirm which versions are restricted and how sensitive exploit details are handled. The entity then prepares a remediation plan that assigns owners and dates to each finding. The step closes when the report is accepted and the remediation plan is approved by the management body or its delegate.
Verify remediation and obtain attestation
The entity implements the remediation plan and the provider or a suitably independent party checks that the corrections address the findings. Where the regulation requires an attestation, the entity obtains it in the form and wording the text specifies, and confirms who may sign it. Retesting evidence and the attestation are retained as part of the records the authority may request. The step is complete when each finding is closed with evidence or formally accepted as a documented risk, and the attestation is on file.

What can be in TLPT scope and the scoping decisions to settle first

Scope for a DORA threat-led test is a set of linked decisions, not a single asset list. Each card below is a decision to settle and document in writing before any tester begins work, because the choices on one shape what the others can cover.

Critical or important functions in scope

Start from the financial entity's own identification of critical or important functions, not from the IT asset register. Under DORA Article 26, the test must reflect the functions that matter most to the entity and its customers, and the competent authority's view of which entities must test shapes who is in the first place. Ask which functions were chosen, who approved the choice, and how the risk assessment supports it. Do not promise a named function is in scope until the written scope says so.

Production systems and ICT services

Map each function to the production systems, applications, databases, identity services and infrastructure that support it, and note which are shared with other functions. TIBER-EU style scoping is risk and threat-led, so the list should come from threat scenarios and the entity's critical functions rather than from an asset inventory alone. Confirm which environments are live production and which are replicas or test stacks, because testers will act on what is in scope.

Third-party providers and their consent

Many critical functions depend on ICT third-party providers, including cloud hosting, managed security and software vendors. Identify which provider systems fall within the scenarios, and confirm whether each provider has agreed in writing to testing against its infrastructure. Some providers will only allow testing of the customer tenant or specific services under their own rules. Record each consent and its limits before work starts.

Off-limits systems and live data

Define what testers must not touch: safety-critical or payment settlement systems that cannot tolerate disruption, customer personal data beyond what the test needs, and production records that must not be altered or exported. Agree how any evidence of access will be captured without copying sensitive data, and who can halt activity if a system shows strain. These limits belong in the written scope and rules of engagement.

Rules of engagement for movement

Set the conditions under which testers may pivot between systems, escalate privileges, or move from an initial foothold into a deeper environment. Agree in advance which pivots are allowed, which require notification to the control team, and which stop the exercise. Name the contacts for real-time decisions and the procedure for stopping the test. Clear rules protect the entity and the provider and give the report a defensible account of what was done.

Written scope before work starts

Agree scope, deliverables, timelines, and the role of the entity's own control team in writing before testing begins. Confirm who signs off changes to scope during the engagement and how those changes are documented. Ask the provider how it will show that the scope matched the threat scenarios and critical functions selected, since that record will be examined by supervisors and internal auditors.

How TIBER-EU, DORA TLPT and Article 24(6) testing fit together

TIBER-EU is the European framework for threat intelligence-based ethical red teaming. The regulatory technical standards for DORA threat-led penetration testing are aligned with it, so the methods, roles and governance it describes shape how DORA TLPT is run. National authorities put TIBER-EU into practice, and how a given country runs these exercises, and which entities take part, is set by that authority. Read the Delegated Regulation (EU) 2025/1190 to see where the alignment shows up in the text.

Who it applies to: Entities that a national authority invites or designates to take part, typically within the financial sector. Participation is an authority decision.
How it runs: Scenarios are built from threat intelligence about the entity and its sector, and the exercise is run under controlled conditions against the entity's own systems.
Roles: The framework defines responsibilities for the entity's control group, the testers and the threat intelligence provider, so each party's duties are set before the test starts.
What it produces: Test reports, a remediation plan and a closing process that the authority oversees, including formal attestation at the end of the exercise.
Recognition: Whether a TIBER-EU exercise also satisfies a DORA TLPT obligation is a question for your competent authority.

Before you plan around an existing or proposed TIBER-EU exercise, ask your competent authority in writing whether it will be recognized for DORA and what evidence it will accept.

Which weakness categories threat-led scenarios expose

This table compares the weakness categories that threat-led scenarios tend to expose in a financial entity's critical functions, how each usually appears, and why it matters to the regulator and the board. Scenarios are built from threat intelligence about actors likely to target the entity, so the categories below are a starting point for scoping rather than a fixed checklist. Use the matching testing approach to judge whether a scenario is probing the right control.

Weakness category	How it tends to appear in critical functions	Why it matters to the regulator and board
Identity and privileged access	Standing administrator rights on payment or core banking platforms, service accounts with broad reach, and weak separation between administrative and everyday accounts.	Compromised privileged access can enable large-scale disruption of critical functions, which DORA's ICT risk management requirements expect entities to limit and monitor.
Corporate to production paths	Flat or loosely segmented networks where a foothold on an office or remote access system can reach production environments supporting critical services.	Segmentation weaknesses turn a single compromised user into an incident affecting critical or important functions, a concern boards must understand in their risk appetite.
Third-party and cloud management interfaces	Administrative consoles for cloud tenants, managed service providers and outsourced ICT services exposed to the internet or reachable with weak authentication.	DORA places third-party ICT risk under board oversight, so weaknesses in provider access paths are a governance matter as well as a technical one.
Detection and response gaps	Logging that does not cover critical systems, alerts without owners, and response playbooks that have not been exercised against realistic intrusion sequences.	Threat-led testing measures whether the entity's people and tools detect and respond, which supervisors assess alongside technical controls in the test report.
Change and patch handling on critical applications	Delayed patching of internet-facing or core applications, emergency changes that bypass review, and test environments that differ from production.	Known weaknesses left open on critical applications weaken the entity's claim to effective ICT risk management and make remediation tracking a board-level item.

Who may run the test and what to ask a provider before you sign

The exact criteria for who may run a threat-led penetration test under DORA sit in Commission Delegated Regulation (EU) 2025/1190, which sets the regulatory technical standards for TLPT, and in the TIBER-EU framework it is aligned with. Read both before you shortlist anyone. Those texts define the expectations on testers' skills, their independence, the insurance they must hold and how internal testers may be used alongside external ones. Your competent authority and the entity's own TLPT authority may also apply expectations on top of the text, so confirm with them early. Treat any provider's summary of these rules as a starting point, not as the criteria themselves.

Before you sign, ask the provider for concrete evidence of experience in threat-led testing, not general penetration testing. Ask which threat intelligence sources they use, who supplies and validates them, and how that intelligence is turned into scenarios that match your risk assessment. Ask how they manage independence and conflicts, including whether they also operate or remediate the systems being tested, and how they will document any conflict. Ask how they protect live production systems from disruption, who holds the authority to stop a test, and how emergency contact works. Ask what happens to the data they collect, where it is stored, who can access it, how long it is kept and how it is destroyed. Finally, ask for a delivery track record in regulated financial services, with references you can verify under confidentiality, and confirm the named testers' qualifications and insurance cover in writing. Put the answers into the statement of work so they are contractual, not verbal.

What drives the cost and duration of a TLPT

This table compares the main factors that move the price and calendar time of a DORA threat-led penetration test, and what each one means for your quote. Read each row as a question to settle in the written scope before work starts. The main takeaway is that the number of in-scope functions, live environments and third parties drives most of the effort, and that the scope document is what turns a request into a comparable quote.

Driver	Why it moves cost or duration	What to ask for in a quote
Critical or important functions in scope	Each function brings its own systems, owners, threat scenarios and evidence, so more functions mean more analysis and more testing time.	A list of functions with the ICT systems supporting each, and the rationale for their criticality.
Distinct live environments	Production, disaster recovery and separate regions or entities each need access arrangements and controlled testing, which adds setup and coordination.	The environments named explicitly, with which ones are production and which are test replicas.
Third-party providers whose consent and systems are needed	Cloud, hosting and outsourced service providers must agree to testing that touches their systems, and that agreement can add lead time and legal work.	Confirmation of which providers are involved, who obtains their consent, and how delays are handled in the timeline.
Threat intelligence and scenario development	Tailored threat intelligence and scenarios built from the entity's own risk profile take analyst time before any active testing begins.	Whether threat intelligence is included or supplied by the entity, the number of scenarios, and the sources used.
Depth of active testing	The number of attack paths, the breadth of techniques and the amount of manual work set how long the active phase runs within the 12 week window.	The planned attack paths per scenario, the testing team size and the hours assigned to each phase.
Purple teaming and debrief	Joint sessions with the entity's defenders, plus the time to replay activity and discuss detection gaps, add facilitation and reporting effort.	The number of purple teaming sessions, who attends, and whether the debrief is part of the fixed price.
Attestation and regulator-facing reporting	Preparing the report and the attestation that the competent authority expects, and translating results for supervisors, adds review and drafting work.	The report format, the attestation scope, the reviewers involved and the number of revision rounds included.
Retest of remediated findings	Verifying fixes after remediation is separate work that recurs whenever findings are re-opened, so it changes the total over time.	Whether one retest round is included, how retests are scheduled, and the cost of any further rounds.

What the entity receives and what goes to the authority

A threat-led test produces several outputs that reach different readers, from the executive team to the defenders and the supervisor. The entity owns each one, decides what it shares, and answers to its competent authority for what it submits. The cards below set out each output and what to check before it leaves the organization.

Test report and scenarios executed

The main report sets out the threat intelligence behind the scenarios, each scenario executed, the attack paths tested and every finding with its severity. For DORA, check that the report covers the live production systems in scope and the critical or important functions named in the test plan. Ask the provider to show how each finding maps to a scenario and to the controls it tested. The Delegated Regulation sets minimum report content, so confirm the required fields against the text before you agree a report template.

Purple teaming debrief for defenders

The purple teaming debrief goes to the people who ran monitoring, detection and response during the test. It records which actions the blue team detected, which went unnoticed, and where alerts or escalations broke down. Ask for it as a separate working document with timestamps tied to the scenario log, so each detection gap can be traced to a specific step. Keep it within the security operations and incident response teams, because it describes operational weaknesses in more detail than the executive summary needs.

Remediation plan with owners

Each accepted finding needs a remediation plan with a named owner, a target date and a stated fix. Group findings by root cause, so one identity or configuration fix does not hide inside a long list of separate items. Any finding the entity decides not to fix needs a risk acceptance signed by someone with authority to accept it. Critical findings should have documented mitigating actions in place while the permanent fix is built. The entity owns this plan, so draft it internally and use the provider to validate the technical fixes.

Retest results for corrected findings

Retesting confirms that corrected findings are closed and that the fix did not introduce a new weakness. Ask for a retest report that lists each finding, its original severity, the evidence of correction and the retest outcome. Scope the retest in writing before the remediation window closes, and carry any finding still open forward with an updated date. Confirm whether retesting is included in the fixed-scope quote or priced separately, since that changes what you can show the authority at the end of the cycle.

Attestation to the competent authority

The entity provides an attestation to its competent authority stating that the threat-led test was carried out as required. The attestation is the entity's own statement, approved through its governance, and DeployOpen does not issue it. The authority decides what supporting material it needs beyond the attestation, so confirm the form and content with your supervisory contact before drafting the package. Link the attestation to the report by reference, without repeating confidential detail, and check that it names the scope, the testers and the scenarios accurately. See the DORA text for the framework the attestation sits within.

Confidential report and shared summaries

A threat-led test report describes exploitable paths into live financial systems, so treat the full report as confidential and limit it to named recipients. Customers, auditors and insurers should receive a separate summary only if the entity agrees to share one. Build that summary from the executive section, with severity counts and retest status, and leave out system names, credentials and attack paths. Record who received each version and when. Ask the provider to produce the summary template within the engagement so every recipient receives a consistent account.

Questions buyers ask about DORA threat-led penetration testing

Must we run threat-led penetration testing or only the yearly test?

Not every financial entity must run TLPT. Article 24(6) of DORA requires financial entities other than microenterprises to test all ICT systems and applications supporting critical or important functions at least yearly. Threat-led penetration testing under Article 26 applies only to entities that their competent authority identifies, and where it applies, the test must take place at least every three years. Being subject to the yearly test does not tell you whether you are also identified for TLPT, so ask your competent authority for a written answer. Whatever the outcome, keep the yearly testing programme running. Read DORA in the EUR-Lex text before scoping any work, because the articles set the obligations that your scope must meet.

What does threat-led penetration testing cost and what drives it?

Cost depends on how much of the entity is in the exercise and how much work surrounds the live testing. The main components are threat intelligence and scenario design, which depend on your threat landscape; the number of critical or important functions and the ICT systems and third-party providers behind them; the testing team's time, including its qualifications; the effort your own staff spend managing the exercise; and reporting plus any retest of findings. The three-year TLPT cycle is the recurring element, alongside the yearly testing that continues between exercises. Ask any provider for a quote that breaks out each component, states its assumptions about in-scope systems and providers, and lists exclusions. DeployOpen prepares quotes from a written scope and does not publish a price list.

How long does DORA TLPT take and what must we confirm?

The overall timeline covers preparation, threat intelligence, scenario agreement, the active testing period, closure and reporting, and the active period is the element buyers most often underestimate. Confirm its length in Commission Delegated Regulation (EU) 2025/1190 and with your competent authority before you plan, because the regulation governs it. Also confirm whether the authority sets or approves dates, whether the exercise can run alongside your change freezes, which third-party ICT providers must agree in advance, and how much notice the testing team needs. Build these answers into the written scope so that the schedule, the staff time and the quote all rest on the same assumptions.

Can we run DORA TLPT in-house and what staff does it need?

Whether an internal team can carry out TLPT depends on the tester requirements in Delegated Regulation (EU) 2025/1190 and on how your competent authority applies them, including its view on qualifications and independence. Confirm this in writing before you build a team. Whoever runs the exercise, expect the regulation to call for defined roles. Typically a white team knows the exercise and controls it, a test manager coordinates the testers, the authority and business owners, and operational staff in incident response and service owners support the work. Those people need protected time for the exercise, so plan their availability early. DeployOpen runs red teaming and adversary simulation as fixed-scope work, but it does not issue attestations, which are a matter for the authority and the framework.

How does threat-led penetration testing differ from a standard pentest?

A standard penetration test checks a defined set of systems for weaknesses within an agreed window, and the report lists vulnerabilities and fixes. TLPT starts from threat intelligence about who is likely to target you and what they would want, then builds scenarios that testers attempt against live production systems. The aim is to test how your detection, response and the people and processes around them perform, not only whether a technical control can be bypassed. TLPT adds threat intelligence, scenario design, a control team that keeps the exercise safe, and reporting that the authority may review. Purple teaming, where testers and defenders work together to improve detection, can form part of the approach, so confirm how the regulation and your authority treat it.

How does TIBER-EU relate to DORA threat-led testing?

TIBER-EU is the European framework for threat intelligence-based red teaming, and Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025, is aligned with it. DORA sets the legal obligation for entities identified by their competent authority, and the delegated regulation sets the technical standards for how TLPT must be carried out. The TIBER-EU framework gives many of the concepts and steps that the regulation uses, so experience with it helps. The practical details, including how national authorities run their programmes, may differ, so check your national implementation and your authority's guidance before you design the exercise. Start with the delegated regulation on EUR-Lex.

What happens after threat-led penetration test findings are reported?

The reporting, remediation and attestation steps are governed by the regulation and by your competent authority, so confirm them before the exercise starts. Findings usually feed a remediation plan with owners, priorities and dates, and the regulation expects you to act on them and keep records of what you did. Plan for a retest of the critical findings within the agreed scope, and agree in writing who verifies closure. Attestation or confirmation that a test met the requirements is issued by the authority or the parties the regulation names, not by the testing provider. DeployOpen can support remediation planning and retesting as part of its security testing work, and retainers are available for continuous testing, with the scope confirmed in writing.

How DeployOpen scopes, tests, reports and retests

DeployOpen runs security testing as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. For DORA threat-led penetration testing, we work from the scope and threat intelligence the financial entity and its competent authority have agreed, and we document each step so the entity can show how the test was run.

How we scope

Confirm with the financial entity whether it has been identified for threat-led testing under Article 26 of DORA, and which competent authority applies.
Agree in writing which critical or important functions, ICT systems and live production services fall within the test and which are excluded.
Record the threat scenarios, tester roles, testing windows and risk controls that the entity and its authority approve before active testing starts.

How we build

Work through the phases of the TIBER-EU-aligned process in Delegated Regulation (EU) 2025/1190, including preparation, testing and closure.
Plan the active testing period with the entity so that the 12 week requirement and the agreed threat scenarios are met and recorded.
Keep an evidence log of scenario execution, detections and control responses so the entity can reconstruct what was tested and when.

How we hand over

Deliver a written report that explains the threat scenarios, attack paths tested, findings, and the entity's detection and response performance.
Provide remediation recommendations ranked by risk, with clear ownership suggestions for the entity's internal teams to act on.
Offer purple teaming debriefs where the entity wants its defenders to review each scenario with the testers after the active phase.

How we support

Support retesting of findings once the entity has remediated, so closure is supported by documented verification evidence.
Offer ongoing support and continuous testing as a retainer, aligned to the entity's next testing cycle and changes to its ICT estate.
Confirm with the entity and its competent authority which attestation or summary they expect at closure, since DeployOpen does not issue regulatory attestations.