TIBER-EU vs DORA threat-led penetration testing: which applies to you?
If your competent authority has designated your entity for threat-led penetration testing, DORA TLPT is a legal obligation, and TIBER-EU is the ECB framework that structures how that test is run. If you have not been designated, the test is voluntary and TIBER-EU is one way to run it. The first question to answer is therefore not which framework to pick, but whether your authority has identified you. Ask your competent authority directly and get the answer in writing, because the designation decides whether the test is required, how often it recurs, and who oversees it. Under DORA Article 26, designated entities must test at least every 3 years, and the Delegated Regulation (EU) 2025/1190 lists categories such as G-SII and O-SII banks that authorities generally require to test unless their own assessment says otherwise.
If you are designated, plan around DORA's requirements first and use TIBER-EU as the working method. The January 2025 TIBER-EU update aligned the framework with the DORA TLPT standards and made purple teaming mandatory, so one well-run test can serve both the regulatory obligation and the TIBER-EU process. Confirm with your authority whether it accepts a TIBER-EU test as meeting DORA, and whether it will issue the attestation that supports mutual recognition under Article 26(7). If you are not designated but want an intelligence-led exercise against live production systems, a voluntary test can follow the TIBER-EU structure without the regulatory consequences. Agree in writing with your provider which elements you are adopting, such as external threat intelligence, minimum scenarios and the control team arrangement, because a voluntary test does not carry an authority attestation.
Combining the two makes sense when your authority designates you and you also operate across several EU jurisdictions, or when you already run a TIBER-EU exercise and want DORA evidence from the same cycle. Check the scenario count, the active testing period and the tester experience requirements in Delegated Regulation (EU) 2025/1190 before you commit to a scope, since these set the minimum shape of the test. Ask any provider to show how its testers meet the manager and tester experience rules and how its threat intelligence is sourced, and treat the answers as part of your procurement file. Cost and duration depend on scope, scenarios and tester time, so request a fixed-scope quote that lists each phase, deliverable and recurring element separately.
How TIBER-EU and DORA TLPT differ on scope, rules and proof
This table compares the two regimes factor by factor, from legal status to attestation. Read the TIBER-EU column as the ECB's voluntary framework and the DORA column as the binding requirement that applies to entities designated by their competent authority. The main takeaway is that the January 2025 TIBER-EU update aligned the two, so a well-run test can often be built to serve both.
| Factor | TIBER-EU (ECB framework, January 2025) | DORA TLPT (Regulation 2022/2554 and Delegated Regulation 2025/1190) |
|---|---|---|
| Legal status | Voluntary framework adopted by national authorities and applied by the ECB | Mandatory for entities identified by their competent authority under Article 26 |
| Who must test | Entities that a national authority or the ECB invites or selects to participate | Entities the authority identifies, plus listed categories such as G-SII and O-SII banks, large payment institutions and central counterparties unless their assessment says otherwise |
| Scenario count and non-threat-led limits | Scenarios are set through the threat intelligence and scoping process with the test authority | At least three scenarios, of which at most one may be non-threat-led |
| Minimum active testing duration | At least 12 weeks of active testing within the test phases | Active red team testing of at least 12 weeks |
| Weekly reporting | Progress is managed through the test phases and control team governance | Progress reports at least weekly during active testing |
| Tester experience requirements | Testers must meet the provider requirements set by the national authority or ECB | Red team manager with at least 5 years of experience and at least two testers with at least 2 years each |
| Internal versus external testers | External providers are the norm, with the authority setting its own rules on internal use | Internal testers need prior approval, external testers are required every third test, and significant credit institutions may use only external testers |
| Threat intelligence sourcing | Threat intelligence is produced for the test, with the framework setting the expected provider role | The threat intelligence provider must be external to the financial entity |
| Purple teaming | Mandatory since the January 2025 update | Not stated as a separate requirement in the regulation text supplied, so confirm with your authority how it expects collaborative review |
| Test outcome | Produces no pass or fail result | Results feed the authority's assessment of the entity's resilience |
| Attestation and mutual recognition | Test authority attestation is used within the TIBER-EU process and national framework | Under Article 26(7), the authority's attestation at the end of a test allows mutual recognition between competent authorities |
Who must run threat-led penetration testing under DORA
The DORA threat-led penetration testing obligation applies only to entities that their competent authority has identified, and it is not a blanket requirement for every financial firm. Under DORA Article 26, identified entities must carry out threat-led penetration testing at least every 3 years. The identification decision sits with the competent authority, so your first task is to establish whether you have been identified, not to assume the requirement from your sector label alone. If you have not received a written notice, ask your competent authority directly whether you are in scope and when the next testing cycle would start.
Delegated Regulation (EU) 2025/1190 Article 2(2) sets out a list of entities that TLPT authorities should require to test, unless their own assessment concludes otherwise. The list includes G-SII and O-SII banks, payment and e-money institutions whose payment transaction volume exceeded EUR 150 billion in each of the 2 preceding years, central securities depositories and central counterparties. Membership of a listed category is therefore a strong signal, but the authority can still waive the requirement after its assessment. Check the regulation text in the Delegated Regulation (EU) 2025/1190 on EUR-Lex and confirm with your authority how the transaction volume test is measured for your entity.
Confirm three things in writing before planning budget or vendor selection: whether you are identified, what your next test window is, and whether the authority has granted or is considering a waiver. If you are a group entity, confirm which legal entity is identified and whether group-level testing can cover subsidiaries. A voluntary test under TIBER-EU may still be useful for firms outside the list, but it does not carry the same supervisory consequences, so label it as voluntary in your governance documents.
Scenario and duration rules: how the two regimes compare in practice
Under Delegated Regulation (EU) 2025/1190, a threat-led penetration test for an entity designated by its competent authority must run at least three TLPT scenarios. At most one of those scenarios may be non-threat-led, so the bulk of the test has to be built on threat intelligence about actors who would plausibly target the entity. The scenario set is therefore a regulatory deliverable, not a design choice made during the test.
- Minimum scenario count: plan for at least three scenarios before the test begins, each tied to a documented threat actor profile.
- Non-threat-led allowance: at most one scenario may be non-threat-led, which leaves little room for generic exercises to fill the test.
- Critical live production systems: scenarios target live production, so the scope must name the systems and the controls that protect them.
- Authority involvement: the competent authority reviews the test design and the scenario set, which adds approval steps to the calendar.
- Threat intelligence source: under DORA the threat intelligence provider must be external, which affects who you contract and when.
Ask your competent authority how it expects scenario documentation to be presented and which steps it will review before testing starts.
Delegated Regulation (EU) 2025/1190 requires active red team testing of at least 12 weeks, and the regulation requires at least weekly progress reports during that window. The active phase is the period in which testers attempt intrusion against live systems, so the duration figure is a floor. Preparation and closure work sit outside those 12 weeks, and the total calendar for a test is longer than the active phase alone.
- Active phase floor: at least 12 weeks of active red team testing under Articles 10 and 11.
- Weekly progress reports: the test team must report progress at least weekly, so reporting capacity has to be staffed for the whole active phase.
- Outside the active window: preparation, scope agreement and closure all need their own time and people.
- Live system coordination: the operations team must be ready for production activity throughout the active phase, not only at its start.
- Schedule risk: a delay in approvals or scope changes can push the start date, so build calendar buffer with the authority timeline in view.
Confirm with your authority and your test provider how the 12-week window is counted and when weekly reports are due.
TIBER-EU, in the framework dated January 2025, runs threat intelligence-based red team tests through preparation, testing and closure phases, with at least 12 weeks of active testing. The ECB states these tests produce no pass or fail result. The framework is voluntary in most jurisdictions but is applied by the ECB and adopted in 21 countries as of October 2026, so the planning question is which national authority you answer to.
- Phased structure: preparation, testing and closure are separate phases, each with its own deliverables.
- No pass or fail: results describe what happened and what defenders saw, so the output is a remediation and learning plan.
- Active testing minimum: at least 12 weeks of active testing, matching the DORA floor.
- National adoption: the authority that runs your test depends on your jurisdiction, so confirm it before scoping.
- Voluntary status: where a national authority has not made TLPT mandatory for you, the framework is a choice, and the cost and governance commitment should be agreed in writing.
Check with your national authority whether TIBER-EU is mandatory, optional or applied for your entity.
The January 2025 update made purple teaming mandatory in TIBER-EU and renamed the White Team the Control Team. The purple teaming step asks testers and defenders to work together on the techniques used, so the blue team learns which detections fired and which did not. This changes the shape of the exercise: collaboration happens during the test, not only in a debrief after it.
- Mandatory purple teaming: the January 2025 update made this step required, so plan time for joint technique reviews.
- Control Team role: the former White Team is now the Control Team, which manages the test from the inside and keeps it safe for live systems.
- Defender involvement: blue team staff need time away from routine operations to take part in joint reviews.
- Detection validation: the output should show which techniques were detected, logged or missed, so fixes target real gaps.
- Role clarity: document who sits on the Control Team, who can stop the test, and how escalation works.
Ask your test provider how it runs purple teaming alongside the active phase and how it records detections for supervisors.
The January 2025 TIBER-EU update aligned the framework with the DORA TLPT standards, which means a well-run TIBER-EU test can be planned to meet the DORA requirements at the same time. Where both apply, the scenario, duration and tester rules should be designed once against the stricter reading, not run as two separate exercises. The authority attestation at the end of a test is what supports mutual recognition between competent authorities under Article 26(7) of DORA.
- Single design: build scenarios, duration and reporting to satisfy both regimes in one plan.
- Attestation planning: the authority's attestation at the end of the test supports recognition elsewhere, so the closure phase needs its own deliverables.
- Tester requirements: the DORA tester rules, including experience levels for the red team manager and testers, apply regardless of the framework label.
- Cadence: the three-year cycle in DORA Article 26 sets how often a designated entity tests, so plan the next test before this one closes.
- Documentation trail: keep scenario rationale, weekly reports and Control Team records in one evidence set.
Confirm with your authority whether a single TIBER-EU test will be accepted as your DORA TLPT, and in what form.
Tester requirements: what the red team manager and testers must have
DORA and the TLPT technical standards set minimum experience levels, sourcing rules and approval steps for the people who run a threat-led test. These cards cover who must be on the team, who may be inside it, and which rules your competent authority will check, so you can plan staffing before the test is scoped.
Red team manager experience
Delegated Regulation (EU) 2025/1190 Article 7 requires a TLPT red team manager with at least 5 years of experience. The manager directs the test end to end, so this is the one role where seniority is set in law rather than left to the provider. Ask each provider for the named manager's CV and dated evidence of that experience, and confirm whether your authority wants the manager to be internal, external or either.
Tester experience minimum
The same Article 7 requires at least two testers, each with at least 2 years of experience. These are the people who build and execute attack paths against live production systems, so the minimum applies to the hands-on team, not only the manager. Check that the named testers meet the threshold individually, and that a substitute during a 12-week active test window meets it too.
Internal tester approval
Under the DORA threat-led framework, internal testers need prior approval before they can take part. Approval is a gate, not a formality: it is the point where your authority checks independence, competence and conflicts with the systems in scope. Agree the approval route, the evidence you must submit and the timing with your authority before you name anyone internal.
External threat intelligence provider
The threat intelligence provider must be external to the financial entity. The provider supplies the tailored intelligence that shapes the scenarios, so its independence affects whether the scenarios reflect real threat actors rather than internal assumptions. Ask the provider to show how it sources and validates intelligence, and confirm how your authority defines acceptable independence.
External tester rotation
External testers must be used at least every third test, so the same internal team cannot run every exercise. This rule protects against familiarity and blind spots building up over repeated tests. Plan a rotation schedule across your test cycle, and confirm with your authority how it counts tests, especially when a test is shared across entities or jurisdictions.
External-only testers for significant credit institutions
Significant credit institutions may use only external testers. For these firms, the internal team's role shifts to coordination, control and receiving results, while attack execution sits with providers that are not part of the institution. Confirm early whether your institution is classed as significant, since that single fact changes your staffing model, your procurement timeline and the number of external firms you need to qualify.
Attestation and mutual recognition: what a regulator-accepted test proves
Under DORA Article 26(7), the competent authority that oversees a threat-led penetration test issues an attestation at the end of the test, and that attestation is what allows mutual recognition between competent authorities. In practice, a financial entity that completes a TLPT under one authority can present the attestation to other authorities instead of repeating the exercise for the same purpose. The attestation is a regulator's statement that the test was carried out under the prescribed process. It is not a statement that the entity is secure, and it is not a pass or fail grade. The ECB states that TIBER-EU tests produce no pass or fail result, so a clean attestation says nothing about how many findings the red team achieved or how many detections the blue team made.
Before you rely on an attestation, confirm what your competent authority will issue, in what form, and whether it lists the scope, the scenarios and the test dates. Ask your authority whether the attestation covers the live production systems, the threat intelligence inputs and the purple teaming phase, since these are the elements an authority reviewing your test later will look for. Also confirm whether your authority's process treats a test run under TIBER-EU as one that meets the DORA requirement, as the January 2025 alignment is designed to allow. The attestation proves the process was followed and overseen. Your own findings, remediation records and detection improvements still need to be documented separately so that the evidence is useful to the next supervisor who asks.
DeployOpen does not issue attestations, certifications or audit reports for TLPT or any other test. The attestation comes from the authority that oversees the test, and any independent review of the test process is performed by the bodies that the authority designates. DeployOpen's role is to support the parts of the engagement that the entity controls, such as preparing the scope documentation, the rules of engagement, the evidence packages and the remediation tracking that the authority may request. When you scope any supporting work, ask the provider to state in writing which deliverables feed the authority's review and which are internal records, so that no one assumes a supplier's report carries regulatory weight it does not have.
What each approach finds and misses
A TIBER-EU or DORA TLPT exercise is strong on end-to-end attack paths and detection gaps, and narrow by design. The cards below set out what these tests surface, what they leave out, and what to check before treating one test as a full picture of your exposure.
End-to-end attack paths to live systems
A TLPT test is built to chain techniques from initial access to a defined objective against the entity's critical live production systems. That is where it finds weaknesses that single-issue scans miss, such as a low-risk foothold that leads to a payment or settlement system. Check whether the scenarios your testers were given reach the systems that would matter most in a real incident, and whether the attack paths were tested as chains rather than as isolated findings.
Detection and response gaps
Purple teaming is mandatory under the January 2025 TIBER-EU framework, so the exercise shows which techniques the defenders saw, which they missed, and how fast they responded. The output is a list of logging and alerting gaps tied to specific techniques. Ask who on your side will own the fixes and how the detections will be retested after the exercise closes.
Scope excluded by the control team
The White Team, renamed the Control Team in the January 2025 update, approves the scope and can exclude systems, people or techniques for safety or business reasons. Anything excluded is untested by definition, even if it is exposed. Ask for the written list of exclusions, the reasons recorded for each, and whether a separate assessment covers the excluded areas.
Limits of non-threat-led scenarios
Under the TLPT rules, at most one of the minimum three scenarios may be non-threat-led, which allows a scenario built around a known weakness rather than an intelligence-based threat actor profile. That scenario tests a path you already suspect, so it does not show what an unknown actor would choose. Ask which scenario is non-threat-led and what evidence supports its selection.
Findings outside tested scenarios
A TLPT test shows what happened in the scenarios it ran. It does not certify that the rest of the estate is secure, and it does not replace scheduled penetration tests, vulnerability scanning or application testing. Treat a clean result as evidence for the tested paths only. Ask for a coverage map that lists the systems, identities and techniques touched, so gaps are visible for the next planning cycle.
Questions buyers ask before choosing a threat-led test
Can a voluntary firm use TIBER-EU if DORA does not require it?
Yes, a firm outside the designated group can use the TIBER-EU framework on a voluntary basis, although the mandatory DORA TLPT regime applies only to entities identified by their competent authority. The framework itself is the ECB's published method for threat intelligence-based red team tests, and the January 2025 update aligned it with the DORA TLPT standards. Confirm with your national competent authority or the TIBER-EU authority in your jurisdiction whether a voluntary test is accepted for your purposes, and whether your entity would need the same attestation and tester conditions.
How long does a threat-led penetration test take?
Under the Delegated Regulation (EU) 2025/1190, active red team testing must run for at least 12 weeks, with at least weekly progress reports. That 12-week figure is the minimum for active testing only. The full engagement also includes preparation and closure phases, and the total calendar time depends on how long the threat intelligence and scenario work takes and how quickly your control team can approve the scope. Ask any provider for a written timeline that separates preparation, active testing and closure, and confirm how the minimum applies to your entity.
What does a threat-led test need from our internal staff?
Expect a dedicated control team and named owners across security operations, IT operations and business continuity, because the test runs against live production systems and must be coordinated without alerting the testers' targets prematurely. TIBER-EU renamed the White Team the Control Team in its January 2025 update, and that group governs scope, safeguards and escalation. Staff also need time for the mandatory purple teaming and for reviewing weekly progress. Ask the provider which roles they expect you to fill, how many hours of participation they assume, and how those hours are recorded in the quote.
Can our own team run a threat-led test without outside testers?
Only under strict conditions. Under the DORA threat-led penetration testing rules, internal testers need prior approval from the authority, the threat intelligence provider must be external, and external testers must be used every three tests. Significant credit institutions may use only external testers. Your internal team may therefore support preparation, control and purple teaming, but it cannot simply run the red team itself unless your authority has approved it. Check the current approval process with your competent authority before planning staffing.
What drives the cost of a threat-led test?
Cost is driven by who is paid for what: the external red team, the external threat intelligence provider, your internal control team time, and the remediation work that follows. Costs rise with the number of scenarios, since the regulation requires at least three with at most one non-threat-led, with the length of active testing, with the number of live production systems in scope, and with the depth of purple teaming. Most of the cost is one-time for the engagement, while retesting and ongoing exercises recur. DeployOpen does not publish prices. Ask each provider for a written quote that itemizes these components against the agreed scope.
Does a TIBER-EU test satisfy the DORA threat-led penetration testing requirement?
It can, because the TIBER-EU framework was aligned with the DORA TLPT standards in January 2025, so one well-run test can serve both. Satisfaction depends on the authority: under DORA Article 26(7), the competent authority's attestation at the end of a test enables mutual recognition between authorities. Confirm with your competent authority that the test meets the requirements in Regulation (EU) 2022/2554 and Delegated Regulation (EU) 2025/1190 and that they will accept the TIBER-EU attestation. The ECB notes that these tests produce no pass or fail result, so set expectations with the board accordingly.
Who is accountable for the outcome if live systems are affected?
The entity remains accountable for its production systems, so the written rules of engagement and the control team's escalation paths decide what happens if a test causes disruption. Ask who holds the authority to halt the test, how safeguards protect critical services, and how the provider documents each action. Confirm these terms in the signed scope and in your contract with the threat intelligence provider and red team, not only in the proposal.
How to combine a TLPT with other testing in one program
The sequence below shows how a designated financial entity can layer a threat-led test on top of the scans and penetration tests it already runs, so each exercise feeds the next instead of duplicating it. The order also keeps the regulator in the loop at the points where the rules require it.
Confirm designation with the competent authority
Start by establishing whether your entity has been identified for threat-led penetration testing. Under DORA Article 26, the competent authority makes that identification, and Delegated Regulation (EU) 2025/1190 describes the entities that authorities generally require to test unless their own assessment says otherwise. Your compliance or regulatory affairs lead owns this step and should obtain the decision in writing. It is done when the entity holds the authority's designation and knows the required testing cycle, which DORA Article 26 sets at least every 3 years.
Inventory existing scans and penetration tests
Map every scheduled vulnerability scan, network test, application test and penetration test the entity already runs against the test types listed in DORA Article 25(1). This includes vulnerability assessments and scans, open source analyses, scenario-based tests and penetration testing. The security assurance team should record the owner, scope, frequency and last result for each item in one register. The step closes when every test type has a named owner and any gaps against Article 25 are logged for planning.
Keep scheduled scanning and periodic testing running
Confirm that routine scanning and periodic penetration testing continue on their own schedules. NIST SP 800-115 suggests regularly scheduled network and vulnerability scanning interspersed with periodic penetration testing, and the TLPT does not replace that cadence. The security operations lead should make sure the TLPT calendar is added beside these existing schedules rather than substituted for them. The check is a single calendar in which routine tests and the TLPT appear together without one cancelling another.
Scope the TLPT around critical live systems
Use the register from the earlier steps to select the critical or important functions that the TLPT will cover, focusing on live production systems that support them. Delegated Regulation (EU) 2025/1190 requires at least three TLPT scenarios, of which at most one may be non-threat-led, so the scope workshop should agree those scenarios with the threat intelligence provider and the control team. Document the scope, the systems in and out, and the rules of engagement in writing. The step is complete when the scope and scenarios are signed off by the entity's management and recorded for the authority.
Feed findings from routine tests into threat intelligence
Pass the results of existing scans and penetration tests to the threat intelligence work that informs the TLPT scenarios. Findings that show recurring weaknesses in critical systems can shape the attack paths the external threat intelligence provider develops. The threat intelligence lead should record which routine findings were used and why. The output is a documented link between past test results and the TLPT scenario set, so the authority can see that the exercise reflects the entity's actual exposure.
Run the TLPT and secure the authority attestation
Carry out the active red team test with the required tester composition and the minimum active period set by Delegated Regulation (EU) 2025/1190, with weekly progress reports. Track findings and remediation against the agreed scope. Once the test closes, the competent authority issues its attestation, which under DORA Article 26(7) supports mutual recognition between authorities. The output is the closing report and attestation file, and the step is done when both are stored with the entity's audit evidence.
Schedule purple teaming and follow-up tests
After the TLPT, run purple teaming sessions with the defenders to confirm which techniques were detected, logged and answered. TIBER-EU made purple teaming mandatory in its January 2025 update, so the same sessions serve both frameworks. Use the results to set the next scheduled scans and penetration tests, targeting the detections and controls that failed. The step closes when a follow-up plan names the tests, owners and the detections being validated, and it feeds the next TLPT cycle.
How DeployOpen scopes, delivers and supports threat-led testing
DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted open-source platforms inside the client's own infrastructure, and runs security testing as part of that work. For TIBER-EU vs DORA threat-led penetration testing, we help teams work out which regime applies, what the written scope must cover and how the test evidence is prepared. We do not issue attestations; independent auditors and the competent authority do.
How we scope
- Confirm with your competent authority whether your entity is designated for threat-led testing, since the scope depends on that determination.
- Agree in writing which critical live production systems, scenarios and tester roles fall inside the test before work starts.
- Document the rules of engagement, including who approves internal testers and how the external threat intelligence provider is engaged.
How we build
- Prepare the test environment, control team arrangements and reporting cadence so the active testing window matches the agreed plan.
- Support purple teaming steps and detection validation so blue team findings are recorded alongside red team activity.
- Keep evidence of each phase, scenario and decision so the file is ready for supervisor and attestation review.
How we hand over
- Deliver a written report covering scenarios run, techniques used, detections observed and remediation priorities for owners to act on.
- Provide a closure file that maps findings to the phases and requirements of the applicable framework for your reviewers.
- Walk the internal team through the evidence so they can repeat or extend the exercise between formal test cycles.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement closes.
- Help plan the next threat-led cycle, including scenario refreshes and tester rotation, against the written scope and timeline.
- Quote each phase from its written scope, so cost follows the agreed deliverables rather than a published price list.
