Red teaming vs threat-led penetration testing (TLPT)

Red teaming vs TLPT: which one your organization needs first

If your competent authority has not designated your entity for threat-led penetration testing, a voluntary red team can answer your board's question. If it has, the TLPT is mandatory, and a red team alone will not satisfy it. The deciding factor is designation by your competent authority under DORA, not which format your security leaders prefer. A voluntary red team is set by your own objectives, scope and rules of engagement, and it can be sized to the threats you care about most. It sits alongside the wider testing that NIST SP 800-115 describes, and it does not need to meet the authority's oversight, scenario or tester rules. Confirm your designation status in writing with your authority before you scope anything.

If you are designated, the TLPT must follow Commission Delegated Regulation (EU) 2025/1190, which sets the minimum number of scenarios, the active red team testing period, the weekly progress reporting, and the experience required of the red team manager and testers. Read the Commission Delegated Regulation (EU) 2025/1190 against your scope before you accept a provider's proposal. A red team you already run internally or through a provider may be reusable as input, but confirm with your authority whether it counts toward the TLPT rather than assuming it does.

Many organizations run both. A voluntary red team can build capability and test detection between mandated cycles, while the TLPT provides the formal, authority-recognized result. Ask your authority how it treats a voluntary exercise and whether its findings can feed the TLPT. Plan your budget and calendar around the TLPT requirements first, then decide how much additional voluntary testing your risk profile justifies.

How a commercial red team and DORA TLPT compare on scope, oversight and output

This table compares a voluntary commercial red team with the regulated threat-led penetration test that DORA requires of designated financial entities, row by row on trigger, scope, oversight and output. Read it as a checklist: where the regulation sets a floor, the buyer's own contract sets the rules for a commercial exercise. The main takeaway is that TLPT adds regulator and tester obligations on top of a red team, not a different kind of attack.

Factor	Commercial red team	DORA threat-led penetration test (TLPT)
Trigger for the test	The buyer decides, based on its own risk appetite, a board question or a control validation goal	The competent authority identifies the entity, and Article 26 requires TLPT at least every 3 years for those so identified
Who sets scope and objectives	The buyer and the provider agree scope, rules of engagement and objectives in writing; the buyer sets the rules	Scope is shaped by the entity and its authority under Delegated Regulation (EU) 2025/1190, with rules set by that framework
Threat intelligence input	Optional and set by the buyer, often drawn from the provider's or the buyer's own sources	Required external threat intelligence used to build scenarios tailored to the entity
Minimum scenarios and duration	Agreed in the contract; no regulatory minimum applies	At least three scenarios, with at most one non-threat-led, and at least 12 weeks of active red team testing (Articles 10 and 11, Delegated Regulation (EU) 2025/1190)
Tester requirements	Set by the buyer's procurement and the provider's own staffing and certifications	Red team manager with at least 5 years' experience and at least two testers with at least 2 years' experience each (Article 7, Delegated Regulation (EU) 2025/1190)
Regulator role	None, unless the buyer's own regulator asks for evidence	The competent authority oversees the test and its results, and can require the entity to test
Attestation	Provider report and any written attestation the buyer negotiates; confirm its form in the contract	The authority issues an attestation at the end of the TLPT (Article 26(7), DORA)
Mutual recognition	Not applicable; the report serves the buyer only	The authority's attestation allows tests to be recognized across competent authorities (Article 26(7), DORA)
Reporting cadence	Set by the contract, often at milestones and a final report; confirm the interval before signing	Active testing includes at least weekly progress reports (Article 11, Delegated Regulation (EU) 2025/1190)
Cost driver	Scope size, number of objectives, provider staffing and how much reporting the buyer requires	Mandated scenarios, the 12-week minimum, tester seniority, and the threat intelligence and oversight work that the regulation requires

Which entities must run TLPT and which can run a voluntary red team

If your competent authority has identified you for threat-led penetration testing, the obligation is mandatory. Under Article 2(2) of Delegated Regulation (EU) 2025/1190, TLPT authorities require the entity types below to test unless their own assessment says otherwise: G-SII and O-SII banks, payment and e-money institutions above EUR 150 billion of payment transactions in each of the two preceding years, central securities depositories and central counterparties.

Test cycle: DORA Article 26 requires threat-led penetration testing at least every 3 years for entities the authority identifies.
Scenarios: The regulation requires at least three TLPT scenarios, and at most one may be non-threat-led.
Duration: Active red team testing runs at least 12 weeks, with progress reports at least weekly.
Cost reference: The 2020 DORA impact assessment cites an ESA estimate that TLPT costs between 0.1% and 0.3% of the total ICT budget of the firms concerned (SWD(2020) 199). Use it as a 2020 planning reference only.

Confirm your designation status and its date in writing before you set a budget or a test calendar.

What DORA TLPT adds on top of a red team exercise

The main difference is that DORA TLPT is set by the regulator, not by you. A red team exercise starts when your organization decides to run one and sets its own objectives and rules. Under DORA, your competent authority decides whether your entity must run threat-led penetration testing, and it can also decide the test must be run on a set cycle, at least every three years under Article 26. Confirm with your authority whether you are in scope, because the regulation's designation criteria and the list of entities the authorities expect to test both matter. The authority also oversees the exercise, and its attestation at the close is what allows the result to be recognized by other competent authorities under Article 26(7) of DORA.

The scenario design is where a voluntary red team and a TLPT diverge most. The test must be informed by external threat intelligence about actors likely to target your sector, and the delegated rules under Delegated Regulation (EU) 2025/1190 require at least three scenarios, with at most one that is not threat-led. Your team therefore needs a threat intelligence input it can document, and a scenario list that the authority has reviewed before testing starts. A red team that picks its own objectives may satisfy neither rule.

Duration and people are also fixed. The delegated rules set active red team testing of at least 12 weeks, with weekly progress reports to the authority. The red team manager must have at least five years of experience, and at least two testers need at least two years each. Ask your provider to show these credentials in writing before you sign, and plan internal time for weekly reporting, which a voluntary exercise rarely requires. These obligations recur for each cycle, so budget them as ongoing governance rather than a one-off engagement.

What each approach finds and what it misses

A voluntary red team and a threat-led penetration test both test whether defenders detect and respond to chained attack paths, but they answer different questions. The cards below set out what each one finds, what it misses, and what neither replaces.

Defender detection along chained paths

A voluntary red team finds whether your people and tools notice and respond to a chain of techniques aimed at an objective you choose, such as access to a payment system or a customer data store. The output is a timeline of what was detected, what was missed and how long response took. Check that the objective and the rules of engagement name the systems and actions testers may use, because the findings can only cover what was in scope.

Intelligence-based scenarios under TLPT

TLPT tests the same kind of detection and response, but the attack paths come from external threat intelligence about actors that plausibly target the entity. The regulation sets minimum scenario counts and an active testing period of at least 12 weeks. Ask the provider how the threat intelligence was gathered and which scenarios were rejected, since that choice determines what the test can find.

Techniques outside the test profile

Both exercises miss techniques outside their scope or threat profile. A red team that targets a payment chain may never touch a neglected internal service, and a TLPT scenario built on one threat actor may not reflect a different actor's methods. Record the techniques excluded and why, so the next exercise or a scanning program can cover the gap.

Scanning and periodic testing still required

Neither a red team nor a TLPT replaces routine scanning or periodic penetration testing. NIST SP 800-115 suggests regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing. An exercise is a snapshot of one objective, so keep the scanning and penetration testing calendar running and treat the exercise as an additional layer.

No pass or fail result

TIBER-EU tests produce no pass or fail result, according to the ECB. Do not expect a score or a compliance verdict from a TLPT. The useful outputs are the documented attack paths, detection gaps and remediation plan, which are reviewed with the authority. A voluntary red team should be planned the same way, with a report that explains what was detected rather than a single rating.

Findings defined by rules of engagement

For an internal red team, the findings are defined by the rules of engagement. These set the objective, permitted techniques, time window, systems in scope, escalation contacts and the stop conditions. Ask who approves the rules, how the defenders are informed, and whether the findings report will cover detection timing as well as access achieved.

How a TLPT engagement moves through its phases

A TLPT engagement runs as a sequence of gated steps, from scoping and threat intelligence through scenario approval, active testing, closure and attestation, so that each phase produces a record the authority can review. Confirm the timing of every phase with your competent authority before committing to a plan.

Scope the test and agree rules of engagement
The regulated entity, its authority and the provider agree the systems in scope, the objectives, the escalation contacts and the conditions under which testers may act. NIST SP 800-115 includes a rules of engagement template in Appendix B that many buyers use as a reference point for this document. The step closes when the scope and rules are signed off in writing by the entity and the authority's requirements have been checked against them.
Gather external threat intelligence
Under the TLPT framework, the threat intelligence used to shape the test must come from outside the entity and reflect threats relevant to its sector and services. The provider or a dedicated intelligence provider produces a report on the actors and techniques that could target the entity. The step closes when the intelligence report is accepted as the basis for scenario design, and the entity can show where each input came from.
Design threat-led scenarios
Testers turn the intelligence into a set of attack scenarios, each with a clear objective, such as reaching a critical function or data set. The Delegated Regulation requires at least three TLPT scenarios, with at most one that is not threat-led, so the design must cover this minimum. The step closes with a scenario document that maps each scenario to its intelligence source and to the controls it is expected to test.
Obtain authority approval for the plan
The entity submits the scope, intelligence summary and scenarios to its competent authority, which reviews them and may require changes before testing begins. Testers and the red team manager named for the exercise should be confirmed against the tester requirements at this point. The step closes when the authority's approval is recorded and the test plan is frozen as the baseline for active testing.
Run active red team testing
Testers carry out the approved scenarios against live systems under the agreed rules, adapting within the plan as they learn about the environment. The Delegated Regulation sets a minimum active testing period, which the entity should check against its own authority's guidance, and requires progress reports at least weekly. Each report records activity, detections where they occur and any changes to the plan. The phase closes when all scenarios are executed or formally stopped.
Hold purple teaming and close the test
Under the TIBER-EU framework, a purple teaming step follows active testing so that defenders and testers review which actions were detected, logged or missed. The closure phase produces a report of the findings, the evidence behind them and the detection gaps the defenders agreed to address. The step closes when the report is issued and the entity has accepted the findings for remediation planning.
Remediate findings and verify fixes
The entity assigns owners and target dates to each finding, prioritizes the work, and implements fixes or compensating controls. Testers or an independent party may verify that critical fixes work as described before the test is considered complete. Ask the provider how re-testing is scoped and priced, because it is usually a separate piece of work. The step closes when the remediation plan is tracked to completion or formally accepted as residual risk.
Obtain the authority's attestation
At the end of the TLPT, the competent authority issues an attestation confirming that the test was carried out in line with the regulation. Under DORA Article 26(7), this attestation is what allows mutual recognition of the test between competent authorities. The step closes when the attestation is on file and the entity has recorded it as evidence for its ICT risk management and supervisory discussions.

How to combine a red team with TLPT without running two tests

One well-scoped exercise can serve both a voluntary red team and a regulated TLPT, but only if your competent authority accepts it in advance. The ECB's TIBER-EU framework, dated January 2025, already requires purple teaming alongside the red team, so the defensive review is built into the exercise rather than bolted on afterward. Running a commercial red team and then a separate TLPT against the same systems doubles the disruption to production, doubles the tester time and produces two sets of findings that someone must reconcile. The risk is that the red team's scope and the TLPT scenarios drift apart, so the regulator sees a test it did not approve and the firm pays twice.

A shared rules of engagement is the control that keeps this manageable. Before any testing starts, agree one document that names the target systems, the threat scenarios and their objectives, the permitted and prohibited actions, the escalation path when a tester reaches a critical system, the criteria for stopping the test, and who holds the white team role. Under Delegated Regulation (EU) 2025/1190, a TLPT needs at least three scenarios, of which at most one may be non-threat-led, and active red team testing of at least 12 weeks. A voluntary red team does not have to meet those minimums, so any combined exercise must satisfy the stricter regime and the rules of engagement should record which requirements each part of the work is meeting. Confirm also which tester qualifications and attestation the authority expects, because those requirements shape who can be staffed on the work.

Your responsibility is to put the proposal to your competent authority in writing and get its position before scoping begins. Ask whether a combined exercise counts as the TLPT, whether any part of the work needs to be run separately, and what evidence and attestation will be required at the end. Ask your provider to show how the threat intelligence, scenarios and tester roles map to the regulation, and confirm the scope, deliverables and timeline in a written, fixed-scope agreement. If the authority says no, you will still have a useful red team, but you will need a second, regulated test later.

When compliance frameworks call for each approach

Some regimes require a specific kind of test, while others only describe what a sound program includes. The cards below separate the two, so you can tell which obligations a voluntary red team can meet and which need a regulated, intelligence-led exercise.

DORA's broad ICT testing duty

Article 25(1) of DORA lists several kinds of ICT testing, including vulnerability assessments, scenario-based tests and penetration testing. Every financial entity in scope must run a testing program of this kind, not only the designated ones. Check whether your current program covers each listed type or only scans and penetration tests. A voluntary red team can contribute to this duty but does not by itself meet the separate TLPT obligation.

DORA's threat-led testing cycle

Article 26 of DORA requires threat-led penetration testing at least every three years, but only for entities that their competent authority identifies. Whether you are in scope is decided by the authority, not by your own risk assessment. Ask your supervisor directly if you have not been notified. If you are in scope, the TLPT cycle replaces the optional choice of exercise format with a fixed regulated process.

NIST red team enhancement in high baseline

NIST SP 800-53 control CA-8 covers penetration testing and includes an enhancement for red team exercises. Under the SP 800-53B baselines in Release 5.2.0, CA-8 and CA-8(1) are selected only in the high baseline. If your federal or contractual obligations use a moderate or low baseline, a red team may be optional rather than required. Confirm the baseline in your system security plan before scoping.

Validating defenses after each test

CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used. This is a requirement to close the loop, not just to run the exercise. Plan for detection validation work after every test, including any red team, and record which techniques were detected, missed or logged without an alert. Ask any red team provider how they will document detection gaps for your defenders.

Automated tools do not count

PCI SSC penetration testing guidance describes penetration testing as essentially a manual process. Running an automated scanner alone does not satisfy the penetration testing requirement, even if the output looks thorough. Check that your provider's deliverables show manual exploitation and analyst judgment, and that the report explains what was attempted and what was learned. Automated breach and attack simulation can complement a manual exercise but should not be presented as a replacement.

Questions buyers ask before choosing a red team or TLPT provider

What does a TLPT cost, and what drives the price up?

The price depends on the scope agreed in writing before work starts, not on a standard rate. The only cost figure we can point to is from the European Commission's 2020 DORA impact assessment (SWD(2020) 199), which cites an ESA estimate that threat-led penetration testing costs between 0.1% and 0.3% of the total ICT budget of the firms concerned. That is an estimate for the sector at the time, not a quote. Main drivers are the number of live production systems in scope, the number of threat-led scenarios, the length of the active testing period, the mandatory tester staffing, and the threat intelligence and reporting work. Ask each provider to itemize these components, and state which parts are one-time (scoping, threat intelligence, final report) and which recur (the next test cycle).

How long does a TLPT take, and what is the minimum active period?

Under Delegated Regulation (EU) 2025/1190, active red team testing must last at least 12 weeks, with at least weekly progress reports. Total elapsed time is longer because it includes preparation, threat intelligence work, scenario design and closure. Preparation and closure durations depend on how many scenarios are agreed and how quickly the entity's staff provide access and documentation. Ask providers for a phase-by-phase plan that shows where the 12 weeks of active testing sit within the wider calendar, and check it against your competent authority's expectations.

What does the work need from our internal staff?

A TLPT needs named people on the entity side for scoping, access approvals, system owner questions, and sign-off on rules of engagement. Plan for a contact who can make decisions quickly, plus technical staff who can explain architecture and respond to the weekly reports. Blue team staff who detect and respond are part of the exercise too, so their time must be planned. Confirm in writing who holds the decision on stopping a test that threatens production stability, and how escalation works during the active period.

Can our own team run a TLPT, or do we need an outside provider?

For a TLPT, the answer is generally no for the internal team alone. Delegated Regulation (EU) 2025/1190 Article 7 requires a red team manager with at least 5 years' experience and at least two testers with at least 2 years' experience each. Internal staff can meet those thresholds only if they are independent of the day-to-day security operations being tested and are accepted under the regulation's requirements, which your competent authority must confirm. A voluntary red team has no such fixed staffing rule, so the decision depends on skills, independence and what you need to prove. Check the current tester requirements with your competent authority before deciding.

Does a voluntary red team satisfy the TLPT requirement?

Usually not on its own. A voluntary red team can test people, processes and technology well, but a TLPT under DORA must follow the regulation's rules on scenarios, duration, tester requirements and authority oversight. Delegated Regulation (EU) 2025/1190 requires at least three TLPT scenarios, with at most one non-threat-led, plus active red team testing of at least 12 weeks. A voluntary exercise can still be useful for the board, for building capability, or between regulated cycles. Confirm with your competent authority whether a given exercise will count toward a TLPT obligation, since authority attestation under DORA Article 26(7) is what enables mutual recognition.

What does a CREST-accredited provider mean, and does it count for DORA?

CREST (International) is a UK not-for-profit that accredits member companies and certifies individuals in disciplines including security testing, red teaming and threat intelligence. A CREST accreditation tells you the provider has passed CREST's assessment, but it is not a DORA approval. The Bank of England names CREST as the accreditation and certification body for CBEST, the UK scheme, not for DORA TLPT. For a DORA TLPT, ask your competent authority which provider credentials it accepts, and ask the provider to show the certifications held by the named testers, not only the company.

What is delivered at the end of a TLPT?

Expect a final report covering the scenarios tested, the attack paths used, what was detected and what was not, and prioritized remediation. Under DORA Article 26(7), the competent authority issues an attestation at the end of a TLPT, and that attestation supports mutual recognition between authorities. Ask providers which deliverables are fixed in the written scope, including the weekly progress reports, the closure report, remediation support and the format of material passed to the authority. A TLPT is not a pass or fail test, so the report should focus on lessons and fixes, not a score.

Where to check the rules before you commit

Start with the primary texts before you accept any scope or price. The Commission Delegated Regulation (EU) 2025/1190 sets the TLPT requirements for designated entities, including the minimum of three scenarios, the at most one non-threat-led scenario, the active red team testing of at least 12 weeks, and the tester experience rules in Article 7. Read it alongside Regulation (EU) 2022/2554 (DORA), particularly Article 26, which sets the three-year cycle and the attestation that makes results recognizable across authorities. The Commission impact assessment SWD(2020) 199 explains the cost reasoning behind the regime, including the ESA estimate that threat-led testing costs between 0.1% and 0.3% of the total ICT budget of the firms concerned. Treat that figure as a policy estimate from 2020, not a quote for your organization.

For the phase rules, purple teaming requirements and the closure process, use the ECB's TIBER-EU framework and the January 2025 framework document, which governs how one test can serve both TIBER-EU and DORA. Before you commit, confirm with your competent authority whether you are designated for TLPT, which entity types and thresholds apply to your group, which threat scenarios the authority will accept, whether it expects a joint or separate TIBER-EU test, and the exact attestation route and format. Ask whether the authority will recognize a voluntary red team in place of a mandated test, and what it requires if it does not. Those answers, not the framework text alone, will determine your scope and tender.

How DeployOpen scopes, delivers and supports security testing

DeployOpen is a Chainscore Labs company that plans, runs and documents security testing for self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For red teaming and TLPT work, we scope the exercise in writing first, then hand over evidence that your team and any independent provider can review.

How we scope

Engagements are fixed-scope, with objectives, targets, rules of engagement and timelines agreed in writing before work starts.
Written scope states whether the exercise is a commercially scoped red team or a regulator-led TLPT that follows a defined framework.
Ask us to confirm which entities, systems and third-party providers are in scope and who authorizes the test.

How we build

We prepare the test environment, communication channels and escalation paths so the exercise can run with minimal disruption to production.
Testing follows documented phases, from intelligence gathering and attack path planning through exploitation, post-exploitation and reporting.
Where a regulator requires a specific structure, we map our plan to that structure and confirm the tester qualifications with you in advance.

How we hand over

Deliverables include a written report of attack paths, techniques used, detections triggered and missed, and remediation priorities.
We document evidence in a form that your compliance team and auditors can trace back to the agreed scope.
Ask for the handover format, retention period and access controls for test evidence before the engagement begins.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial exercise.
Retainers can cover retesting of fixed findings and updated exercises as your platforms and threat context change.
Confirm the retainer scope, response expectations and renewal terms in the written agreement, since we do not publish a price list.