2025/1190 TLPT RTS: DORA requirements and evidence

What DORA threat-led penetration testing requires under 2025/1190

If your compliance lead or CISO has just learned that your entity may be asked to run a threat-led penetration test (TLPT), the first question is whether you fall within scope at all. Delegated Regulation (EU) 2025/1190 sets out the rules that answer it, and then governs how the test is controlled, how its phases and deadlines run, and how the competent authority closes the loop. The authority decides first: under Article 2(2), TLPT authorities must require testing from listed entities unless their own assessment shows it is not justified, so the notification you receive is the trigger, not a self-assessment you can skip. Confirm with your authority which category your entity falls into and what the notification asks you to submit.

The risk the regulation addresses is narrow but serious. Routine penetration testing and vulnerability scanning check known weaknesses in defined systems, while a TLPT asks whether a realistic attacker, informed by current threat intelligence, could reach the functions whose disruption would hurt your customers or the market. Hard parts tend to cluster in four places: scheduling, since the timeline runs from the authority's notification through initiation information within 3 months and a management-approved scope specification within 6 months; threat intelligence depth, since scenarios must be built on intelligence specific to your entity; control team independence, since the team that manages the test must be kept separate from the people defending the systems; and remediation, since the red team, blue team and summary reports are followed by remediation plans that the entity must deliver.

The attestation under Article 26(7) is the only authority-issued document the Regulation provides for in this context, and it confirms that the test met the requirements. It is not a certification and it does not replace your own supervisory obligations. Before work starts, ask your internal audit function and any external testing provider to confirm in writing how they will evidence each deadline, how the control team's independence will be documented, and how remediation will be tracked to closure. Those documents are what the authority will read when it decides whether the test was complete.

Which entities must test under the TLPT RTS, and what decides scope

Article 2(2) of Delegated Regulation (EU) 2025/1190 names the categories of financial entity that a TLPT authority must require to test, subject to a justification check. The cards below cover who falls in those categories, where the authority has discretion, and which scoping choices change the size of the work.

Systemically important credit institutions

Article 2(2) points the TLPT authority toward credit institutions that are global systemically important institutions (G-SIIs) or other systemically important institutions (O-SIIs), and toward institutions that are members of one of those groups. Confirm the designation status of the legal entity and of each group member, because membership can bring a subsidiary into scope even when it is not designated on its own. Record the designation source and date in the scoping file.

Payment and e-money institution thresholds

Payment institutions and electronic money institutions fall in scope when they exceed the transaction or outstanding e-money thresholds in Article 2(2), measured over the two preceding years. Build the calculation from the transaction records for each year, not from a forecast, and keep the workings with the scoping decision. An institution that crosses a threshold in one year should check the test period again before it assumes it is outside scope.

Market infrastructures in scope

Central securities depositories and central counterparties are named in Article 2(2) as entities a TLPT authority must require to test, unless the authority's assessment finds testing is not justified. Market infrastructures often run shared ICT platforms for many participants, so the scope specification must state which production systems belong to the entity and which belong to its providers. Ask the authority early how it reads that boundary.

Authority discretion and the justification test

The requirement to test is not automatic for every named category. Article 2(2) lets the TLPT authority decide that testing is not justified after assessing the entity. Ask for the written reasoning behind any decision not to require testing, and keep the authority's correspondence in the compliance file. A decision that testing is not needed does not remove the entity's wider resilience testing duties under DORA.

Live production systems and critical functions

The scope specification, approved by the management body, sets which live production systems and critical or important functions the test covers. Choosing narrow scope can lower red team effort but may leave the authority dissatisfied, while broad scope raises cost and the number of parties who must agree to the test. Map each function to the systems, data and third parties that support it before drafting the specification, and confirm the approval route in the entity's own governance.

Intra-group and third-party ICT services

Shared group platforms and outsourced ICT services can sit inside the test boundary, which affects who must consent, who must be told, and whose staff may be targeted. Decide early whether a service is in scope, document the contract basis for testing it, and confirm the provider's cooperation terms. Article 16 also allows joint testing where entities share ICT systems or an intra-group provider, which can reduce duplicated effort across the group.

How cross-border TLPT works when several authorities are involved

When a threat-led test touches entities in more than one member state, the host authority has 20 working days after being informed of the test to decide how it will take part. It can follow the test as an observer or assign its own test manager. The clock starts when the authority is informed, so a group that has not already told each relevant authority about its planned test may find that the window has opened before its own preparation is ready. Confirm early, in writing, which authorities are expected to be notified, who receives the notification for each entity, and what each authority has asked to see in the scope specification before the test starts.

Joint testing is the preferred route where entities share ICT systems or rely on an intra-group provider, because one test can cover shared infrastructure and the authorities can cooperate on one set of findings instead of running parallel exercises. Article 16 favors joint testing where it reduces costs, so a group should check early whether its shared systems make a joint test feasible. Map which entities depend on the same platforms, hosting or identity services, and which of those dependencies sit with a single provider whose contract and cooperation terms must cover the test.

A group with entities in several member states needs a single coordinating owner who holds the test timetable across all of them, aligns the threat intelligence and scenarios with each entity's scope, and tracks each authority's response window separately. The control team lead, the test managers and the provider should agree how observers will be given access to the test plan, reports and evidence, and how questions from different authorities will be answered consistently. Ask each authority how it wants to receive the summary and remediation material, because the deadlines in the Regulation run from those reports and a mismatch in what each authority expects can delay closure for every entity in the group.

How to run a TLPT from notification to closure

This sequence takes an entity from the TLPT authority's notification to a closed test, with each phase producing a document the authority can review. Following the order keeps governance, scope approval and reporting deadlines aligned with Delegated Regulation (EU) 2025/1190.

Confirm the notification and calendar every deadline
The entity receives notice from its TLPT authority that it must test. Management confirms the notification, assigns an internal owner and maps every deadline in the RTS against the calendar, including the initiation information due within 3 months of notification and the scope specification due within 6 months. The output is a signed internal test plan with a deadline register that the management body has seen. The step is done when the authority has acknowledged receipt of the initiation information.
Appoint the control team lead and test managers
The entity sets up a control team to steer the test, led by a control team lead who coordinates decisions across the business and ICT functions. Test managers are named for the red, blue and replay and purple teaming tracks, and the entity confirms that the people and any external providers meet the tester requirements in the RTS. The output is a written appointment record with roles, reporting lines and independence checks. Confirm with the authority which roles it expects to see named in the initiation information.
Approve the scope specification through the management body
The control team drafts the scope specification, covering the critical or important functions, ICT systems, people and processes in scope, and the ICT third-party providers whose consent or involvement is needed. The management body formally approves the document before the deadline in the RTS. The output is a management-approved scope specification with a recorded decision and the provider involvement confirmed in writing. Keep the minutes, because the authority reviews them.
Select at least three threat-led scenarios
The control team lead selects at least three scenarios built from threat intelligence about the entity's sector and its own exposure. No more than one scenario may be non-threat-led, so the others must trace back to identified threat actors and their likely techniques. The output is a scenario set with the threat rationale recorded for each scenario, ready for the authority and the testers to review. Confirm that the rationale would stand up to challenge from a reviewer who did not write it.
Gather and document threat intelligence
The threat intelligence provider compiles tailored intelligence on the actors and techniques behind each selected scenario, covering the entity's sector, geography and technology footprint. The output is a threat intelligence report that the red team can use as the basis for its attack plans, with sources and confidence levels stated. Open-source tooling such as MISP or OpenCTI can organize indicators and STIX objects, but the entity should confirm that its provider documents its own collection and handling practices.
Run the active red team phase
The red team executes the approved scenarios against the in-scope live production systems for active testing of at least 12 weeks, with progress reported to the control team at least weekly. The entity's blue team does not know the timing or details in advance, so the control team manages deconfliction and safety rules without disclosing the attack path. The output is a weekly progress report for each week of active testing. The phase ends when active testing is complete, and the red team test report follows within 4 weeks.
Coordinate blue team response and replay and purple teaming
The blue team detects and responds to the red team activity as it would to a real intrusion, and its activity is recorded for assessment. After active testing, the red team and blue team run replay and purple teaming exercises that show which detections worked, which did not, and why. The output is a blue team test report and the replay and purple teaming records, both due within 10 weeks of the end of active testing. Confirm that the evidence logs on your detection stack, such as Wazuh or OpenSearch Security Analytics, can reproduce the timeline of each scenario.
Produce the summary report and remediation plan
Once the authority confirms that the red team and blue team reports are complete, the control team prepares the summary report and the remediation plan. Each is due within 8 weeks of that notification, and the remediation plan must address the weaknesses the test identified with owners and sequencing. The output is a management-approved summary report and remediation plan, which the authority reviews before issuing any attestation under Article 26(7). The step closes when the authority has accepted the summary and the entity has begun tracking remediation items to completion.

How an authority reviews a TLPT and what it checks first

This table compares what the TLPT authority and its test manager examine at each stage of a threat-led test under Delegated Regulation (EU) 2025/1190. Read it as a pre-test checklist: the first checks cover scope and independence, while later checks cover reports and remediation. The main takeaway is that weak scoping and unowned remediation plans cause most delays.

Review area	What the authority checks	Common finding to avoid
Scope specification and scenarios	Whether the scope specification, approved by the management body, covers critical functions and ICT systems, and whether at least three scenarios were selected with no more than one non-threat-led	Scenarios too narrow to test critical functions, or a non-threat-led scenario used as a substitute for threat-led ones
Control team and test managers	Independence of the control team from the testers, clear authority of the control team lead, and the qualifications and conduct of the test managers	Control team members who also run the red team, or unclear reporting lines between the entity and the provider
Testers and provider requirements	Evidence that the external provider and internal testers have appropriate skills, experience and safeguards for handling sensitive data	Vague tester credentials or no documented checks on the provider's competence and conduct
Threat intelligence quality	Whether the threat intelligence is tailored to the entity, sourced and documented, and used to shape the scenarios	Generic threat feeds with no link to the entity's sector, systems or observed threat actors
Weekly progress reporting	Evidence of at least weekly progress reports during the active red team phase of at least 12 weeks	Gaps in reporting, or reports that describe activity without recording decisions and risks
Red and blue team reports	Whether the red team report arrived within 4 weeks of active testing ending and the blue team report, with replay and purple teaming, within 10 weeks	Late reports, or blue team findings that do not compare detection and response against the red team's actions
Remediation plans	Whether the summary report and remediation plans, due within 8 weeks of the authority's notification, address each finding with priorities, owners and dates	Remediation plans without named owners, fixed dates or links to the findings they address
Attestation under Article 26(7)	Whether the authority is satisfied that the test met the requirements, which it records in an attestation	Assuming attestation follows from completing the test; it depends on the authority's review of the whole file

Which evidence shows a TLPT met the RTS

A threat-led penetration test under Delegated Regulation (EU) 2025/1190 is judged on its paper trail as much as on its findings. The artifacts below cover preparation, threat intelligence, testing, reporting and closure, and each one should be dated, versioned and traceable to the phase it supports.

Initiation information and scope specification

The entity submits TLPT initiation information within 3 months of the authority's notification, followed by a scope specification document approved by its management body within 6 months. Check that the management approval is recorded with a date and named approver, and that the scope lists the critical or important functions, ICT systems, providers and live production components the test covers. Ask whether each third party whose systems are in scope has agreed in writing to the test.

Threat intelligence report and sources

The threat intelligence provider's report should name each source, its collection method, the date range and the threat actors or scenarios it supports. Keep the raw indicators and the analyst's reasoning separate, so an assessor can trace each scenario back to an input. Open-source platforms such as MISP and OpenCTI can hold these records, but the report itself must be signed off and dated.

Scenario selection record

The control team lead must select at least three scenarios, with no more than one non-threat-led. Keep a record showing the candidate scenarios considered, the threat intelligence each one rests on, why each was accepted or rejected, and who approved the final set. An assessor will look for a clear link between the selected scenarios and the entity's own critical functions.

Weekly progress reports

Active red team testing must run for at least 12 weeks, with progress reported at least weekly. Each report should record the activities completed, access gained, detections triggered, blocked actions and any change to the test plan. Dated weekly reports are the strongest proof that the active phase ran as scheduled, so gaps in the sequence need an explanation.

Red and blue team test reports

The red team test report is due within 4 weeks after active testing ends, and the blue team test report within 10 weeks. The blue team report should document what the defenders detected, how they responded and where alerts were missed. Detection evidence from platforms such as Wazuh and OpenSearch Security Analytics (alerts, findings and correlation records) can support the blue team report. These records are inputs to the test, not proof that the RTS was met.

Replay and purple teaming records

Replay and purple teaming exercises must be recorded within the same 10-week window as the blue team report. Keep the replay logs, the detection rules tested, the before and after configurations and the agreed improvements. Each exercise should show which detections were tuned, who approved the change and whether it was retested.

Summary report and remediation plans

Once the authority confirms both reports are complete, the summary report and the remediation plans are each due within 8 weeks. The remediation plan should assign owners, dates and retest criteria for every finding, and the summary report should reflect those same findings. Confirm that the management body has reviewed both, and that the plan links each item to the ICT risk management framework.

What a TLPT costs in money and staff effort

This table breaks down the main cost components of a threat-led penetration test under Delegated Regulation (EU) 2025/1190, showing who is paid or who spends time, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a scope-based quote request, since no fixed prices are published here and the largest variables are scenario count, system count and cross-border coordination.

Cost component	Who bears it	One-time or recurring	What drives it and how to reduce it
External red team and testing provider	Entity pays the provider under a written engagement	One-time per test cycle	Scenario count (at least three under Article 10), active testing of at least 12 weeks, and attack surface size. Ask for a scope-based quote and confirm which phases are priced separately.
Control team and test manager time	Entity staff and any external test manager	Recurring across each cycle	Number of control team members and governance meetings. Keep a stable team and agree reporting cadence up front, including the weekly progress reports Article 11 requires.
Threat intelligence subscriptions or analyst time	Entity pays for feeds or analysts, or the provider supplies intelligence	Subscriptions are recurring; analyst work is one-time per test	Number of commercial feeds and depth of tailored intelligence. Self-hosted open-source platforms such as OpenCTI and MISP can remove platform licence spend, but analyst time to curate feeds stays.
Blue team effort	Entity security operations staff, plus any provider support	One-time per test, with ongoing monitoring afterwards	Detection coverage and log sources. Self-hosted detection tools such as Wazuh or OpenSearch Security Analytics can remove licence spend, while tuning rules and handling the blue team report under Article 12 still takes staff time.
Internal remediation effort	Entity system owners, engineering and change teams	Largely one-time per finding, with follow-up validation	Number and complexity of findings and the remediation plan required by Article 13. Fix recurring root causes once rather than patching each finding separately.
Authority and cross-border coordination	Entity staff, with authority time carried by the authority	Recurring for the duration of the test and reporting	Whether a host authority observes, assigns a test manager under Article 16, and how many jurisdictions are involved. Joint testing may reduce duplicated effort where entities share ICT systems or an intra-group provider.

Who owns each part of a TLPT: your team, a partner and the authority

The financial entity keeps accountability for the test. The management body approves the scope specification document, and the control team lead, who is appointed by the entity, directs the test from planning through closure. Owners of remediation, usually security, platform and application leads, turn findings into dated fixes and report progress back to the management body. None of this can be delegated away, even when external specialists do much of the technical work.

Management body: approves the scope specification document within the deadline set by the regulation and keeps oversight of the remediation plans.
Control team lead: selects the scenarios, coordinates the control team and keeps the test within its agreed rules of engagement.
Remediation owners: named individuals who take each finding, set a fix date and provide retest evidence.
Internal records: the threat intelligence inputs, system inventories and approvals that the authority will ask to see.

Before you engage anyone, confirm in writing which named people sit in each of these roles and how the control team lead will be kept independent from the red team.

Questions buyers ask about TLPT under DORA

Who must run a threat-led penetration test under DORA?

Entities that the competent TLPT authority selects must test, unless the authority's assessment shows testing is not justified. Under Article 2(2) of Delegated Regulation (EU) 2025/1190, the group covers credit institutions that are G-SIIs or O-SIIs or part of one, payment and electronic money institutions above the transaction or outstanding e-money thresholds in each of the two preceding years, central securities depositories, central counterparties, and certain trading venues and large insurers. Smaller firms are not in this group by default. Confirm your status with your national authority, because the selection is made by the authority rather than by the entity itself. Read the Delegated Regulation text on EUR-Lex for the exact wording of each category.

How long does the active red team testing phase last?

Active red team testing must run for at least 12 weeks under Article 11, with at least weekly progress reporting to the control team. The 12 weeks is a minimum, so the scenarios, the target scope and the number of attack paths agreed in the scope specification can extend it. The phase sits inside a longer sequence: the entity submits initiation information within 3 months of the authority's notification, a scope specification approved by the management body within 6 months, and then the red team, blue team and closure reports follow on the deadlines in Article 12. Ask your authority and your provider to show the full calendar, not only the active window.

Can a small team run a TLPT in-house?

The Regulation does not forbid in-house testing, but it sets roles that must be filled by people with the right independence and skills. The control team lead selects at least three scenarios, of which no more than one may be non-threat-led, and the test managers and testers must meet the provider requirements in the RTS. A small team can usually cover internal duties such as asset scoping, system owner access and remediation, while the red team and the independent elements are harder to staff from the same pool of people. Check with your authority whether internal resources are acceptable for each role before you commit, because that answer determines the staffing plan.

What can an external partner take over in a TLPT?

A partner can prepare systems and evidence, support scoping, run technical testing and produce the documentation the phases require, but the organization keeps ownership of the controls and of the decisions the RTS places with the entity and its management body. In practice, outside partners usually take on preparation of the scope specification, environment and asset mapping, threat intelligence collection work, red team execution where the provider rules allow it, and report drafting. The management body still approves the scope specification, and the entity still owns remediation. DeployOpen plans, implements and documents self-hosted platforms in the client's own environment and runs security testing, but it does not act as the authority, the attesting body or the independent assessor. Confirm each role in writing before work starts.

How does the TLPT attestation work?

The attestation is issued by the competent authority, not by the tester or the entity. Article 26(7) of DORA provides that the authority confirms the threat-led penetration test met the requirements, and that confirmation is the only authority-issued attestation the Regulation provides for in this area. Your tester can supply evidence that the test was run to the RTS, including the reports and the closure documentation, but the attestation depends on the authority's review. Ask your authority which documents it expects at closure and how long its review usually takes, since neither point is fixed by the supplied sources.

What does a TLPT need from management and IT teams?

A TLPT needs a named management body decision, a control team with clear authority, and IT teams that can provide system access, asset information and fast remediation support. The management body must approve the scope specification within 6 months of the authority's notification, so governance time is front-loaded. IT teams must map systems in scope, maintain change and incident contacts that the testers will be working around, and track remediation plans. The remediation plan is due within 8 weeks after the authority confirms both the red team and blue team reports are complete, under Article 13(1), so the remediation owners should be identified before the testing starts.

How does cross-border coordination change the effort?

Cross-border coordination adds steps, but joint testing can reduce duplicated work. Under Article 16, a host member state's TLPT authority has 20 working days from being informed to decide whether to follow the test as an observer or to assign a test manager. The RTS prefers joint testing where entities share ICT systems or an intra-group provider and it reduces costs. For a group with entities in several member states, expect more coordination meetings, more documentation and a longer lead time to agree the scope. Confirm early with your home authority which authorities will be involved and whether a joint test is available.

What drives the cost of a TLPT up or down?

The main cost drivers are the size and complexity of the in-scope environment, the number of scenarios and entities covered, the amount of threat intelligence work, and whether the test is joint or separate. Costs fall into one-time items such as scoping, test preparation and the first test cycle, and recurring items tied to later cycles and remediation. Ask any provider for a quote that separates the control team support, threat intelligence, red team execution, reporting and remediation support, and that states which items depend on your authority's decisions. DeployOpen does not publish prices and quotes follow from a written scope.

How DeployOpen prepares systems and evidence for a TLPT

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and runs security testing that can feed a threat-led test. The organization keeps ownership of its test, its control team decisions and its attestation requests, while DeployOpen prepares the systems, threat intelligence tooling and evidence that the test relies on.

How we scope

Agree in writing which entities, systems and ICT services fall inside the threat-led test scope before work starts.
Map which platforms in the client's own infrastructure will hold threat intelligence, detection logs and test records.
Confirm with the client which parts of the TLPT the client will run itself and which parts a provider will perform.

How we build

Deploy MISP, OpenCTI, Wazuh and OpenSearch Security Analytics inside the client's own cloud, data center or air-gapped network.
Configure sharing groups, feeds and detection rules so threat intelligence and blue team telemetry are traceable and retained.
Document configurations, access controls and data handling so the control team can evidence how each platform was set up.

How we hand over

Deliver configuration records, runbooks and evidence logs mapped to each phase of the test under Delegated Regulation (EU) 2025/1190.
Provide documentation the client can give its test manager, provider and competent authority when deadlines require it.
Walk the client's staff through the platforms so the organization can operate and explain them after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement ends.
Keep platform versions, rules and feeds current through a maintenance agreement agreed in writing.
Confirm with the client's auditor or assessor which evidence they expect, since DeployOpen does not issue test reports or attestations.

Delegated Regulation (EU) 2025/1190 TLPT RTS