Does a TIBER-EU test count as DORA TLPT?
A TIBER-EU test run under a national or European implementation can satisfy DORA threat-led penetration testing (TLPT), but only if it also meets the formal TLPT requirements set by the competent authority. The answer depends on three things: whether your entity is identified for DORA TLPT, which authority supervises the test, and whether the formal conditions for TLPT are met. If a regulator or customer now asks for threat-led testing, start by confirming with your competent authority whether you are in scope and whether it will treat your TIBER-EU test as the DORA TLPT. Do not assume either answer from the existence of a TIBER-EU programme in your country alone.
The Eurosystem updated TIBER-EU in February 2025 to align its process steps, deliverables and timelines with the DORA TLPT standards, which are set out in Commission Delegated Regulation (EU) 2025/1190. The ECB states that the core requirements of DORA TLPT and TIBER-EU are identical, so an entity that completes a test under a TIBER-EU implementation should be DORA TLPT-compliant. The same update made purple teaming mandatory and renamed the White Team the Control Team. Where TIBER-EU is used for DORA TLPT, the TLPT authority is treated as the TIBER authority for that test, and the test summary report and remediation plan must also go to the competent authority if it is not acting as TIBER authority. Check this routing in your engagement letter before the test starts.
Your organization owns its controls and its response to the findings. DeployOpen prepares systems, controls and evidence for a TIBER-EU or DORA TLPT test, but it does not issue the attestation or any report. Those come from the authority and the independent providers involved in the test. Ask your authority to confirm in writing which documents it will accept for DORA purposes, and plan your evidence file around that list.
Which deadlines match in TIBER-EU and DORA TLPT
The deadlines in TIBER-EU and Delegated Regulation (EU) 2025/1190 are the same, so one timeline can serve both a voluntary TIBER-EU test and a DORA threat-led penetration test. Each step below closes with a deliverable that starts the next clock.
Start the clock with written notification
The authority notifies the entity in writing that a test will take place, and that notification starts the preparation phase. The entity's control team confirms the date in its own records and asks the authority to state in writing which event starts each later deadline. The step is done when the entity holds a dated notification and an agreed list of the clock start points.
Complete initiation within 3 months
Within 3 months, the entity, the authority and the test manager complete initiation, including the initiation documents, the appointment of the control team and the arrangements for the threat intelligence and red team providers. The control team leads this work for the entity, and the authority confirms the test's roles and governance. The step closes when the initiation documents are signed off by the authority.
Finalize the scope within 6 months
Within 6 months of notification, the scope specification document is agreed, covering the critical or important functions, the flags and the systems in scope. Procurement of the threat intelligence provider and red team testers must also be finished, because the testing phase cannot begin without them. The step closes when the authority approves the scope and the entity holds signed provider contracts.
Run active red team testing for at least 12 weeks
The threat intelligence provider delivers the targeted threat intelligence report, and the red team then writes its test plan. Active testing against the flags runs for at least 12 weeks under the supervision of the control team and test manager. The step closes when active testing ends and the test manager records the end date, which starts the closure deadlines.
Deliver the red team report within 4 weeks
The red team provider issues the red team test report within 4 weeks of the end of active testing. The report records the attack paths, the flags reached and the techniques used. The control team checks it against the test plan and the logs before it moves to the blue team stage. The step closes when the red team report is accepted by the test manager.
Complete blue team report, replay and purple teaming within 10 weeks
Within 10 weeks of the end of active testing, the blue team produces its test report, the red and blue teams complete replay, and purple teaming is carried out, which is mandatory under the 2025 update. The output is a shared record of which detections worked and which did not. The step closes when the blue team report and the purple teaming results are filed with the test manager.
Issue summary report and remediation plan within 8 weeks
Within 8 weeks of the authority's assessment, the test summary report and the remediation plan are issued. Under DORA, both must also go to the competent authority if it is not acting as the TIBER authority. The step closes when the entity holds the final summary report, the remediation plan and the authority's attestation, which together complete the test. Entities should confirm with their authority exactly when the assessment date falls and which date starts the 8 weeks.
Which route applies: DORA TLPT, voluntary TIBER-EU or outside DORA
This table compares three routes to a threat-led test: a financial entity identified for DORA TLPT, a voluntary TIBER-EU test by an entity the authority has not identified, and a voluntary test by an entity outside DORA or in another critical sector. Read each row against your own status, and confirm the route with your competent or TIBER authority before scoping starts.
| Aspect | DORA TLPT (identified financial entity) | Voluntary TIBER-EU test (not identified) | Voluntary test outside DORA |
|---|---|---|---|
| Legal driver | DORA Article 26 and Commission Delegated Regulation (EU) 2025/1190 require the test once the competent authority identifies the entity | No DORA obligation. The test follows an authority's voluntary TIBER-EU implementation and the entity's own decision to take part | No DORA obligation. The entity chooses TIBER-EU as a method, usually because its sector or customers expect a threat-led approach |
| Three-year cycle | TLPT at least every 3 years for identified entities (DORA Article 26(1)) | The TIBER-EU norm of 3-year intervals applies, but no mandatory cycle is set for a non-identified entity | No external cycle. The entity sets its own interval, which the framework would still treat as the reference point |
| Authority's role | The competent authority acts as TIBER authority for the test, and the test summary report and remediation plan also go to the competent authority if it is not the TIBER authority | The national or ECB TIBER authority runs the test through its TIBER Cyber Team and test manager, if it accepts the entity | No TIBER authority is involved unless the entity or its regulator asks for one. Oversight depends on the contract and sector rules |
| Can the result serve as DORA evidence? | Yes, when the test meets the formal TLPT requirements set by the competent authority, since the ECB states the core requirements are identical | Not automatically. The entity must ask its competent authority whether the test counts toward any DORA obligation | No. A DORA-based claim needs the entity to be in scope, so the result cannot serve as DORA TLPT evidence on its own |
| Attestation and mutual recognition | The authority's attestation supports mutual recognition between authorities under DORA Article 26(7) | The authority's attestation is issued at closure, but recognition by other authorities depends on their rules | No attestation from a TIBER authority. Any assurance is limited to the report the entity agrees with its provider |
| Internal testers and providers | Strict DORA rules apply, including external threat intelligence providers and limits on internal testers | The TIBER-EU framework rules apply, as set by the authority and the test manager | Set by the entity's own policy and the contracts it signs |
| What to confirm with your authority | Your identification notice, the formal TLPT requirements, the TIBER authority designation and the timing of notification | Whether the authority accepts voluntary entities, the criteria it uses, any fees it charges and how its national document applies | Whether a regulator, customer or sector body accepts a non-TIBER threat-led test, and the report format it expects |
Rules on internal testers and external providers
DORA and TIBER-EU limit how much of a threat-led test an entity can run with its own staff. The five rules below set who may act as a tester, who must be external, and what the entity must document and get approved before testing begins. The provider selection guide covers how to choose external firms within these limits.
Internal testers need prior approval
Under DORA, an entity may use internal testers for a threat-led test only with prior approval from its competent authority. Treat this as a gating decision made before any test planning starts. Document the names and roles of proposed internal testers, their red teaming experience, and how they are separated from the production teams they would be testing. Ask the authority in writing which evidence it expects with the request.
Threat intelligence provider must be external
The threat intelligence provider must always come from outside the entity, whether the test is a TIBER-EU test or a DORA TLPT. Internal threat analysts can support the control team but cannot produce the targeted threat intelligence report. Document the provider's independence, its contract, and the sources behind its scenarios. The authority approves the provider as part of the procurement step.
External testers every third test
DORA requires that external testers be used at least once every three tests. The entity must keep a test history showing which tests used external red team testers and which used internal ones, so the count is verifiable. Record the sequence in the test summary and check it before the next procurement. The competent authority reviews this record when it decides whether the next test can rely on internal staff.
Significant credit institutions use external testers only
A significant credit institution may not use internal testers for threat-led testing and must engage external red team testers for every test. This removes the internal option entirely for that entity. Confirm with the competent authority whether the entity is classed as significant before planning staffing. Internal staff can still take part in the control and blue teams, which are separate roles from the red team.
Test manager checks consecutive internal tests
TIBER-EU adds a check that the test manager at the authority performs before approving an internal-tester test. The entity must show it has not run two consecutive tests with internal testers. Keep a dated register of each test, its tester type, and the approving authority. Raise the question early during the initiation stage so that a planned internal test does not fail this check late in preparation.
Choose external providers with the selection guide
External threat intelligence and red team providers need to meet the independence, conflict and experience requirements that the authority reviews during procurement. Document each provider's team, certifications, insurance and conflict declarations, and keep the signed contract on file. The provider selection guide explains how to compare providers against these checks and how the test manager reviews the choice.
What the 2025 alignment changed for a DORA test
On 11 February 2025 the Eurosystem aligned the TIBER-EU process steps, deliverables and timelines with the DORA TLPT standards, made purple teaming mandatory and renamed the White Team the Control Team. For a financial entity already in a test, the first check is which framework version your authority is applying. The January 2025 framework document is the reference for the aligned steps, so ask the test manager to confirm in writing that the test plan, initiation documents and deadlines follow that version rather than an earlier national document. Where a test started before the update, confirm with the authority how any transitional arrangements apply to open steps.
The rename is more than a label. Under DORA terminology the people who manage the test's information flow to the red team are the Control Team, so entities should confirm who holds those roles, whether they are internal staff or external support, and that the people named in the scope documents are the same people who will run the control function. Check that no one in the Control Team also plays a role that the independence rules would not allow, and record any change of named individuals with the test manager before testing resumes.
Purple teaming now sits inside the closure phase rather than being optional. Plan it as a scheduled workshop within the same 10 week window that covers replay, the red and blue team reports and the purple teaming itself, counting back from the end of active testing. Confirm with the test manager which blue team staff, red team testers and Control Team members must attend, and book the sessions early, because the remediation plan and test summary report follow within the 8 week deadline after the authority's assessment.
Who does what in a DORA-recognized TIBER-EU test
Your organization owns the test outcome. The control team, the blue team, the decisions on scope and the remediation of findings all sit with the entity under test, and no outside party can take those over. The control team is the entity's own coordination point with the test manager and the threat intelligence and red team providers, so its members need enough authority to make and record decisions during live testing.
- Control team: Staff who supervise the red team, approve flags and manage risk during active testing. Confirm named members and their deputies before the authority's notification.
- Blue team: Staff who detect and respond to the red team without knowing its exact activity, and who produce the blue team test report.
- Remediation: Owning the remediation plan, the budget and the owners for each finding, including fixes at ICT third parties.
- Approvals: Signing off scope, procurement and the attestation request, which only the entity can give.
Ask your authority which internal roles it expects to see named in the initiation documents and whether any of them must be independent of the blue team.
An implementation partner such as DeployOpen can prepare the systems, logs, evidence and documentation that the control and blue teams rely on. This work is supporting work. The partner does not choose scenarios, decide what counts as a finding, approve red team actions or write the entity's remediation decisions, because those belong to the entity and to the independent providers.
- Telemetry readiness: Checking that logging, alerting and case tooling capture the activity the blue team will need to assess, and documenting where gaps exist.
- Evidence preparation: Organizing configuration records, runbooks and change logs so the control team can answer the test manager's questions quickly.
- Documentation support: Drafting process records and templates for the entity's review, with the entity approving the final text.
- Remediation execution: Building or hardening systems once the entity has decided what to fix and who owns it.
Before engaging a partner, confirm in writing that it will not be a member of the control team, will not advise the threat intelligence or red team providers, and will hold no role that the independence rules in your national implementation exclude.
The competent or TIBER authority appoints a test manager and runs the process, and it issues the attestation at the end of the test. The threat intelligence provider and the red team testers are independent providers that the entity procures under the framework's rules. Their work produces the targeted threat intelligence report, the red team test plan and the red team test report.
- Test manager: The authority's representative who supervises the test, checks procurement and the independence of providers, and reviews the reports.
- Threat intelligence provider: Must be external to the entity, and it builds the targeted threat intelligence used to select scenarios.
- Red team testers: Carry out the active testing against the flags, within the agreed rules of engagement and under control team supervision.
- Attestation: Only the authority issues it, which supports mutual recognition of the test between authorities.
DORA and TIBER-EU limit who can serve as external testers and how often internal testers may be used, so check the current rules with your authority before you sign any provider contract.
How cross-border tests and mutual recognition work
A cross-border TLPT under DORA involves more than one national authority, and the first practical question is which authority leads. Commission Delegated Regulation (EU) 2025/1190 gives host member state authorities 20 working days to respond to a test in their territory, either by joining as observers or by assigning a test manager. TIBER-EU sets the principles for this arrangement: one lead TIBER Cyber Team coordinates the test, and other authorities take part at a level that reflects their supervisory interest. Ask the lead authority, in writing, which authority will act as lead, how the test manager role will be shared, and which participation tier each host authority has chosen. Ask also how host authorities will be notified, when, and through which channel, so that the 20 working day window is not lost to an administrative gap.
The authority's attestation at the end of a test is the document that carries weight beyond one country. Under DORA Article 26(7), an attestation issued by a competent authority supports mutual recognition of the test between authorities, so that one completed test can be accepted by others rather than repeated in full. The ECB states that this reduces the burden on both entities and authorities. The reduction is only real if the test was run under a recognized TIBER-EU implementation and met the formal TLPT requirements of the competent authority. Before the test starts, confirm with your competent authority which attestation format it will issue, whether it will accept the attestation for the other jurisdictions where your group operates, and what each host authority will need to see in the test summary report.
Treat mutual recognition as something to plan for, not something to assume. Map every jurisdiction in which the tested entity or its group operates, and ask each relevant authority whether it expects to observe, to receive reports or to accept the lead attestation. Keep the scope specification document and the test summary report consistent across authorities so that the same findings and remediation plan can be presented to each one. Where a provider or an intra-group ICT service sits in another country, confirm early whether that country's authority needs to be involved. Any delay in these decisions will eat into the deadlines that run from initiation and scope, so the coordination questions belong in the first weeks of the preparation phase.
What buyers ask about TIBER-EU and DORA TLPT
Is a TIBER-EU test automatically DORA compliant?
Not automatically. The ECB states that the core requirements of DORA threat-led penetration testing (TLPT) and TIBER-EU are identical, so a test completed under a national or European TIBER-EU implementation can meet DORA TLPT, provided it also meets the formal TLPT requirements set by your competent authority. Those formal requirements cover things such as who the authority treats as the TIBER authority for the test and where the test summary report and remediation plan must be sent. Confirm the exact requirements with your competent authority before the test starts, because the answer depends on whether you have been identified for TLPT.
How often must a threat-led penetration test be repeated?
DORA requires TLPT at least every three years for financial entities identified by their competent authority, and TIBER-EU treats intervals of three years between tests as the norm. The three-year cycle reflects the resources and cost a test involves. Your competent authority or TIBER authority sets the actual schedule for your entity, so ask them for the date of your next test and whether any interim requirement applies to your organization.
Can an internal team run a TIBER-EU or DORA TLPT test?
Internal testers can take part in some roles, but DORA sets strict limits. Under DORA, internal testers need prior approval, the threat intelligence provider must be external, and external testers must be used at least every third test. Significant credit institutions may use only external testers. TIBER-EU adds that the test manager should check that the entity has not run two consecutive tests with internal testers. Ask your authority which roles, if any, your internal team may hold before you plan staffing.
Does an entity need a separate TLPT if it already ran a TIBER-EU test?
A TIBER-EU test that meets the DORA TLPT requirements can serve as the DORA test, so a second, separate test is not required in the same cycle. The key condition is that the test was run under a valid TIBER-EU implementation and that the TLPT authority treats it as a TIBER authority for that test. If the test covered only part of your ICT estate or was run by a different authority, confirm with your competent authority whether it counts toward your DORA obligation.
What does the entity need to provide for a TIBER-EU test?
The entity must own the test and provide the people, systems and information that make it work. In practice this means a board-level sponsor, a control team that manages the test day to day, blue team staff who detect and respond, access to the systems in scope, and a list of critical or important functions and their supporting ICT assets. You will also need contracts that allow testing at your ICT suppliers where their systems are in scope. The authority can confirm what it expects during the preparation phase, and the test manager will review your scoping and procurement choices.
Can a voluntary test outside DORA serve the same purpose?
Yes, a voluntary TIBER-EU test can give you the same kind of evidence about your detection and response capability as a DORA test, and TIBER-EU can be used by entities outside DORA's scope and in other critical sectors. A voluntary test does not discharge a DORA TLPT obligation unless your competent authority accepts it as such. Whether a voluntary test is worth running depends on your sector, your authority's programme and your own risk goals, so confirm with your national authority whether it runs voluntary tests for your type of entity.
Who confirms that a test counts for DORA and TIBER-EU?
The competent authority and the TIBER authority confirm it, not your provider. The authority issues the attestation at the end of the test, and that attestation supports mutual recognition of tests between authorities under DORA Article 26(7), which the ECB says reduces the burden on entities and authorities. Neither threat intelligence providers, red team firms nor a consultant can issue this confirmation. Ask your authority in writing which documents it will accept as evidence of a compliant test.
What should a buyer look for when hiring outside help for a test?
Start with the authority's rules, then check whether a provider can meet them. Ask for a written scope, the roles the provider will take, and how it handles independence and conflict rules. DeployOpen plans and runs security testing inside the client's own environment and prepares systems and evidence for compliance assessments, but it does not issue attestations or reports, which only the authority or an independent assessor can do. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen prepares systems and evidence for a TLPT
DeployOpen works on the systems and evidence side of a TIBER-EU or DORA threat-led test, not on the test itself. We plan, implement and document self-hosted open-source platforms inside your own infrastructure so your control team and blue team have what they need, while the authority, the threat intelligence provider and the red team testers carry out their roles.
How we scope
- Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
- The written scope lists which systems, environments and supporting controls are prepared for the flags under test.
- We confirm with you which evidence the control team and test manager will need at each TIBER-EU or DORA phase.
How we build
- We implement and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- We configure logging, monitoring and detection sources so blue team activity during the red team test can be reconstructed.
- We document configurations, access paths and change records in a form that supports the red team and blue team test reports.
How we hand over
- You receive documentation, runbooks and evidence packs that your team owns and can present to the test manager.
- We prepare the systems and records; only the authority, the independent auditors or assessors issue any report or attestation.
- Handover includes a walkthrough so internal staff can operate and explain the prepared environment after the engagement ends.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial engagement.
- Retainers can cover maintenance of the prepared platforms between tests, which matters given the 3-year interval the framework treats as the norm.
- Ask us to confirm in the quote which support, testing and documentation tasks sit inside the fixed scope and which sit in a retainer.

