Who must run DORA threat-led penetration testing, and what it takes
Threat-led penetration testing (TLPT) is an intelligence-led red team test of a financial entity's critical live production systems, and DORA requires it at least every three years for entities that their competent authority identifies. The authority, not the entity, decides who is in the regime, and it is the authority that issues the attestation confirming a test met the requirements. If your competent authority has notified you, or a board or contract counterparty is now asking whether you are covered, your first task is to confirm the notification in writing and read the scope it implies. The regime is not a single rule for all financial entities. Microenterprises and the entities excluded under Article 16(1) fall outside the obligation, and the authority may ask for testing more or less often than every three years.
The answer depends on three things: your size and type, the scope of critical or important functions you operate, and whether you fall within Article 2(2) of Delegated Regulation (EU) 2025/1190. That article lists entity types the TLPT authorities require to test unless their own assessment says otherwise. It names G-SII and O-SII banks, central securities depositories, central counterparties, and payment and electronic money institutions above the stated transaction or outstanding e-money thresholds in each of the two preceding years. Check those thresholds against your own figures for both years, and do not assume that falling below them removes you from scope, because the authority's assessment still applies. Confirm the list and any assessment criteria directly with your competent authority, and document the basis for your conclusion. The full text is available on EUR-Lex.
The TLPT phases and deadlines under Delegated Regulation 2025/1190
The sequence runs from the authority's notification through scoping, active red team testing, reporting and remediation, ending with the summary report and remediation plans that the competent authority reviews before issuing its attestation. Each phase hands a defined document or decision to the next.
Confirm notification and submit initiation information
The process starts when the competent authority notifies the entity that it must carry out threat-led penetration testing. Within 3 months of that notification, the entity submits initiation information to the authority, identifying the people and parties involved in the test and the intended approach. The output is a submitted initiation package and a clear record of the date the 3-month clock started. Ask your authority which templates and channels it expects, and keep proof of submission for the file.
Approve the scope specification with the management body
The entity prepares a scope specification document covering the critical or important functions, the live production systems and the ICT providers involved. The management body must approve it within 6 months of notification. The competent authority validates the scope, so the document should be complete enough to survive challenge. The output is a management body approval recorded in its minutes and a scope the authority has accepted. Confirm early whether any ICT provider needs to join through a pooled test.
Select threat scenarios and the control team lead
The control team lead selects at least three scenarios for the test, based on threat intelligence about the actors most likely to target the entity. At most one scenario may be non-threat-led, so the remainder must be built from threat intelligence. The selection is documented so that the authority can see how each scenario maps to the scope. The output is a scenario set that the red team can execute and that the control team can measure against.
Run active red team testing with weekly progress reports
The external red team executes the scenarios against live production systems for at least 12 weeks. The control team receives progress reports at least weekly, which lets it stop or adjust the test if risks to operations appear. The output is a continuous record of activity, weekly reports to the control team and a clear end point for active testing. Ask testers how they plan to handle safeguards, data protection and escalation during this phase.
Deliver the red team, blue team and purple teaming reports
After active testing ends, the red team report is due within 4 weeks. The blue team then reports on how defenders detected and responded, with the blue team report and the replay and purple teaming exercises due within 10 weeks of the end of active testing. Replay and purple teaming let defenders and testers review together what worked and what did not. The output is three linked reports showing attacker activity, defensive response and joint lessons.
Complete the summary report and remediation plans
The summary report and the remediation plans are due within 8 weeks of the competent authority notifying the entity that both the red team and blue team reports are complete. The summary report sets out the findings in a form the management body and authority can review. The remediation plans assign owners and sequencing for each weakness found. The output is a summary report and remediation plans ready for authority review, from which the attestation can follow.
Receive the authority attestation
Once the authority has reviewed the test, it issues an attestation that the test met the requirements of Article 26. This attestation is the only authority-issued document under the TLPT regime, and it allows the test to be mutually recognized between competent authorities. The output is the attestation on file, which the entity can present to supervisors and to other authorities where relevant. Confirm with your authority how it expects the attestation to be stored and referenced in the register of tests.
What testers and threat intelligence providers must meet
DORA sets minimum experience and reference levels for the people and firms that run threat-led penetration tests, and it limits who may be inside the team. Each card covers one requirement that an entity or its provider must check before a test starts.
Red team manager experience
Delegated Regulation (EU) 2025/1190 sets a minimum for the person who leads the red team: at least 5 years of relevant experience. This person directs the attack scenarios, controls the test and writes the reporting that the authority reviews. Ask each provider for named CVs and confirm the years of experience against the role, not against the firm's general track record.
Minimum red team testers
Beyond the manager, the red team must include at least two testers with at least 2 years of experience each. Entities should map each named tester to a role in the test plan and confirm that the team can cover the chosen scenarios at the same time. Staffing gaps often surface in week one of active testing, so check availability before the contract is signed.
External tester references
External testers must show at least five references. A reference is evidence of comparable work, so ask for client sectors and test types, not only a count. Verify the references are for tests of similar scope, and confirm that the provider can share the references under its confidentiality obligations.
Threat intelligence provider references
The threat intelligence provider must show at least three references, a lower count than the external testers but still a formal test. Its work defines the threat scenarios, so it should be able to show how it builds intelligence on the entity's sector and threat actors. Ask how the provider sources its intelligence and how it keeps that material confidential.
Always external threat intelligence
The threat intelligence provider must always be external to the financial entity, whatever the entity's internal capability. Internal staff may not supply the threat intelligence that drives the scenarios. Confirm this in the procurement file and in the scope specification so that the independence of the intelligence is documented for the authority.
Internal testers and external rotation
Internal testers may take part only with prior approval, and external testers must be used at least every three tests. Significant credit institutions may use only external testers. Entities should record the approval for each internal tester, track the test count for each external firm and plan the rotation early, since it affects the choice of provider for future cycles.
Pooled testing and the link to TIBER-EU
Some ICT providers serve many financial entities from one shared platform. Testing each customer's live production environment separately may not be practical, and including the provider in every entity's test may affect its other customers. Article 26(4) of DORA allows the provider and the entity to agree on a pooled test. One designated financial entity directs the test, an external tester carries it out, and the result counts as TLPT for every participating entity. The pooled route is a cooperation arrangement, not a shortcut around the rules.
- Designation: One financial entity must be named to direct the pooled test, and the other participants should confirm that choice in writing.
- External tester: The tester must be external to the participants, and it must meet the tester requirements of Article 27 and Delegated Regulation (EU) 2025/1190.
- Shared scope: The scope must cover the critical or important functions and live production systems that each participant relies on, and the competent authorities must validate it.
- Individual recognition: Each participant still needs its own TLPT status with its own competent authority, so confirm how each authority will treat the shared result.
- Contract terms: Agree on data handling, reporting access, remediation ownership and costs in the contract before the test starts.
Before committing, ask each participating entity's competent authority whether it accepts a pooled test for its own TLPT obligation.
Financial entities that already completed a TIBER-EU test under a national or European implementation often ask whether that work can be reused. Article 26(11) required the TLPT standards to be developed in accordance with the TIBER-EU framework, and the ECB has stated that an entity completing a test under a TIBER-EU implementation can be DORA TLPT-compliant if it meets the formal requirements its competent authority sets. Alignment in method does not automatically mean acceptance of a specific test.
- Formal requirements: Identify the formal requirements your competent authority applies, including documentation, reporting structure and timing.
- Gap review: Compare the earlier test's phases, deliverables and tester qualifications with the DORA steps in Delegated Regulation (EU) 2025/1190.
- Scope alignment: Check whether the scope covered the critical or important functions that DORA requires and whether it used live production systems.
- Attestation: Ask whether the authority will issue the attestation under Article 26(7) for the earlier test or only for a new one.
- Timing: Confirm whether the earlier test falls within the three-year cycle set for the entity.
Read the ECB's publication on adopting TIBER-EU for DORA and then ask your competent authority in writing which of these steps it will accept as evidence.
Neither route becomes TLPT by self-declaration. The entity owns its controls and test programme, and an implementation partner can prepare the scope, evidence and reporting, but the competent authority decides whether a test or a pooled arrangement meets DORA. The authority validates the scope under Article 26(2), reviews the reports and issues the attestation under Article 26(7). Nothing in this process turns a provider, a consultant or a testing firm into the decision maker.
- Competent authority: The authority for the entity's type decides on scope, pooled arrangements and whether a TIBER-EU test counts.
- Entity responsibility: The management body approves the scope specification, and the entity remains accountable for the results.
- Partner role: A partner can prepare systems, documentation and evidence for the authority's review but cannot issue an attestation.
- Early contact: Authorities are most useful before testing begins, so raise the question early in the notification process.
- Written record: Keep the authority's answer, any conditions it sets, and the basis for the decision in your evidence file.
Before engaging any provider, ask it to show how its proposed route fits your authority's published expectations and who will sign each document.
What a TLPT costs and who gets paid
This table separates the parties paid or affected in a DORA threat-led penetration test, from internal staff to the competent authority. Read each row for who bears the cost, whether it is one-time or recurs per cycle, and what moves it up or down. The only cost figure supplied is the ESA estimate of 0.1% to 0.3% of total ICT budget in the 2020 impact assessment, which is an estimate and not a quote.
| Cost component | Who is paid or affected | One-time or recurring per cycle | What drives the cost |
|---|---|---|---|
| Internal staff time | The entity's own staff, including the control team lead, system owners and management body approval | Recurring per cycle | Number of critical functions in scope, how many internal testers need prior approval, and how much live system knowledge is kept in house |
| External red team provider | The external tester firm, paid under the entity's contract | Recurring per cycle, at least every three years | Number of scenarios (at least three), active testing of at least 12 weeks, reporting frequency, and the size of the systems tested |
| Threat intelligence provider | A mandatory external provider, paid under a separate contract | Recurring per cycle | Depth of the tailored threat intelligence, the number of scenarios it supports, and the provider's references and team size |
| Implementation partner for environment and evidence preparation | An outside partner the entity may hire to prepare systems, logging, documentation and evidence, not to issue the attestation | Partly one-time (initial setup), partly recurring per cycle | Maturity of logging and asset records, number of live production systems in scope, and how much documentation must be rebuilt for the scope specification |
| Pooled testing with an ICT provider | The designated financial entity directing the pooled test, with costs shared or agreed with the provider | Recurring per cycle where it applies | Agreement between the provider and entities on scope, and who directs the external tester under Article 26(4) |
| Competent authority role | The national competent authority validates scope and issues the attestation, and may charge under national rules | Recurring per cycle | Scope validation, the number of entities tested, and the authority's own fee practice, which the reader should confirm with the authority |
| Overall ESA estimate | Reported in the 2020 Commission impact assessment (SWD(2020) 199), citing an ESA estimate | Context only, not a quote | The estimate is 0.1% to 0.3% of total ICT budget of the firms concerned, so the actual cost depends on the entity's ICT spend and scope |
What makes a TLPT more expensive or longer
Most of what drives the cost and duration of a threat-led penetration test is set before any tester starts work. The decisions below shape how much the test covers, how many attack paths the red team must build, and how much work follows the final report. Each one can be controlled through scoping choices agreed with the competent authority and the management body.
Number of functions and live systems
The test covers several or all critical or important functions on live production systems, and the competent authority validates the scope. Every additional function brings more systems, owners, data flows and environments into the red team's target set. Ask which functions the authority expects to see in scope, which ones the entity can justify excluding, and how many production systems each function depends on before the scope specification is written.
Number of attack scenarios
The control team lead selects at least three scenarios, and at most one may be non-threat-led. Each scenario needs threat intelligence, attack path design, tester time and its own reporting. Adding scenarios beyond the minimum raises effort in nearly every phase, so the scenario count should follow the risk the entity has identified rather than a default. Ask the threat intelligence provider how many distinct threat actor profiles are relevant to the in-scope functions.
Pooled testing with ICT providers
Where an ICT provider's services would be affected, the provider and the entity may agree on a pooled test run by one designated financial entity, and that test counts for all participants. Pooling can spread preparation and tester costs across firms, but it adds coordination, shared scope decisions and a single lead entity's governance. Confirm early which providers the entity depends on, whether they accept pooling, and who holds the direction role and its contractual terms.
Third-party dependencies in scope
A function that runs on a cloud platform, a managed service or a vendor's hosted application pulls that provider's controls, logs and change processes into the test. Each dependency needs agreed rules of engagement, contact points and sometimes separate permissions before the red team can act. Map every critical system to the providers that host, operate or access it, and check whether each provider's contract allows the testing activity described in the scope document.
Logging and environment readiness
Weak logging forces the blue team to reconstruct events manually, which extends the detection analysis and the replay exercises. Production environments that lack segregation, named test accounts or documented baselines also add setup time and risk. Before the test starts, check that security logs from the in-scope systems are retained and searchable, that the entity can separate red team activity from real incidents, and that the environment matches the production configuration described in the scope.
Remediation volume after the test
The entity must produce remediation plans within 8 weeks of the authority's notification that the reports are complete. The number of findings, their severity and the number of systems they touch determine how much engineering, change approval and retesting follows. Entities with mature vulnerability management and patch cycles usually carry a smaller remediation load into the closing phase. Ask testers to group findings by root cause and to state which ones require architectural change rather than configuration fixes.
Who does what in a TLPT
The financial entity owns the TLPT from start to finish. It is the party the competent authority notifies, the party that must submit the initiation information and the scope specification document, and the party accountable to its supervisor for every decision about what is tested and how findings are fixed. Its management body approves the scope, and the entity keeps responsibility for the critical or important functions covered by the test, even when outside firms run parts of the work.
- Initiation and scope: submitting initiation information within the period set in the delegated regulation and a scope specification document approved by the management body.
- Control team: the entity's internal control team works with the lead and the testers, and internal testers need prior approval from the authority.
- Remediation: owning the remediation plans that follow the red team, blue team and summary reports.
- Data and live systems: deciding which live production systems and third parties are in scope, and agreeing the safeguards for the test.
- Governance records: keeping the reports, approvals and evidence that the authority will review.
Before engaging any partner, confirm in writing which decisions stay with the entity's management body and which tasks the partner may perform on its behalf.
An implementation partner such as DeployOpen prepares the environment in which the entity's systems are tested and produces the records the entity needs to show its supervisor. The partner works inside the entity's own infrastructure, on the entity's instructions, and it does not hold the attestation or decide the outcome of the test. Where the partner also offers security testing services, those are delivered under a separate written scope agreed with the client, and they are not the TLPT itself.
- Systems readiness: preparing the in-scope systems, access paths and monitoring so the entity can run and evidence the test.
- Logging and telemetry: configuring logging, alerting and retention so the blue team and the reports have reliable data.
- Evidence and documentation: assembling configuration records, change history and the technical documentation the entity presents to the authority.
- Separate security testing: where contracted, running penetration or security testing under its own statement of work, which the entity may use as input but which is not an authority-validated TLPT.
- No attestation role: the partner does not validate scope, appoint testers or issue any authority document.
Ask any partner to state in its proposal which tasks it performs for the TLPT and which it does not, and confirm the boundary in the engagement letter.
The competent authority for the entity is the body that identifies the entity for TLPT, validates the scope, and decides whether the test met the requirements. It is the only party that issues the attestation under DORA, and that attestation is the document other authorities can rely on through mutual recognition. The authority acts on the entity's submissions and on the reports, so its role begins and ends with the formal decisions, not the technical work.
- Identification: notifying the entity that it must carry out TLPT and setting the test frequency, which is at least every three years unless the authority decides otherwise.
- Scope validation: checking that the critical or important functions and live systems covered are sufficient.
- Oversight of the process: reviewing the scope specification and the reports within the deadlines set in the delegated regulation.
- Attestation: issuing the document that confirms the test met the requirements.
- Recognition: allowing the attestation to be recognized by other competent authorities.
Confirm with your authority which document format and submission channel it expects, because this varies by member state.
The test itself is run by testers and a threat intelligence provider who meet the requirements of DORA Article 27 and the delegated regulation. The control team lead selects the scenarios and directs the red team, and the threat intelligence provider must always be external. Testers do not decide scope or certify the result. Their reports feed the entity's remediation, and the authority reviews them before deciding on the attestation.
- Red team: delivering the active testing over the minimum period set by the delegated regulation, with regular progress reports.
- Threat intelligence provider: supplying the threat intelligence that shapes the scenarios and must come from outside the entity.
- Blue team and replay: supporting the entity's defenders, with blue team reporting and purple teaming within the set deadlines.
- Qualifications: meeting the experience and reference minimums, which the entity should check and document.
- Independence: confirming in writing that the testers have no conflicts with the entity's systems or ICT providers.
Request the tester qualification records and the reference checks before contracting, and keep them with the TLPT file.
Common questions about DORA TLPT cost and effort
Can our own security team run DORA threat-led penetration testing?
Your internal team can take part, but only with prior approval from the competent authority, and it cannot carry the whole test alone. Article 26(8) and Article 27(2) of DORA require the threat intelligence provider to be external, and Delegated Regulation (EU) 2025/1190 sets minimum experience levels for testers. External testers must also be used at least every third test, and significant credit institutions may use only external testers. Plan internal staff for control team roles, scope preparation and remediation, and budget external firms for the red team and threat intelligence work.
How long does the active red team testing phase last?
Active red team testing lasts at least 12 weeks under Delegated Regulation (EU) 2025/1190, with progress reports at least weekly. That is the minimum, not the planning figure. The full cycle also includes the initiation notice due within 3 months of the authority's notification, the scope specification approved by the management body within 6 months, and the reports that follow testing. Ask any provider to show how they will meet each deadline in the regulation's timeline, not only the 12-week window.
What does the TLPT attestation prove and who issues it?
The attestation is a document issued by the competent authority confirming that a threat-led penetration test met the requirements of Article 26(7) of DORA. No auditor, consultant or testing firm can issue it, and it does not certify your organization as DORA compliant. Its main practical value is mutual recognition, so that a test accepted by one competent authority can be recognized by others. Your implementation partner can prepare the evidence for the authority, but the attestation itself comes only from the authority.
Does pooled testing with an ICT provider reduce our TLPT cost?
Pooled testing can lower your share of effort, because one test run by an external tester under the direction of one designated financial entity counts as TLPT for every participant under Article 26(4). The saving depends on how many firms share the test, how much of the provider's environment is in scope, and whether each participant still needs its own scope and reporting work. Agree in writing who directs the test, who pays for which phase, and how each participant's critical functions are covered before you assume any reduction.
What drives the cost of a DORA TLPT engagement?
The main cost drivers are the number and complexity of critical or important functions in scope, the size of the live production environment, the number of threat scenarios selected, and the extent of replay and purple teaming. The Commission's 2020 impact assessment (SWD(2020) 199) 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. Treat that as a sector-wide estimate from 2020, not a quote for your organization.
What should we ask a partner to include in a TLPT quote?
Ask for a fixed-scope proposal that lists each phase, its deliverables and its dates, tied to the deadlines in Delegated Regulation (EU) 2025/1190. Request the names of certified tester roles against the minimum experience levels, the threat intelligence provider's references, and a clear split of what the partner prepares and what your staff or the authority must do. Confirm which items are one-time, such as scope and the initial test, and which recur, such as the next cycle at least every three years. Ask how the work maps to TIBER-EU, if your authority follows that framework, and which reports the partner will not issue on your behalf.
Is a TIBER-EU test the same as a DORA TLPT?
A TIBER-EU test can meet DORA's TLPT requirement, but only if it satisfies the formal requirements your competent authority sets. The European Central Bank states that entities completing a test under a national or European TIBER-EU implementation will be DORA TLPT-compliant on that condition, and Article 26(11) required the TLPT standards to be developed in line with TIBER-EU. Ask your authority which formal requirements apply before you choose a framework, because the deliverables and approvals may differ.
How DeployOpen prepares your environment and evidence for TLPT
DeployOpen's role in a threat-led penetration test is preparatory and fixed-scope. Before a test starts, we support the planning and scoping work that feeds the scope specification document, which the entity's management body must approve within 6 months of the authority's notification under Delegated Regulation (EU) 2025/1190, Article 9. In practice that means mapping the critical or important functions in scope to the self-hosted open-source platforms that run them, identifying the live production systems behind each function, and documenting the dependencies the control team lead will need when selecting scenarios. The written scope agreed with you defines which systems, functions and deliverables are covered. Quotes follow that written scope, and we do not publish a price list.
We also harden and instrument the self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. That work covers configuration baselines, access controls, centralized logging of the events a red team and blue team will generate, and backup and recovery procedures, so the entity can show that its production systems were tested in a defined and monitored state. The entity owns those controls and its own records. We assemble evidence packs that gather configuration records, change logs, scope documentation and the reports produced during testing, so your internal team and the authority can trace what was tested and when. Ask any provider to confirm in writing which artifacts they will hand over and in which format.
DeployOpen does not run the competent authority's validation of scope, does not issue the TLPT attestation under Article 26(7), and does not guarantee any result from a test or from the authority's review. Those decisions sit with your authority and with the testers and threat intelligence provider that meet the requirements of Article 27. Our security testing services can complement the programme, but any TLPT engagement must use testers who satisfy the rules on external and internal testers, which we will confirm against your scope before work begins. Ask your authority which formal requirements apply to your entity, and confirm each responsibility split in the written agreement.
