Process and remediation - TLPT step by step

How does a TLPT run step by step? A threat-led penetration test is a sequence in which a financial entity forms a control team, assesses the risk of testing production systems, commissions external threat intelligence, undergoes at least 12 weeks of active red teaming, then replays the attack with its defensive team, reports to the TLPT authority and implements a remediation plan. This article covers what to do at each stage from the organisation’s side – who is in scope and the deadlines are explained in TLPT under DORA – how to start, and provider selection in How to choose a TLPT provider.

Canonical definition: A TLPT remediation plan is the document required by Article 26(6) of DORA and Article 13 of RTS 2025/1190 in which a financial entity describes, for every finding, the shortcomings, prioritised remediation measures, root causes, responsible functions and the risk of non-implementation.

TLPT step by step – key takeaways:

The control team should be as small as possible (Recital 10 of the RTS), with test information shared strictly on a need-to-know basis under a code name (Article 4).
The test risk assessment covers six categories under Article 5(2), including financial-stability impact and the risk of incomplete system recovery.
The threat intelligence report must contain at least 3 scenarios – one each for availability, integrity and confidentiality (Annex III).
After the active phase, testers have 4 weeks for the red-team report, the blue team 10 weeks for its report and the replay, and the entity 8 weeks for the test summary and remediation plan.
Detection by the blue team does not end the test – Article 11(9) requires measures to continue while preserving confidentiality.
Patronusec supports clients across the full cycle: from reviewing the scope specification, through the TI and red-team phases, to the replay, purple teaming and a remediation plan drafted for the authority’s review.

How do you organise the control team and keep the TLPT confidential?

You build the control team around a lead with a board mandate, 3-6 members from security, IT, risk and legal, and nobody with blue-team duties. Article 4 of RTS 2025/1190 requires test knowledge to be restricted to the control team, the management body, TLPT providers and the authority, a procedure to halt incident escalation on detection, and consistent use of a code name.

Article 9(4) of RTS 2025/1190 lists the control team’s tasks: communication channels, reporting progress and risk to the board, substantive decisions during the test, provider selection and drafting the scope specification. The lead owns day-to-day management and decisions (Article 4(1)), including suspension (Article 11(10)).

Four rules that decide confidentiality in practice:

Composition – Recital 10: as small as possible, with deep knowledge of the entity and board access. Typically: the CISO or deputy as lead, an IT architect, operational risk, legal, and the owner of ICT provider relationships.
Exclusions – nobody from the SOC, incident response, infrastructure administration or the service desk. Article 4(2)(b) requires consultation with the test managers before involving any blue-team member.
Channels – encrypted email, a data room and a messenger outside SOC-monitored infrastructure (Annex I requires them in the project charter).
Code name – constructed so that a third party cannot recognise a TLPT (Recital 9); used in calendars, invoices and procurement documents.

The control team in a TLPT is the team of the financial entity’s staff that manages the test and, under Article 4(2)(c) of RTS 2025/1190, must be informed of any detection and, where necessary, halt the escalation of incident response.

The hardest point is the escalation-halt procedure. If the SOC reports an incident under the DORA process (Articles 17-19) and that incident is the testers’ activity, the control team must stop it before it reaches the authority as a major ICT incident – without revealing the test. That requires a pre-agreed mechanism, for example a clause in the incident procedure allowing the control team lead to hold external reporting for a defined window on a generically worded ground.

Patronusec Insight: In our project experience, entities most often leak the test not through the SOC but through supporting processes: procurement asks the security team about the red-team vendor, HR sees an NDA for an external firm, finance sees an invoice described as “security testing”. The fix is a code name used consistently from the request for proposals onward, a generic description of the contract subject, and document flow limited to the control team lead. Patronusec prepares the procurement and contract pack for the control team under the code name, so the test is not identifiable in document management systems.

How do you assess the risk of a TLPT on production systems?

The control team performs the test risk assessment during preparation across the six categories of Article 5(2): provider access to sensitive information, non-compliance leading to no attestation, incident escalation, red-team actions, blue-team actions and incomplete system recovery. The assessment is discussed with the test managers before the testing phase and reviewed throughout.

Risk category (RTS Art. 5(2))	Example	Typical mitigation
(a) provider access to sensitive information	the TI provider obtains leaked employee credentials	NDA, encrypted data room, least-privilege access, post-test deletion (Art. 7(1)(g))
(b) non-compliance with DORA/RTS and no attestation	breach of confidentiality, unethical tester conduct	contract clauses, ethical boundaries in the test plan, test manager oversight
(c) escalation of crises and incidents	the SOC reports red-team activity as a major incident	escalation-halt procedure, control team lead on call
(d) red-team actions	an exploit destabilises a production system	lab testing of exploits, time windows, kill switches, no denial-of-service
(e) blue-team actions	the blue team isolates a network segment in response to the “attack”	monitoring of response, control team right to intervene with test manager consent
(f) incomplete system recovery	backdoors left behind, altered configurations	recovery procedures of Art. 7(1)(h), change log, post-test verification

Article 5(1) adds a sectoral dimension: the control team assesses the potential impact of the test on the financial sector and on financial stability at national and EU level – for instance where a settlement system used by other institutions is in scope. Recital 11 allows the management body itself to approve the risk measures.

A TLPT risk assessment must, under Article 5(1) of RTS 2025/1190, consider the potential impact of testing live production systems on the financial sector and on financial stability at Union or national level.

In practice, the test risk assessment is a separate document, not a section of the ICT risk register. A sound methodological basis is ISO 27001 risk assessment – with the difference that here the threat is the test itself, not an attacker.

What must the threat intelligence report contain, and how do you select TLPT scenarios?

The targeted threat intelligence (TTI) report must, under Annex III of the RTS, include the research scope, an assessment of available data on the entity (credentials, look-alike domains, dark web), the geopolitical and economic context, threat actor profiles and at least three scenarios – one each for availability, integrity and confidentiality. The control team lead selects scenarios under Article 10(3), and the authority approves them.

Six mandatory elements of the TTI report:

Research scope – functions in scope, locations, language, ICT providers, collection period.
Assessment of actionable data – employee identifiers and passwords from leaks, domains resembling official ones, vulnerable technologies, information published by staff, dark-web listings, physical access information.
Threat analysis – geopolitical and economic environment, technology trends in the sector.
Threat profiles – specific groups or classes of actors, their motivation, intent and likely modus operandi against the entity.
Scenarios – at least three full attack paths for the highest-criticality profiles.
Forward-looking scenario (optional) – under Article 10(4), at most one scenario may address a future, not yet observed threat.

The control team lead’s selection criteria (Article 10(3)): the TI provider’s recommendation, input from the test managers, feasibility in the testers’ expert view, and the entity’s size, complexity and risk profile. Scenarios must differ in actors and TTPs and cover every function in scope (Article 10(2)). In pooled or joint tests, at least one scenario must target the ICT provider’s systems.

Under Annex III of RTS 2025/1190, the targeted threat intelligence report contains at least three scenarios: one involving loss of service availability, one involving a breach of data integrity and one involving a breach of information confidentiality.

The TI phase usually takes around 4 weeks (Recital 18). The control team, testers and test managers give feedback on the draft report – the moment for the control team to flag a scenario as unrealistic for its architecture, but not to soften one for convenience.

Have a draft scope specification or TTI report and want to know whether it will pass the test manager’s review?

Patronusec reviews TLPT preparation documents against Annexes II and III of RTS 2025/1190: within 5 working days you receive a written completeness assessment, a list of items to add, and a recommendation on matching scenarios to the functions in scope.

Request a TLPT documentation review

How does the red-team phase run – flags, leg-ups and weekly reporting?

The red-team phase starts with a test plan aligned to Annex IV of the RTS, approved by the control team and the authority, followed by at least 12 weeks of active testing split into entry, through and exit stages. Testers pursue flags, report progress weekly, and the control team provides planned leg-ups when an attack path stalls.

The red-team test plan (Annex IV) contains: communication channels, permitted and prohibited TTPs with ethical boundaries for social engineering, risk management measures, a description of each scenario (actor, motivation, functions, security attributes, flags), expected attack paths with preconditions and leg-ups, a schedule split into three stages, and specific features of the infrastructure.

The three stages of the active phase under Annex IV(f):

Stage	Testers’ objective	Typical TTPs (Recital 21)	What the control team watches
Entry	gain an initial foothold	reconnaissance, weaponisation, phishing, exploitation of external vulnerabilities, physical access	whether the blue team detected attempts; whether an information leg-up is needed
Through	lateral movement to systems supporting in-scope functions	privilege escalation, control and movement, abuse of privileged access	time to detection, blue-team reactions, production risk
Exit	actions on objectives – capturing flags and controlled withdrawal	access to target data, simulated exfiltration, tool removal	which flags were captured; whether the initial state was restored

Flags are key objectives within the systems supporting in-scope functions (Article 1(14)) – for example reading data from the general ledger, changing a parameter in the payment system under controlled conditions, or reaching an administrative console. Each flag is tagged with an attribute: confidentiality, integrity, availability or authenticity.

Leg-ups (Article 1(12), Article 11(8)) are information or access the control team gives testers when they cannot progress and no reasonable alternative exists. They must be designed in the test plan and documented in the report; overuse devalues the test, while their absence can waste 12 weeks on one blocked stage.

Under Article 11(7) of RTS 2025/1190, testers report progress to the control team and the test managers at least once a week throughout the active red-team testing phase.

Patronusec Insight: The weekly progress report is a decision tool for the control team lead, not a formality. In our project experience, a fixed format pays off: status of each scenario against the schedule, TTPs used and planned, attempts detected by the blue team (from the testers’ perspective), risks raised that week, and decisions required from the control team. Patronusec runs weekly reporting in a MITRE ATT&CK-mapped format, so after the test the same reports become the skeleton of the Annex V red-team report – without reconstructing history from notes.

What do you do when the blue team detects the testers or the test threatens production?

Detection triggers Article 11(9): the control team, in consultation with the testers, proposes measures to the test managers that allow the test to continue while preserving confidentiality. A threat to production triggers Article 11(10): the control team lead may suspend the test or – as a last resort, with the authority’s approval – move to limited purple-teaming activities. Neither situation invalidates the test.

Detection scenario – sequence of actions:

Testers report suspected detection (their duty under Article 7(1)(h)(vi) – monitoring the blue team).
The control team establishes what the blue team sees and whether the incident procedure has started.
The control team lead halts external escalation (Article 4(2)(c)) if the incident is heading for a regulatory report.
The control team proposes continuation measures to the test managers: new C2 infrastructure, a scenario change, an access leg-up bypassing the detected vector, or limited disclosure to one blue-team member (with test manager consent, Article 4(2)(b)).
The detection and the response go into the red-team and blue-team reports as one of the test’s most valuable results.

Production threat scenario – options under Article 11(10):

Suspension – the lead halts tester activity until the risk is removed; suspension time does not automatically count towards the 12 weeks, so the schedule needs an update approved by the test managers (Article 11(6)).
Limited purple teaming – with the authority’s prior approval: “catch and release” (testers allow detection and resume), war games, or joint proof of concept (Recital 23). This time counts towards the 12-week minimum.

Under Article 11(9) of RTS 2025/1190, detection of the test by the financial entity’s staff does not end the TLPT – the control team submits to the test managers for approval measures that allow the test to continue while preserving its confidentiality.

In practice, procedures for both scenarios should be ready before the active phase starts and described in the test plan (Annex IV(c)). The worst case is improvisation on a Friday evening when the SOC escalates an incident and the control team lead has no authority to stop it.

What happens in the closure phase – reports, replay and purple teaming?

Closure begins with informing the blue team that a test took place (Article 12(1)) and covers, within 10 weeks: the red-team report (4 weeks), the blue-team report, a joint replay of the attack, and purple-teaming activities on identified vulnerabilities and untested areas. It ends with feedback exchanged between all parties.

Contents of the two reports under Annexes V and VI:

Red-team report (Annex V, 4 weeks)	Blue-team report (Annex VI, 10 weeks)
targeted functions and systems	for each attack stage: detected attempts and corresponding log entries
summary of each scenario	assessment of the testers’ findings and recommendations
flags captured and not captured	evidence of the attack gathered by the blue team
successful and failed attack paths, effective and ineffective TTPs	root-cause analysis of successful attacks (from the defensive view)
deviations from the plan, leg-ups granted	lessons learned and improvement opportunities
blue-team actions known to the testers	topics for purple teaming
vulnerabilities with criticality, root causes, prioritised recommendations

The replay (Article 12(5)) is a joint session in which the testers walk through the attack path step by step while the blue team compares it with what it saw in logs and alerts. This is where detection gaps surface: the attack ran for 12 weeks and the SOC saw two low-priority alerts.

Purple teaming in closure (Recital 24) may include discussing alternative scenarios, executing them on live systems, or re-running scenarios the testers could not complete. The aim is to maximise learning – every unexecuted scenario is an untested hypothesis about resilience.

Closure of a TLPT requires, under Article 12(5) of RTS 2025/1190, that no later than 10 weeks after active testing ends the blue team and the testers replay the offensive and defensive actions and conduct purple-teaming activities.

At the test managers’ request, reports exclude sensitive information (Article 12(3)-(4)) – the control team should prepare a full internal version and a redacted version for the authority.

What must the TLPT remediation plan and the test summary report contain?

Once the authority confirms the red-team and blue-team reports are complete, the entity has 8 weeks for two documents: the test summary of material findings (Annex VII, Article 12(7)) and the remediation plan (Article 13). For every finding, the plan must describe the shortcoming, prioritised and scheduled measures, root-cause analysis, responsible functions, and the risk of non-implementation. Only then is the attestation issued.

The test summary (Annex VII) has 15 elements: parties, project plan, approved scope with reasoning, scenarios and deviations from the TTI, attack paths and TTPs, flags, deviations from the plan, detections, purple teaming in the testing phase, leg-ups, risk measures, vulnerabilities with criticality, root causes, a high-level remediation plan, and lessons learned.

The remediation plan (Article 13(2)) – five mandatory elements per finding:

Description of the shortcoming – what specifically enabled the attack (not “weak segmentation” but “no traffic filtering between the workstation VLAN and the application server segment”).
Remediation measures with priority and expected completion – including measures to improve identification, protection, detection and response.
Root-cause analysis – why the gap existed: process, technology, skills, budget.
Responsible staff or functions – specific roles, not “the IT department”.
Risk of non-implementation – and, where relevant, the risk of implementation itself.

A TLPT remediation plan must, under Article 13(2) of RTS 2025/1190, contain for every finding a root-cause analysis and an indication of the risks associated with not implementing the proposed measures.

The attestation (Annex VIII) records test dates, functions in scope, involvement of other entities and ICT providers, the type of testers, the active phase duration in days, and the documents the authority reviewed. It is the basis for mutual recognition by authorities in other Member States (DORA Article 26(7)).

Holding the red-team and blue-team reports with 8 weeks to produce a remediation plan the authority will accept?

Patronusec supports the control team in drafting the test summary and remediation plan: within 15 working days you receive drafts of both documents in the Annex VII and Article 13 structure, with root-cause analysis and prioritised measures, ready for board approval.

Request remediation plan support

How do you use TLPT results beyond the regulatory obligation?

You use TLPT results in four areas beyond the attestation: as input to the ICT risk management framework of Article 6 DORA, as a correction to the Article 24-25 testing programme (penetration tests, scans, scenarios), as training material for the SOC and the board, and as a baseline for the next cycle in 3 years. Recital 24 of the RTS frames TLPT as a learning experience, not merely an obligation.

Four practical applications:

ICT risk register – every root cause from the remediation plan becomes a risk with an owner and a deadline; TLPT provides evidence that the risk is real rather than theoretical.
Article 24 testing programme – attack paths show which systems need more frequent penetration testing and which gaps regular authenticated vulnerability scans would have caught.
Detection and response – the blue-team report shows how many alerts 12 weeks of attack generated; every undetected technique is a detection rule to write and a scenario to rehearse in the SOC.
The board – the summary in its management-body version shows resilience in business terms: which critical functions were reachable, in what time and at what cost to the attacker.

Under Recital 24 of RTS 2025/1190, TLPTs should be used as a learning experience to increase the digital operational resilience of financial entities.

It is also worth confronting the results with the 12-month cybersecurity roadmap – if the test showed an attacker reaching a critical function in 3 weeks, the roadmap’s priorities probably need to change.

Patronusec Insight: The greatest value of TLPT emerges in the second cycle, 3 years on – but only if the entity preserved comparability: the same functions in scope, similar actor profiles, the same metrics (time to first foothold, time to detection, number of flags captured). In our project experience, it pays to define 5-6 resilience indicators in the first cycle and record them in the test summary. Patronusec proposes such an indicator set in the red-team report, so that in 3 years the board gets an answer to “are we more resilient?” rather than just another list of vulnerabilities.

What mistakes do organisations make during a TLPT?

The most common mistakes during a TLPT concern confidentiality, leg-ups, the reaction to detection, the quality of the remediation plan and the loss of comparability between cycles. Each maps to a specific requirement of RTS 2025/1190.

❌ An oversized control team that includes the SOC manager – contradicts the logic of Article 1(3) (an unaware blue team); detection results become unreliable.

❌ Leg-ups granted “to keep the test moving”, undocumented – Article 11(8) requires them to be planned and approved; undocumented leg-ups undermine the result before the test manager.

❌ Treating detection by the blue team as a failure and quietly ending the scenario – Article 11(9) requires a continuation procedure; detection is one of the most valuable results.

❌ A remediation plan that is a list of vulnerabilities from the red-team report – Article 13(2) requires root-cause analysis, owners and the risk of non-implementation; a CVE list does not meet it.

❌ No redacted versions of the reports – Article 12(3)-(4) anticipates the authority asking for them; preparing them afterwards delays closure.

❌ Breaking comparability between cycles – changing scope and metrics in the second test makes it impossible to judge whether first-cycle remediation worked.

FAQ – TLPT step by step

How many people should be on the control team?

Usually 3-6. Recital 10 of RTS 2025/1190 requires the team to be as small as possible, with deep knowledge of the entity and access to the board. A typical composition: lead (CISO or deputy), IT architect, operational risk, legal, and the owner of relationships with in-scope ICT providers.

Must the board know about the test?

Yes. Article 4(2)(a) of the RTS lists the management body among those with access to test information, Article 9(6) requires the board to approve the scope specification, and Article 9(4)(b) obliges the control team to report progress and risk to the board.

What if the testers capture no flags?

The test remains valid. The red-team report documents failed paths and ineffective TTPs (Annex V), and closure includes purple teaming on untested areas (Article 12(5)). The control team should, however, examine whether leg-ups were missing or scenarios unrealistic.

Can the blue team be informed during the test?

Only in justified cases and with the test managers’ prior consent (Article 4(2)(b), Recital 9). The most common case is limited disclosure to one person after detection, to halt escalation without revealing the test to the rest of the team.

When must testers remove their tools from the systems?

After the test, under Article 7(1)(g)-(h): C2 deactivation, removal of backdoors and malware, secure deletion of credentials and data, notification of potential breaches, and procedures enabling future backup restoration. The control team verifies completion before closure.

How long does Patronusec’s support in the closure phase take?

We run the replay and purple teaming within the 10-week window required by Article 12(5), and deliver drafts of the test summary and remediation plan within 15 working days of the authority confirming the reports – with margin against the 8-week deadline of Article 13.

How do we start working with Patronusec on TLPT?

With a free 30-minute consultation in which we establish where your entity stands – before notification, in preparation or after the active phase – and agree the support scope: readiness assessment, documentation review, delivery of both TLPT roles, or remediation plan support.

Blog space

TLPT step by step – how to prepare the organisation, run the test and use the results under RTS 2025/1190

In this article you will learn:

Table of Contents