Threat-led penetration testing (TLPT) asks whether a capable, named type of attacker could reach your critical functions in live production without your defenders stopping them, and regulators now require some firms to prove the answer. Unlike a scoped penetration test, a TLPT is built from targeted threat intelligence, runs for months against live systems, keeps the defenders unaware, and ends with a remediation plan that a supervisor follows up. This guide explains how the main schemes work (TIBER-EU, DORA TLPT under Delegated Regulation (EU) 2025/1190, the Bank of England's CBEST, Hong Kong's iCAST and Singapore's AASE), how to govern and scope a test, how to keep it safe, and how to turn findings into remediation. It is written for CISOs, testing programme owners, control team leads and risk functions. It covers governance and process only: no attack techniques, tooling or payloads.
Key takeaways
- TLPT is a governance exercise as much as a technical one. The scheme defines who knows about the test, who can halt it, who signs off scope and who attests the result, and those decisions determine whether the test is valid.
- DORA has made TLPT a legal obligation for selected EU financial entities. Article 26 of Regulation (EU) 2022/2554 requires TLPT at least every three years for entities the authority identifies, and Delegated Regulation (EU) 2025/1190, in force since 8 July 2025, sets the method.
- Timelines are long and fixed. Under the RTS, active red team testing lasts at least 12 weeks, and reports, replay and the remediation plan follow on deadlines measured in weeks after it ends.
- Safety depends on the control team. A small, secret control team manages risk, escalations and leg-ups, and must be able to pause or stop the test at any time without exposing it.
- The value is in remediation, not the attack narrative. Every scheme here is explicitly not pass or fail. What supervisors follow up is the remediation plan, with root causes, owners and dates.
What threat-led penetration testing is, and where it sits
DORA Article 3(17) defines TLPT as a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as genuine threats, delivering a controlled, intelligence-led red team test of a financial entity's critical live production systems. Three properties separate it from other testing:
- Threat-led: scenarios come from a targeted threat intelligence report on the entity, not from the tester's preferred approach. The RTS requires at least three scenarios, of which no more than one may be non-threat-led (Art. 10(3) and 10(4)).
- Live and critical: the test targets live production systems supporting critical or important functions (CIFs), including people and processes, and not a lab copy.
- Unannounced: the blue team (security operations, incident response and supporting providers) is not told. Their real detection and response is part of what is tested.
| Activity | Driver | Defenders aware? | Typical duration | Main output |
|---|---|---|---|---|
| Vulnerability scan | Asset list | Yes | Hours | List of known weaknesses |
| Penetration test | Agreed scope | Usually | Days to weeks | Exploitable findings in scope |
| Red team exercise | Objectives | No | Weeks | Attack path and detection gaps |
| Threat-led penetration test | Targeted threat intelligence plus regulator scheme | No | Typically 9 to 12 months end to end | Reports, remediation plan, attestation |
For the general practice of adversary simulation see the Red Teaming Guide; for scoped technical testing see the Penetration Testing Guide. This guide focuses on what the regulated, intelligence-led schemes add.
The schemes compared
| Scheme | Owner | Status and basis | Key features |
|---|---|---|---|
| TIBER-EU | European Central Bank and national central banks | Published May 2018; updated in 2024 to align with the DORA RTS; guidance documents issued in 2025 versions | Control team, TIBER Cyber Team with test manager, external threat intelligence provider, attestation supporting mutual recognition; can be used outside finance |
| DORA TLPT | EU law, run by national TLPT authorities | Article 26 and 27 of Regulation (EU) 2022/2554; RTS in Delegated Regulation (EU) 2025/1190 (adopted 13 February 2025, in force 8 July 2025) | Mandatory for identified entities at least every three years; methodology based on TIBER-EU; statutory deadlines and tester requirements |
| CBEST | Bank of England, PRA and FCA | In use since 2014; implementation guide 2024 edition | Control Group, Threat Intelligence and Penetration Test service providers accredited by the Bank and CREST members; regulator-supervised remediation |
| iCAST | Hong Kong Monetary Authority | Part of the Cyber Resilience Assessment Framework (C-RAF) under the Cybersecurity Fortification Initiative, circular of 24 May 2016 | Intelligence-led simulation on top of conventional penetration testing, for authorised institutions targeting intermediate or advanced maturity |
| AASE | Association of Banks in Singapore | Red Team Adversarial Attack Simulation Exercises Guidelines, September 2024 edition | Exercise Director, Exercise Working Group, trusted agents, concessions; suggested at least every 24 months |
Which EU entities must do TLPT
Article 2 of the RTS sets the criteria authorities use. They include credit institutions identified as G-SIIs or O-SIIs (or part of one), payment and electronic money institutions above EUR 150 billion of payment transactions in each of the two preceding years (or, for e-money institutions, above EUR 40 billion outstanding e-money), central securities depositories, central counterparties, trading venues with the largest national or a Union-level turnover share above 5%, and insurance and reinsurance undertakings above size thresholds such as EUR 1.5 billion gross written premium. Authorities can exclude a listed entity where its impact, financial stability concerns or ICT risk profile do not justify TLPT, and under DORA Art. 26(8) the decision on which entities must test rests with the authority, so treat the thresholds as indicators rather than a guarantee either way. Microenterprises are outside Article 26. For the wider DORA testing programme that sits beneath TLPT, see the DORA Guide.
Roles and governance
The names differ by scheme but the structure is the same: a small group at the entity runs the test in secret, an authority oversees it, and external providers supply intelligence and attack capability.
| Function | TIBER-EU / DORA | CBEST | AASE |
|---|---|---|---|
| Runs the test inside the entity | Control team and control team lead (RTS Art. 4) | Control Group, led by an executive sponsor and Control Group Co-ordinator | Exercise Working Group |
| Decides to pause or stop | Control team, which "may at any time order a temporary or complete halt" | Control Group | Exercise Director (proceed, pause, divert or terminate) |
| Authority oversight | TLPT Cyber Team; a test manager and at least one alternate per test (RTS Art. 3) | Regulator (PRA, FCA or FMID) | Industry guideline; no authority role in the document |
| Threat intelligence | Threat intelligence provider, always external | Threat Intelligence service provider (TISP) | Threat intelligence provider |
| Attack | Red team testers, external by default | Penetration Test service provider (PTSP) | Attacker (red team) |
| Defends, unaware | Blue team | Firm's defenders | Defender (blue team) |
- Management body sign-off: under RTS Art. 9(6) the scope specification document is approved by the entity's management body. Make this a board or executive committee decision, not a delegated security approval.
- Secrecy: control team members are on a need-to-know basis and may sign NDAs; TIBER-EU requires stakeholders to use a code name for the entity. If the blue team learns of the test, its integrity is compromised and the attestation may be withheld.
- Consult before involving defenders: under RTS Art. 4(2)(b) the control team must consult test managers before involving any blue team member.
- Back-up roles: the TIBER-EU control team guidance recommends a designated back-up control team lead at all times. Months-long tests outlast holidays and resignations.
The lifecycle and its deadlines
Under TIBER-EU and the DORA RTS a test runs in three phases. The figures below come from the 2025 TIBER-EU framework and Delegated Regulation (EU) 2025/1190; CBEST's indicative timings are shown for comparison.
| Step | DORA RTS / TIBER-EU | CBEST (indicative) |
|---|---|---|
| Initiation documents | Within 3 months of notification (Art. 9(2)) | Initiation about 6 weeks |
| Scope specification document | Within 6 months of notification, management body approval (Art. 9(6)); preparation phase no longer than 6 months | Included in initiation |
| Targeted threat intelligence | Indicatively 4 to 6 weeks; at least 3 scenarios (Art. 10) | About 10 weeks, with validation workshop |
| Red team test plan | Indicatively 2 to 3 weeks | Part of penetration testing phase |
| Active red team testing | At least 12 weeks, with tester reporting at least weekly (Art. 11(5), 11(7)) | Penetration testing about 14 weeks |
| Red team test report | Within 4 weeks after active testing ends (Art. 12(2)) | Penetration Test Report |
| Blue team report; replay and purple teaming | Both no later than 10 weeks after active testing ends (Art. 12(4), 12(5)) | Detection and response assessment |
| Test summary report | Within 8 weeks of the authority's notification that reports meet requirements (Art. 12(7)) | Thematic analysis by regulator |
| Remediation plan | Within 8 weeks of that same notification (Art. 13(1)) | Drafted on regulator template, then supervised (often 6 to 12 months or longer) |
| Attestation | Issued by the authority, content in RTS Annex VIII (Art. 14; DORA Art. 26(7)) | Not an attestation scheme |
How to implement a TLPT programme
- Prepare before notification. Map CIFs to supporting systems, processes and ICT third-party providers (DORA Art. 26(2) requires this mapping, including outsourced services). Confirm budget for a year-long engagement.
- Form the control team. Appoint the control team lead and back-up, a small number of senior people who can authorise business decisions, and legal and risk representation. Agree secure communication channels and the code name.
- Procure providers. Check the threat intelligence provider and red team testers against RTS Art. 7 and DORA Art. 27, or the CBEST accreditation requirements. Engage early: capable providers are booked months ahead.
- Write the scope specification. List each CIF, its supporting systems and at least one flag per system relating to confidentiality, integrity or availability. TIBER-EU guidance suggests no more than 10 CIFs per test.
- Agree the risk assessment and rules of engagement. RTS Art. 5 requires risks to be assessed in preparation and reviewed throughout. Use the Red Team Rules of Engagement Template as the working document.
- Validate threat intelligence and scenarios with the authority, then approve the red team test plan.
- Run active testing with weekly reporting, a logged decision for every leg-up, and an always-available control team lead.
- Close properly. Inform the blue team, write the blue team report, run the replay and purple teaming, and confirm that all tester artefacts and accounts have been removed.
- Remediate and track. Build the remediation plan with root causes, owners, priorities and dates, and report progress to the management body until closure.
Scoping: critical functions, flags and third parties
- Start from functions, not systems: a CIF is a business service whose disruption would materially impair the entity. Work back to the applications, identity systems, networks, people and suppliers that support it. Missing an upstream dependency, such as the directory or a privileged access platform, produces a test that looks clean but proves little.
- Set flags that mean something: a flag is the evidence that an objective was reached, for example demonstrating the ability to alter a payment instruction or read a customer data store. The ABS AASE guidelines note that high-risk actions such as payment submissions can be demonstrated on a documented replica instead of production.
- Bring ICT third parties in: DORA Art. 26(3) requires the entity to ensure an in-scope ICT third-party provider participates, and the entity stays fully accountable. Where participation would affect the provider's other customers, Art. 26(4) allows a pooled TLPT directed by one designated entity. Put participation clauses in contracts now; see the Third-Party Risk Management Guide.
- Verify ownership of every target: confirm that each domain, IP range and tenant in scope belongs to the entity or a provider that has consented. The Anthropic Claude evaluation incidents included an automated tester attacking a real company with a name similar to its intended target, which is exactly the error ownership checks prevent.
Provider requirements and internal testers
| Requirement | Threat intelligence provider | External red team testers |
|---|---|---|
| References (RTS Art. 7(1)(c), (d)) | At least 3 from previous assignments | At least 5 from previous assignments |
| Assigned team (Art. 7(1)(e), (f)) | Manager with at least 5 years of threat intelligence experience plus a member with at least 2 years | Manager with at least 5 years plus at least 2 testers with at least 2 years each |
| Insurance (Art. 7(1)(b); DORA Art. 27(1)(e)) | Professional indemnity covering misconduct and negligence | Same |
| Standing (DORA Art. 27(1)) | Highest suitability and reputability, proven capability, certification by an accreditation body or adherence to formal codes of conduct, independent assurance of sound risk management | |
| CBEST equivalent | Bank-accredited CREST member with a CREST Certified Threat Intelligence Manager (CCTIM) | Bank-accredited CREST member with a CCRTM or Cyber Scheme Red Team Manager (CSRTM), plus a CREST Certified Red Team Specialist (CCRTS) |
Internal testers: DORA Art. 26(8) allows internal testers but requires external testers at least every third test, and significant credit institutions may use only external testers. Art. 27(2) adds authority approval, sufficient dedicated resources, conflict-of-interest controls and an external threat intelligence provider. RTS Art. 15 requires a policy for internal testers, a team of a test lead plus at least two members employed by the entity or an intra-group ICT provider for the preceding 12 months, and disclosure in the initiation, red team and summary reports.
Safety and risk management during the test
- Halt authority: the control team can order a temporary or complete halt at any time if damage is a concern. Make sure the testers' contract and plan say so explicitly.
- Escalation handling: the blue team may treat red team activity as real and escalate. The TIBER-EU control team guidance says the control team should intervene only where the escalation would cause unwanted business impact, and lists shutting down critical servers, reporting to a supervisor and filing a police report as uncontrolled escalations where the control team lead should pause, deal with it, and disclose as little as possible.
- Leg-ups: help given to testers who are blocked, approved by the control team and test manager and logged. TIBER-EU states that directly providing flags or disabling security controls should not be proposed as leg-ups, because they invalidate what is being measured.
- Real compromise: the AASE guidelines say the exercise should pause if evidence of prior compromise is found, so incident response can complete first, and that critical vulnerabilities such as internet-facing code execution should be escalated immediately.
Where identity fits
Threat intelligence for financial entities regularly features abuse of valid accounts (ATT&CK T1078) and phishing (T1566) as entry points, so identity systems, privileged access and machine credentials are usually on the attack path to a CIF. Scope identity providers, privileged access tooling and secrets stores as supporting systems. Any accounts, API keys or certificates issued to testers as leg-ups must be inventoried, time-limited, stored in a vault and revoked at closure. See the Privileged Access Management Guide and the Secrets Management Guide.
Reporting, remediation and attestation
- Red team test report: the attack path for each scenario, flags captured, leg-ups used, and the weaknesses that enabled progress.
- Blue team test report: what defenders saw, when, and what they did, mapped against the red team timeline. This is where detection and response gaps become concrete.
- Replay and purple teaming: red and blue teams walk through the attack together and test improved detections. Under the RTS limited purple teaming during active testing is a last resort, needing prior authority validation, and its time counts towards the 12 weeks (Art. 11(10)).
- Remediation plan: RTS Art. 13(2) requires, for each finding, a root cause analysis, a description of remediation with priorities and timelines, the responsible staff and the associated risks. Feed it into the vulnerability programme with agreed SLAs; see the Remediation SLAs and Vulnerability Exceptions Guide.
- Attestation and mutual recognition: under DORA Art. 26(7) the authority issues an attestation confirming the test met requirements, which allows other authorities to recognise it. The entity remains responsible for remediation regardless.
Decision guidance
- Mandated vs voluntary: if you are notified under DORA, the RTS method is not optional. If you are not, a voluntary TIBER-aligned test is still useful but can be shorter and narrower; keep the core disciplines of threat-led scenarios, secrecy and control team governance.
- TIBER-EU vs CBEST for UK and EU groups: UK-regulated firms selected for CBEST follow the Bank of England guide; EU entities follow their national TLPT authority. Coordinate early so that scope, providers and threat intelligence can be shared where authorities allow.
Detection and measurement
Log every control team decision, leg-up, halt, escalation and scope change with a timestamp; these logs feed the reports and the attestation. Metrics that show the programme is working:
- Share of scenarios in which the blue team detected activity before a flag was captured, and median time to detection.
- Number of leg-ups per scenario (falling numbers over successive tests indicate stronger preventive controls).
- Remediation plan items closed by their agreed date, tracked to the management body each quarter.
- Repeat findings: root causes from the previous test that reappear in the next one.
- Number of uncontrolled escalations and unplanned halts per test (a measure of control team effectiveness, not of defenders).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CA-8 Penetration Testing; CA-8(1) Independent Penetration Testing Agent or Team; CA-8(2) Red Team Exercises | Core testing controls TLPT satisfies |
| NIST SP 800-53 Rev. 5 | CA-2(2) Specialized Assessments; IR-3 Incident Response Testing; PM-14 Testing, Training, and Monitoring | Programme planning and testing of response |
| NIST CSF 2.0 | ID.RA-03 (threats identified and recorded); ID.IM-02 (improvements from security tests and exercises, including with suppliers); GV.SC-07 (supplier risk) | Threat intelligence input, improvement loop, third-party participation |
| CIS Controls v8.1 | Control 18 Penetration Testing | Programme-level testing safeguards |
| ISO/IEC 27001:2022 Annex A | 5.35 Independent review of information security; 8.8 Management of technical vulnerabilities | Independent assurance and remediation |
| MITRE ATT&CK | Scenario mapping, for example T1078 Valid Accounts, T1566 Phishing | Common language for scenarios and detection gaps; AASE maps attack models to ATT&CK |
Common failure patterns
- Scope by system list: scoping applications without the identity, network and supplier dependencies behind them, so the test never touches the real attack path.
- Leaky secrecy: too many people in the control team, or test details shared through ordinary ticketing and email, so defenders learn of the test and the result loses value.
- Unverified targets: testers acting on infrastructure that has not been confirmed as owned or consented, as in the Anthropic Claude evaluation incidents, where a look-alike company was attacked.
- Leg-ups that hollow out the test: handing over credentials or disabling controls to keep to schedule, which TIBER-EU explicitly discourages.
- Remediation drift: a plan accepted by the regulator and then left with owners who have no budget, so the next test repeats the same findings.
Practitioner checklist
- Map critical or important functions to systems, identity services, people and ICT third parties before any notification arrives.
- Name a control team lead and back-up, keep the team small, use a code name and secure channels.
- Check providers against RTS Art. 7 and DORA Art. 27 (or CBEST accreditation) and record the evidence.
- Get the scope specification approved by the management body.
- Agree written rules of engagement with halt authority, escalation handling, leg-up approval and data handling.
- Verify ownership of every in-scope domain, address range and tenant.
- Add TLPT participation clauses to contracts with ICT providers that support critical functions.
- Log every control team decision and leg-up during testing.
- Revoke all tester accounts and credentials and confirm artefact clean-up at closure.
- Track remediation items to closure with root cause, owner and date, reported to the board.
Standards and references
- EUR-Lex: Commission Delegated Regulation (EU) 2025/1190 on threat-led penetration testing
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience (DORA)
- European Central Bank: TIBER-EU framework and guidance
- European Central Bank: TIBER-EU Framework (2025)
- Bank of England: CBEST Threat Intelligence-Led Assessments Implementation Guide
- Association of Banks in Singapore: Red Team Adversarial Attack Simulation Exercises Guidelines
- Hong Kong Monetary Authority: Cybersecurity Fortification Initiative circular
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Red Teaming Guide · DORA Guide · Purple Teaming Guide · Red Team Rules of Engagement Template · Threat Intelligence Guide. This guide summarises threat-led penetration testing schemes and regulatory requirements and is not legal advice.