TIBER-EU Navigator

A free reference for the threat-led penetration testing lifecycle under Regulation (EU) 2022/2554 (DORA), Commission Delegated Regulation (EU) 2025/1190 (the regulatory technical standards on TLPT) and the TIBER-EU framework. It sets out every phase, milestone, duty, role and deliverable of a test beside the article, annex or guidance section it rests on, with the source text quoted verbatim.

Written for test managers, control team leads and control team members, testers, threat intelligence providers and TLPT authorities — as a reference during a live engagement and as an onboarding and training aid.

Unofficial. Only the Official Journal text of DORA and Regulation (EU) 2025/1190 is authentic; TIBER-EU guidance is published by the European Central Bank.

This app needs JavaScript for the lifecycle band, the role filter, the project timeline planner and the verbatim source text of each provision. The duties themselves follow here in plain form.

The lifecycle

Every phase, stretch and duty of a threat-led penetration test, with the article, annex or guidance section each rests on. The source text of every provision is quoted verbatim in the app itself, and at https://tibernavigator.eu/llms-full.txt.

Preparation phase

From the TLPT authority's notification through control team validation, scoping, procurement and risk management, to the start of the testing phase.

Notification

No duration fixed in the regulation.

The TLPT authority notifies the entity that a test is to be carried out. The notification is what obliges the entity to initiate the test, and it is where the test manager gives the entity the contact details of the TCT to work with from here on. Both preparation deadlines run from the date the entity receives it: three months for the initiation information, six months for the scope specification document. TIBER-EU adds a notification meeting, held with or shortly after the written notification, at which the test manager briefs the entity on what is about to happen; the RTS records no such meeting.

Notify the entity that a TLPT is to be carried out — The TLPT authority tells the financial entity that a test will take place. The notification carries the TCT's contact details and starts both preparation clocks, so everything else in the phase is measured from the day it arrives. Sources: DORA Art. 26(8); RTS Art. 9(1); RTS Art. 3(4); TIBER-EU Framework §6, Notification
Hold the notification meeting — With, or shortly after, the written notification, the test manager meets the entity and briefs it on its designation, on who does what, on the testing process and its deliverables, and on the composition of the two teams. The parties also identify any further entities or legal parties that will have to be involved in the test. Sources: TIBER-EU Framework §6, notification meeting

Initiation

Within 3 months from receipt of the notification (RTS Art. 9(2))

The entity appoints the control team lead, puts the secrecy arrangements in place, and submits the initiation information — project charter, contacts, tester intent, communication channels, code name. The authority validates it, which unlocks setting up the control team.

Appoint the control team lead — The financial entity appoints a control team lead, who is responsible for the day-to-day management of the TLPT and for the decisions and actions of the control team. Sources: RTS Art. 4(1); Control Team Guidance §1.3
Establish the organisational and secrecy arrangements — The entity puts in place the measures that make a covert test possible: need-to-know access to TLPT information, consultation of the test managers before any blue team member is involved, a route by which the control team learns of any detection and can contain the resulting incident escalation, secrecy arrangements binding staff and the providers concerned, disclosure to the test managers on request, and code-name-only reference to the test. Sources: RTS Art. 4(2); TIBER-EU Framework §4.1.5
Submit the TLPT initiation information — Within three months of the notification, the entity submits to the test managers a project charter with the content set out in Annex I, the control team lead's contact details, whether internal or external testers or both will be used, the communication channels for the test, and the code name. Sources: DORA Art. 26(1); RTS Art. 9(2); RTS Annex I; Initiation Documents Guidance §1.3; Initiation Documents Guidance §2
Validate the TLPT initiation information — Where the five items are complete and ensure the suitability and effective performance of the TLPT, the TLPT authority validates the initiation information and notifies the entity. That validation is the gate to setting up the control team. Sources: RTS Art. 9(3); Initiation Documents Guidance §1.3
Set up the control team — Following validation of the initiation information, the entity sets up a control team to support the control team lead in specifying communication channels and processes, briefing the management body on progress and risks, taking expert decisions, executing the test in compliance with the Regulation, selecting the threat intelligence provider and the testers, and preparing the scope specification document. Sources: RTS Art. 9(4); Control Team Guidance §1.3
Validate the control team composition — Where the TLPT authority considers the initial composition and any later changes adequate, it validates the control team and notifies the control team lead. Sources: RTS Art. 9(5); Control Team Guidance §1.3

Scoping

SSD submitted within 6 months from receipt of the notification (RTS Art. 9(6))

The control team applies the Article 9(7) criteria, drafts the scope specification document, and the management body then the TLPT authority approve it. The six months runs from the notification rather than from the end of initiation, so scoping and initiation overlap rather than queue: an entity that uses all three months on initiation has three left for scoping, not six.

Apply the CIF scoping criteria — When deciding which critical or important functions to bring into scope, the entity considers the seven criteria listed in Article 9(7). Sources: RTS Art. 9(7); SSD Guidance §1
Submit the scope specification document — The financial entity submits the SSD, with the content prescribed by Annex II, to the test managers within six months of receiving the TLPT authority's notification. The management body approves it. TIBER-EU guidance places the drafting in the scoping step and describes the control team as the drafter. Sources: RTS Art. 9(6); RTS Art. 9(4); RTS Annex II; SSD Guidance §1.3
Approve the scope specification document — Where the SSD is complete and ensures an appropriate and effective TLPT, the TLPT authority approves it and informs the control team lead. This is a second approval, on top of the management body's under Article 9(6), and it is the gate to the threat intelligence stage. Sources: RTS Art. 9(12); TIBER-EU Framework §6, Scoping

Procurement

Completed prior to the initiation of the testing phase (RTS Art. 9(9))

The control team assesses candidate threat intelligence providers and testers against DORA Article 27 and RTS Article 7(1), evidences compliance to the test managers, and contracts them — unless the TLPT authority's opinion blocks it. Where internal testers are used, the Article 15 arrangements must already be in place. The Regulation sets only a relative deadline — the stretch must end before the testing phase begins — so procurement has no date of its own. In practice the six-month scope specification clock bounds it, because the providers need the approved document before they can start work.

Put the internal-tester arrangements in place — An entity intending to use internal testers must first establish a policy for managing them, measures ensuring their use does not weaken its own defensive or resilience capabilities, and measures ensuring they have the resources and capabilities to run a TLPT. The policy sets suitability, competence and conflict-of-interest criteria and management responsibilities, is documented and periodically reviewed, requires a test lead and at least two further members, requires every member to have been employed by the entity or an ICT intra-group service provider for the preceding twelve months, and covers training. Sources: DORA Art. 26(8); DORA Art. 27(2); RTS Art. 15(1); RTS Art. 15(2); RTS Art. 15(4); TIBER-EU Framework §6, Procurement
Assess and evidence provider compliance before contracting — The control team assesses candidate threat intelligence providers and testers against DORA Article 27 and RTS Article 7(1), documents the outcome, and gives the test managers evidence of compliance before the selected providers are contracted. Contracting is then blocked outright where the TLPT authority takes the view that the selected providers fall short of those requirements, of national security requirements, or of the entity's own obligations under Article 7(2). Sources: DORA Art. 27(1); DORA Art. 27(2); RTS Art. 9(11); RTS Art. 7(1); RTS Art. 7(2); Service Provider Procurement Guidance §1.3
Complete procurement of testers and TI providers — Procurement or assignment of testers and threat intelligence providers is finished before the testing phase begins. Sources: RTS Art. 9(9); TIBER-EU Framework §6, procurement timing
Share initiation information and the SSD with contracted providers — Once contracted, the testers and threat intelligence providers receive the TLPT initiation information and the SSD, and are briefed on the testing process to be followed. Sources: RTS Art. 9(8); TIBER-EU Framework §6, onboarding

TLPT risk management

During the preparation phase (RTS Art. 5(1)); consulted prior to the initiation of the testing phase (RTS Art. 9(10))

The control team assesses the risks of testing live production systems supporting critical or important functions, puts the risk management measures in place, and consults the test managers on both before the testing phase begins. Article 5(1) keeps the assessment running through the test, so this stretch opens the work rather than closing it. Article 5 stands apart from scoping: it addresses the risks of running the test at all rather than what to put in scope, and Article 9(10) bounds the consultation by the start of the testing phase rather than by the scope specification document.

Assess and manage the TLPT risks — During the preparation phase the control team assesses the risks of testing live production systems supporting critical or important functions, including the potential impact on the financial sector and on financial stability at Union or national level, and keeps those impacts under review throughout the testing. The assessment covers at least provider access to sensitive information, the risk of losing the attestation, crisis and incident escalation, the active red team phase, blue team activity, and incomplete restoration. Sources: RTS recital 11; RTS Art. 5(1); RTS Art. 5(2); RTS Art. 9(10); TIBER-EU Framework §4.1.2
Consult the test managers on the TLPT risk assessment — Before testing starts, the control team consults the test managers on the risk assessment and the risk management measures, and revises them where the TLPT authority considers they do not adequately address the risks. Sources: RTS Art. 9(10); TIBER-EU Framework §4.1.2

Testing phase

Targeted threat intelligence (Art. 10), red team test plan and active red team testing (Art. 11).

Threat intelligence

No duration fixed in the regulation.

The threat intelligence provider analyses generic and sector-specific intelligence, proposes scenarios, and the control team lead selects at least three. The resulting targeted threat intelligence report is submitted to the test manager and approved by the TLPT authority, which opens the red team test.

Where the RTS and TIBER-EU differ: The RTS makes this part of the testing phase — Article 10 is headed "Testing phase: threat intelligence" — while TIBER-EU treats it as a phase in its own right, and the TTI Report Guidance places the work "of the threat intelligence phase". Neither is wrong; a practitioner moving between the two will hear "phase" mean different things.

Gather and analyse targeted threat intelligence — Once the TLPT authority has approved the SSD, the threat intelligence provider analyses generic and sector-specific intelligence for the entity, identifies cyber threats and existing or potential vulnerabilities, and gathers concrete, actionable and contextualised target and threat intelligence, consulting the control team and the test managers. Where the authority has published a generic threat landscape for the Member State's financial sector, the provider may use it as a baseline. Sources: RTS Art. 10(1); TTI Report Guidance §1.3
Select the attack scenarios — The threat intelligence provider presents the relevant threats and proposes scenarios to the control team, testers and test managers. The control team lead then selects at least three, weighing the provider's recommendation and the threat-led nature of each, the test managers' input, the testers' judgement of feasibility, and the entity's size, complexity and risk profile. Each scenario must target a critical or important function in scope and differ by threat actor and by tactics, techniques and procedures. Sources: RTS Art. 10(2); RTS Art. 10(3); RTS Art. 10(4); TTI Report Guidance §1.3
Submit the targeted threat intelligence report — The threat intelligence provider gives the control team the TTI report, with the content set out in Annex III and the selected scenarios included, and the control team submits it to the test manager for approval. Sources: RTS Art. 10(5); RTS Art. 10(6); RTS Annex III; TTI Report Guidance §1.3
Approve the targeted threat intelligence report — Where the TTI report is complete and ensures an effective TLPT, the TLPT authority approves it and informs the control team lead. The approval opens the red team test plan. Sources: RTS Art. 10(6); TTI Report Guidance §1.3

Red team test plan

No duration fixed in the regulation.

The testers draft the red team test plan from the SSD and the TTI report, consult the control team, the threat intelligence provider and the test managers, and the control team and TLPT authority approve it.

Prepare the red team test plan — After the TLPT authority approves the targeted threat intelligence report, the testers draft the red team test plan with the content set out in Annex IV, using the SSD and the TTI report as the basis for the attack scenarios, and consult the control team, the threat intelligence provider and the test managers on it. Sources: RTS Art. 11(1); RTS Art. 11(2); RTS Annex IV; RT Test Plan Guidance §1.3; TIBER-EU Framework §8.3, test plan meeting
Approve the red team test plan — The control team and the TLPT authority approve the plan where it is complete and ensures an effective TLPT. Changes made after approval are approved by the control team lead and the test managers instead. Sources: RTS Art. 11(3); RTS Art. 11(6); RT Test Plan Guidance §1.3

Active red team testing

At least 12 weeks of active red team testing (RTS Art. 11(5))

The testers execute the attack scenarios against live production systems. Weekly progress reporting and leg-ups on request sit here, and so does limited purple teaming, which is optional and reached only when the test cannot otherwise continue. Detection and suspension are the exception procedures: what to do if the red team is spotted, and what to do if the test cannot go on. The twelve weeks is a floor on active red team testing alone, not on the testing phase and not on the engagement, and time spent on limited purple teaming counts toward it.

Report progress at least weekly — Throughout the active red team testing phase the testers report progress to the control team and the test managers at least weekly, and the threat intelligence provider stays available for consultation and further intelligence on request. Sources: RTS Art. 11(7); TIBER-EU Framework §8.4, weekly updates
Provide leg-ups — The control team provides leg-ups in good time, designed on the basis of the red team test plan. Adding or adapting a leg-up requires approval by the control team and the test managers. Sources: RTS Art. 11(8); TIBER-EU Framework §8.2.2
Agree the end of active red team testing — Active testing runs for at least twelve weeks and in proportion to the scope and the number and complexity of the entities and providers involved. Its end is agreed jointly by the control team, the threat intelligence provider, the testers and the test managers. Sources: RTS Art. 11(5); TIBER-EU Framework §8.4, end of active testing
Continue the test as a limited purple teaming exercise — Where the test cannot otherwise continue, the control team lead may keep it running as a limited purple teaming exercise instead of suspending it — a last resort, and only with the TLPT authority's prior validation. Time spent on it counts toward the twelve-week minimum, so the test continues rather than restarting. Sources: RTS Art. 11(10); Purple Teaming Guidance §1.3

Closure phase

Red team and blue team test reports, replay and purple teaming, mutual feedback, the report summarising the relevant findings, the remediation plan and the attestation.

Test reports and replay

Within 10 weeks from the end of the active red team testing phase

The blue team learns a test took place, both test reports are written, and the two teams replay the offensive and defensive actions and hold the purple teaming exercise. Ends when the TLPT authority notifies the control team lead that both reports contain what Annexes V and VI require — the last duty listed here, and the gate to the reporting stretch. The ten weeks bound the writing and the workshops, not the assessment that follows them: the red team's four weeks sit inside the blue team's ten, leaving at least six for the blue team report and the replay, and the assessment itself has no length — which is why TIBER-EU says the closure phase may run longer than eighteen weeks.

Tell the blue team a TLPT took place — Once active red team testing ends, the control team lead informs the blue team that a test has been running. This is the moment secrecy ends for the defenders. Sources: RTS Art. 12(1); TIBER-EU Framework §8.4, end of active testing
Brief the blue team on the test report it owes — A team that has just learned it was the target of a covert test has never seen the project, the deliverable it now owes, or the deadline it is already inside. Once secrecy ends the control team brings the blue team into the project and briefs it on what the blue team test report has to contain, when it is due, that a draft of the red team test report comes first, and that the report is written before the replay and purple teaming. Sources: RTS Art. 12(4); RTS Annex VI; RTS Art. 12(1); BT Test Report Guidance §1.3
Submit the red team test report — Within four weeks of the end of active testing the testers give the control team the red team test report, with the content set out in Annex V. The control team passes it to the blue team and the test managers without undue delay, omitting sensitive information if the test managers ask. Sources: RTS Art. 12(2); RTS Art. 12(3); RTS Annex V; RT Test Report Guidance §1.3
Submit the blue team test report — No later than ten weeks after the end of active testing, and having received the red team test report, the blue team gives the control team its own report with the content set out in Annex VI, omitting sensitive information if the test managers ask. Sources: RTS Art. 12(4); RTS Annex VI; BT Test Report Guidance §1.3
Replay the offensive and defensive actions — No later than ten weeks after the end of active testing, the blue team and the testers walk back through what each side did during the test, so the defenders can see the attack as it was actually carried out and match it against what they observed at the time. Sources: RTS Art. 12(5); TIBER-EU Framework §9.3
Conduct the purple teaming exercise — The control team runs a purple teaming exercise on topics the blue team and the testers identify together, drawn from the vulnerabilities the test found and, where relevant, from things the active red team phase could not reach. Sources: RTS Art. 1(6); RTS Art. 12(5); Purple Teaming Guidance §3.3.1
Assess the two test reports as complete — The TLPT authority assesses that the red team and blue team test reports contain what Annexes V and VI require, and notifies the control team lead. This is the gate between the two stretches of the closure phase: it starts the eight weeks for the summary report and the eight weeks for the remediation plan at the same moment, and until it arrives neither clock runs. Sources: RTS Art. 12(7); RTS Art. 13(1); RTS Annex V; RTS Annex VI; TIBER-EU Framework §9.2; TIBER-EU Framework §9.1

Reporting and remediation

Within 8 weeks from the notification referred to in RTS Art. 12(7)

Once the two test reports are assessed as complete, the stakeholders exchange their 360-degree feedback and the entity has eight weeks to submit the summary report for approval and to provide the remediation plan. The Article 12(7) notification that opens the stretch assesses the two reports for completeness against Annexes V and VI, not their findings, and it starts both eight-week clocks at once, so the summary report and the remediation plan run in parallel. The eight weeks bind those two deliverables and nothing else: they are the entity's to meet, and they end when it has provided both.

Hold the mutual feedback session — Once the replay and the purple teaming are done, the control team, the blue team, the testers and the threat intelligence providers give each other feedback on how the TLPT process went. The test managers may take part but are not obliged to. Sources: RTS Art. 12(6); TIBER-EU Framework §9.7; TIBER-EU Framework §9.1
Create and provide the test summary report — Once the TLPT authority notifies the control team lead that the red team and blue team test reports contain what Annexes V and VI require, the financial entity has eight weeks to draw up the report summarising the relevant findings, with the content set out in Annex VII, and provide it to the TLPT authority. Article 12(7) has it submitted for approval; DORA Article 26(6), the obligation it discharges, has the entity provide it to the authority alongside the remediation plans and the supporting documentation. Sources: DORA Art. 26(6); RTS Art. 12(7); RTS Annex VII; Test Summary Report Guidance §1.3
Create and provide the remediation plan — Within eight weeks of the same notification, the entity draws up its remediation plans and provides them, with the documentation required by DORA Article 26(6), to the TLPT authority and, where different, to its competent authority. For each finding the plan sets out the shortcoming, the proposed measures with their prioritisation and expected completion, a root cause analysis, who is responsible, and the risks of not acting — and where relevant of acting. Sources: DORA Art. 26(6); RTS Art. 13(1); RTS Art. 13(2); RTS recital 26; Remediation Plan Guidance §1.3

Attestation

No duration fixed in the regulation.

The TLPT authority issues the attestation, and the test ends. It is the authority's act alone, and it stands outside the eight weeks: DORA Article 26(7) makes the attestation a confirmation that the test was performed in accordance with the requirements "as evidenced in the documentation", and Article 26(6) has that documentation — the summary of the relevant findings and the remediation plans — provided beforehand, so neither of the two deliverables can still be outstanding when it is issued. What no provision does is date it. The eight weeks are the entity's to meet and stop when it has provided both documents; nothing in DORA or the RTS says by when the authority must then attest, so an entity that has met every deadline the Regulation sets can still be waiting for the document its supervisor will ask to see. TIBER-EU Framework §9.1 puts the attestation after the eight-week part for the same reason, and §9.8 has the issuing of it conclude the test.

Issue the attestation — The TLPT authority issues the attestation required by DORA Article 26(7), with the content set out in Annex VIII. Where several TLPT authorities were involved, the lead authority provides it to the tested entity. Sources: DORA Art. 26(6); DORA Art. 26(7); RTS Art. 14(1); RTS Art. 14(2); RTS Annex VIII; Attestation Guidance §1.3

Across the project

Duties that are not confined to one stretch, or even to one phase: they are discharged more than once, in more than one document, at more than one point.

Disclose the use of internal testers in the required documents — Where internal testers are used, that fact must appear in the TLPT initiation information, in the red team test report, and in the report summarising the relevant findings. Sources: DORA Art. 26(6); RTS Art. 15(3); Initiation Documents Guidance §2

If something goes wrong

Procedures that apply only when the test departs from plan. They are not steps in the lifecycle — listing them in sequence would assert that every test performs them.

If the testing is detected — If any staff member of the entity or of a relevant ICT third-party or intragroup provider detects the testing, the control team consults the testers, then proposes measures that allow the test to continue while preserving secrecy and submits them to the test managers for validation. Sources: RTS Art. 11(9); TIBER-EU Framework §8.4, detection
If exceptional circumstances threaten the entity or the sector — Where exceptional circumstances threaten data, assets, or the continuity of critical or important functions of the entity, its providers, its counterparts or the wider sector, the control team lead may suspend the TLPT. Sources: RTS Art. 11(10); RTS Art. 1(6); TIBER-EU Framework §8.4, suspension

Project timeline planner

The app includes a project timeline planner for one TLPT, opened from the calendar control beside Search. The reader picks the date the TLPT authority's notification was received, which starts the clock for the timed preparation phase duties, and the planner seeds the other dates from it with how long each stage usually takes in practice, with weeks counted from the Monday after a date that falls on a Friday or a weekend. Every date can then be changed: the picker offers only dates inside the limits the Regulation sets (RTS Art. 9(2), RTS Art. 9(6), RTS Art. 11(5), RTS Art. 12(2), RTS Art. 12(4), RTS Art. 12(5), RTS Art. 12(7)) and in the order the sources set, and changing one date moves every later date by the same amount. The four things due after the scope specification document is submitted — its approval, procurement, the providers' briefing and the risk management consultation — share one date, the end of the preparation phase. The closure phase is planned as the Regulation builds it: a ten-week block for the test reports and the replay, the assessment of the reports, then an eight-week block for reporting and remediation, each block with one end date. The attestation is left undated: the TLPT authority takes the time it needs to review the test reports and issue it, and DORA Art. 26(7) and RTS Art. 14 set no period for it.

The plan stays in the reader's browser. It is never put in a link and never sent anywhere; it leaves the browser only as a JSON or Markdown file the reader downloads. The dates are the reader's plan, not deadlines set by DORA, the RTS or TIBER-EU.