What Article 26 DORA threat-led penetration testing asks for
Article 26 applies only to financial entities that their competent authority identifies for threat-led penetration testing (TLPT). Once identified, the entity must test at least every three years by default, and the authority can ask for more or less frequent testing based on the entity's risk profile. Each test covers several or all critical or important functions and runs against live production systems, not copies or staging environments. Microenterprises and the entities excluded under Article 16(1) fall outside the obligation, so the first task is to confirm with your authority whether you have been identified at all.
The risk Article 26 addresses is a attacker who uses current threat intelligence against the systems that actually carry critical services. That differs from the broader testing in Article 25, which can use vulnerability scans, scenario tests or performance tests in controlled conditions. TLPT is built around a threat-intelligence scenario, tested by testers who behave like the adversary would, and it is the only testing in DORA that ends with an authority-issued attestation that the test met the requirements under Article 26(7). The technical rules are set in Commission Delegated Regulation (EU) 2025/1190, which was published in the Official Journal on 18 June 2025 and aligns with the TIBER-EU framework. Read it alongside the TIBER-EU framework before scoping.
Three things make TLPT hard in practice. First, scope is agreed with the competent authority, so the functions, systems and providers included need to be documented and defensible before testing starts. Second, live production testing carries operational risk, so the entity needs written rules of engagement, a clear escalation path and recovery plans for anything the testers might disrupt. Third, where ICT third-party service providers are in scope, the entity must secure their participation. If provider participation would affect other customers, a pooled TLPT directed by one designated financial entity may be used. Ask your provider now whether its contract allows this, because a refusal discovered late can reshape the whole scope.
Which entities, systems and providers fall inside a TLPT
Scope is the first decision in any threat-led penetration test, and it fixes the cost, the testers and the evidence that follows. The cards below cover the decisions that shape scope: who is in the regime, which functions and systems are tested, and how third-party providers are brought in. Confirm each one with your competent authority before testers are engaged.
Authority identification
A TLPT obligation starts with the competent authority identifying the financial entity, not with the entity deciding to test. Authorities may ask for more or less frequent testing based on the entity's risk profile, and the baseline interval for identified entities is at least every 3 years. Check your identification letter or notice, record its date, and confirm the testing cycle it sets before planning budgets or tester procurement.
Microenterprise and Article 16(1) exclusions
Microenterprises and entities covered by Article 16(1) are excluded from the TLPT obligation. Exclusion is not automatic for every small firm, so confirm your classification against the entity definitions and your authority's position. Entities that are excluded still need the testing programme and general testing expected under the other articles, so the exclusion changes the regime that applies rather than removing testing altogether.
Critical or important functions
Each TLPT covers several or all critical or important functions, so the function inventory defines the test boundary. Map each function to the ICT systems, data flows and people that support it, then document why each one is in or out. Expect the competent authority to validate this scope, which means a thin or undocumented mapping can delay the test before any tester starts work.
Live production systems
TLPT is performed on live production systems rather than test copies, which changes how the work is planned and controlled. Testers need rules of engagement, change freezes, backup and rollback plans, and an agreed way to stop the test if a live service degrades. Ask your testers how they will protect customer data and availability while they exercise real attack paths in production.
Third-party provider participation
When an ICT third-party service provider sits inside the scope, the financial entity must secure that provider's participation in the test. Contract clauses should set out the provider's duty to take part, the systems it covers and how findings about its services are handled. Confirm these terms before testing, because a provider that will not cooperate can block the whole scope.
Pooled tests directed by one entity
A pooled TLPT, directed by one designated financial entity, can be used when provider participation would affect other customers. The directing entity coordinates the scope and testers for the group, and each participating entity still owns its own findings and remediation. Ask whether your provider runs pooled testing, who would act as the designated entity, and how costs and results are split among participants.
Internal or external testers under Article 26
Article 26 lets a financial entity use its own staff as testers, but only for some of its TLPT cycles. The entity must contract external testers at least every third test, so internal teams can carry the other tests in the cycle. Internal testers keep in-house knowledge of systems and can reduce external fees, but the entity must show that they meet the same suitability and expertise bar that applies to external testers, and that they are independent enough to test their own organization credibly.
- Rotation rule: Plan the sequence of tests in advance so that every third test uses an external tester. Record which test used which tester type.
- Independence: Show reporting lines that keep the testers separate from the teams that run the systems under test, and document safeguards against conflicts.
- Qualifications: Keep evidence of skills, training and certifications for each internal tester, matched to the requirements of Article 27.
- Cost pattern: Internal effort is largely staff time and tooling, and it recurs with each test. External fees are avoided for internal cycles but not for the mandatory external test.
- Authority review: Expect the authority to ask who the testers were, how independence was secured and how the findings were validated.
Confirm with your competent authority how it applies the internal tester conditions to your entity before you assign a team.
External testers are firms or individuals outside the entity, contracted to run the TLPT. They bring independence from the organization's internal reporting lines and access to threat intelligence and attack techniques the internal team may not maintain. Article 26 requires that an external tester be contracted at least once every three tests. Procurement, contract terms and tester selection therefore need to be planned across the whole testing cycle, not only for one exercise.
- Selection: Assess candidate providers against the tester requirements in Article 27 and the TLPT RTS, including experience, references and insurance.
- Contract terms: Define scope, rules of engagement, confidentiality, data handling and the handover of findings in writing before testing begins.
- Cost pattern: External fees are typically a one-time cost for each engagement, with added cost for scoping, threat intelligence and reporting. Ask providers to separate these in the quote.
- Coordination: Where ICT third-party providers are in scope, the entity must secure their participation, which can affect the contract.
- Evidence: Keep signed engagement letters, tester qualification records and the final reports that feed the summary of findings.
Confirm the external tester requirements and whether your authority expects a specific provider approach before signing a contract.
Significant credit institutions may use only external testers for TLPT. The internal tester option available to other entities is not open to them. This rule removes the internal cycle from their planning, so the full testing schedule relies on external providers. These institutions should treat the external tester requirement as a fixed element of their programme and budget for it accordingly.
- Eligibility: Confirm with the supervisor whether your institution is classified as significant, since this changes the tester rule.
- Provider capacity: Start procurement early, because all tests will depend on availability of qualified external firms.
- Independence: External testers give the clearest separation from internal teams, so document the separation between the provider and the systems owners.
- Cost pattern: Every test carries external cost, so the recurring budget is higher than for entities that can use internal testers.
- Evidence: Keep the same tester records, contracts and reports as external testers, along with the rationale for the classification.
Confirm the classification status and the supervisory expectations with the ECB or the national authority before setting the budget.
How a supervisor tests a threat-led penetration test
This table lists the checks a competent authority typically applies to a TLPT, from whether the entity was identified through to the Article 26(7) attestation. Read each row as a question the supervisor will ask, then the evidence it expects and the gap that most often causes problems.
| Supervisory check | What the supervisor looks for | Common finding |
|---|---|---|
| Entity identified | Evidence that the competent authority identified the entity as subject to TLPT and set the testing cycle, which is at least every 3 years | Testing run on a self-chosen timetable with no authority identification on file |
| Scope covers critical or important functions | Each test covers several or all critical or important functions and includes the live production systems that support them | Thin scope limited to a few applications while core payment or settlement functions sit outside the test |
| Scope validated by authority | Written scope approved by the competent authority before testing starts, with changes recorded and re-validated | Unvalidated scope, or scope changed mid-test without authority sign-off |
| ICT third-party providers secured | Contractual or documented participation of in-scope providers, or a pooled TLPT directed by a designated entity where provider participation would affect other customers | Missing provider participation, with no pooled arrangement or record of why a provider was excluded |
| Tester eligibility | Internal and external testers meet the Article 27 conditions, external testers are contracted at the required intervals, and significant credit institutions use external testers only | Internal testers used without evidence of independence, or external testers not rotated as required |
| Summary of findings | A summary that states the findings, their severity and how they map to the critical functions tested | Summary that lists vulnerabilities without linking them to the functions or threat scenarios tested |
| Remediation plans | Dated plans with owners for each finding, and evidence of validation that fixes work | Plans without owners or dates, or fixes asserted but not retested |
| Compliance documentation and attestation | Complete file submitted by the entity and testers, leading to the authority's attestation under Article 26(7) that the test met the requirements | Incomplete file that delays or prevents the attestation, which supports mutual recognition between authorities |
How to run a TLPT from scope to attestation
This sequence takes a financial entity from identification by its competent authority to a supervisory attestation that its threat-led penetration test met the requirements. Each step produces a document or decision that the next step depends on.
Confirm identification and test frequency
The entity confirms with its competent authority that it has been identified for TLPT, and agrees the testing frequency. Under the topic facts, TLPT must happen at least every three years, and the authority may ask for more or less frequent testing based on the entity's risk profile. Microenterprises and entities under Article 16(1) are excluded. Ask the authority in writing what it expects for the first cycle, including the date by which the first test should start. The output is a written confirmation of identification and frequency that governs every later step.
Define scope and critical functions
The entity, with its testers and its competent authority, sets the scope. Each TLPT covers several or all critical or important functions and runs on live production systems. The authority validates the scope, so draft it with the functions, systems, data and ICT services that support them, and record why each is in or out. Confirm the risk assessment and the register of ICT services that underpin the selection. The output is a validated scope document that names the functions, systems and providers in the test.
Secure provider participation or set up a pooled test
Where ICT third-party service providers are in scope, the entity must secure their participation in writing before testing starts. If a provider's participation would affect other customers, the entity can use a pooled TLPT directed by one designated financial entity. Ask each provider what it will allow, which systems it will expose, and how it will handle a finding in a shared platform. Agree rules of engagement with each provider, including who may be contacted during the test. The output is a signed participation or pooling arrangement that the scope document references.
Select internal and external testers
The entity selects the testing team and checks it against the tester requirements in Article 27 and the TLPT RTS. Entities may use internal testers, but they must contract external testers every three tests. Significant credit institutions may use only external testers. Confirm the independence, expertise and insurance of each tester, and confirm the conditions that apply to internal testers. Ask the external firm to document its methodology, its threat intelligence sources and its handling of live data. The output is a tester selection record that shows how each tester meets the requirements.
Run the test on live systems under agreed controls
The testers run the threat-led test on live production systems within the validated scope. Before the first action, the entity and testers agree controls that limit business impact, such as stop conditions, escalation contacts, data handling rules and a named control team. The threat intelligence used to shape scenarios should be recorded so the authority can see the basis for each attack path. The output is a complete activity log, a set of confirmed findings and a record of every control invoked during the engagement.
Produce the summary of findings and remediation plan
After testing, the testers write a summary of findings and the entity writes a remediation plan for each finding. The summary should describe the attack paths tested, what succeeded, what was detected, and how quickly the entity's defenders responded. The remediation plan should assign an owner, a priority and a validation method to each finding. Have the internal risk function and the management body review both documents before submission. The output is an approved summary and remediation plan that the entity can defend to its authority.
Submit compliance documentation for attestation
The entity and testers submit the summary of findings, the remediation plans and the compliance documentation to the competent authority. The authority reviews the package and, where the requirements are met, issues the attestation under Article 26(7). That attestation supports mutual recognition between authorities. Confirm with the authority which format, channel and supporting evidence it expects before submission, and keep an indexed copy of everything submitted. The output is the authority's attestation, or a documented list of gaps the entity must close before resubmitting.
Evidence that satisfies a threat-led penetration test
A threat-led penetration test produces a chain of documents, from the scope the authority validates to the proof that remediated findings were closed. Each card below is one artifact or record that an authority or auditor will ask to see, and each should be kept current between tests rather than rebuilt before the next one.
Validated scope document
The scope records which critical or important functions, live production systems and ICT third-party services the test covers, as validated by the competent authority. For Article 26, this is the baseline every later artifact must trace back to. Check that the scope names the systems by function rather than by IP range alone, that any change to the scope is recorded with the authority's agreement, and that the document is dated and versioned.
Tester eligibility records
These records show that each tester meets the requirements for threat-led testing, including suitability, expertise and the experience and reference minimums in the TLPT technical standards. Internal testers need additional evidence of independence and a contracted external tester at the required intervals. Keep certificates, reference letters, insurance confirmations and conflict-of-interest declarations on file for each named individual and firm.
Provider participation agreements
Where an ICT third-party service provider falls within scope, the entity must secure that provider's participation. The signed agreement should set out the provider's obligations during live testing, access arrangements, incident handling and the provider's own remediation commitments. If a pooled test is used, keep the designation of the directing entity and the terms agreed by each participating customer.
Threat intelligence basis
The threat intelligence file explains why the chosen threat scenarios reflect the entity's real attack surface and current adversaries. It should show the sources consulted, how indicators were gathered and checked, and how each scenario maps to the functions in scope. Store raw intelligence exports and the analyst's reasoning separately so a reviewer can test the link between intelligence and scenario.
Summary of findings and remediation plans
The summary of findings is the document the entity and testers submit to the authority after testing. Pair it with a remediation plan that lists each finding, its owner, a target date and the control it affects. Ask for named individuals rather than teams as owners, and confirm that the dates in the plan match the dates in the issue tracker. Reviewers often reject plans whose owners cannot be identified.
Closure validation and compliance documentation
Closure validation shows that each finding was fixed and retested, with the retest result, the person who verified it and the date. Together with the compliance documentation, it demonstrates that the entity's wider ICT risk management framework absorbed the lessons. Keep retest logs, configuration baselines before and after change, and approvals from the management body. Records should be indexed so a reviewer can follow any finding to its closure in a few steps.
Where open-source tools support the TLPT evidence trail
The four open-source platforms named here can hold the evidence around a threat-led penetration test, but they do not run the test. Scope, threat intelligence scenarios, attack paths and the choice of testers are set by the financial entity with its testers and validated by the competent authority. MISP and OpenCTI can store the threat intelligence that informs the scenarios, with indicators, sources and relationships kept under the entity's own control. OpenSearch Security Analytics and Wazuh can hold the detections and alert records the blue team produced during the exercise, which helps reconstruct what was seen, when and by which rule. Before adopting any of them for this purpose, confirm with your testers and your authority how they expect threat intelligence and detection records to be packaged in the summary of findings.
Licence terms need a check before deployment. MISP is licensed under AGPL-3.0-only, OpenCTI and OpenSearch under Apache-2.0, and Wazuh under GPL-2.0-only. Each licence has obligations that depend on how the software is modified, hosted and shared, so ask your legal team to review the exact terms and any modifications you plan to make. The obligations apply whether or not the platform is used for TLPT, so this review belongs in the wider ICT tooling approval, not only in the testing project.
Treat the platforms as sources of records and make the evidence chain auditable. Decide which events, indicators and alerts are exported at the close of the test, who signs off on the export, and how long copies are retained. Confirm that the exports can be traced back to the test window and the threat intelligence sources used, because those links are what a reviewer will ask to see. Costs for this work come from licence review, configuration, retention planning and the time your staff spend on it, and they recur whenever the platforms are upgraded or the test scope changes. Ask any implementation partner to state these items separately in a written quote.
What a TLPT costs in money and effort
This table compares each cost component of a threat-led penetration test, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price figures for TLPT are supplied here and the real cost depends on your written scope.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| External tester fees | Accredited external testing firm | Recurring per test cycle | Scope size and number of critical functions. Ask for a fee breakdown by phase: preparation, testing, reporting and closure. |
| Internal tester time | Your staff (salaries and time), or a contracted internal team | Recurring per test cycle | Only relevant where internal testers are permitted. Ask how many person-days the internal team must commit and who covers the time away from other work. |
| Provider coordination | Your organization, plus any ICT third-party providers whose participation you must secure | Recurring per test cycle | Number of providers in scope and whether a pooled TLPT is used. Ask who negotiates provider participation and whether providers charge for their involvement. |
| Scope and authority engagement | Your organization (legal, risk and compliance time), plus the competent authority's validation process | Largely one-time per cycle, with recurring effort on each renewal | Number of critical or important functions covered and how many systems each one touches. Ask the testing firm which scoping documents they will prepare and which you must supply. |
| Remediation effort | Your engineering, operations and vendor teams | Recurring, driven by findings | Volume and severity of findings and how many depend on third parties. Ask the tester to separate findings by owner so remediation can be planned and budgeted. |
| Open-source tooling (MISP, OpenCTI, OpenSearch, Wazuh) | No licence fee for the listed tools (MISP and OpenCTI are open source, Wazuh and OpenSearch are open source), but you pay for hosting, storage, maintenance and staff | Recurring | Log volume, retention period and number of threat intelligence feeds. Confirm the licence terms and support model you need before relying on any tool in evidence. |
| Revalidation | Testing firm and your team, to confirm fixes work | Recurring within each cycle | Number of open findings and how they were fixed. Ask whether revalidation is included in the quoted fee or priced separately. |
Who owns the TLPT, who prepares for it, and who attests
The financial entity owns the threat-led penetration test. Article 26 places the obligation on the entity that the competent authority has identified, and the entity remains accountable for the scope it proposes, the testers it contracts or uses internally, the way live production systems are tested, and the remediation that follows. Management cannot hand that accountability to a vendor, even when a partner does much of the preparation.
- Test ownership: The entity decides how the test is run and signs off the scope that is submitted for validation.
- Scope decisions: The entity identifies the critical or important functions covered and secures the participation of ICT third-party providers where they are in scope.
- Tester selection: The entity contracts external testers as the rules require and can use internal testers only within the limits the regulation sets.
- Remediation: The entity owns the remediation plan, its funding and the validation of fixes after the test.
- Submissions: The entity and its testers submit the summary of findings, remediation plans and compliance documentation.
Before committing budget, confirm with your competent authority which entity types and risk profile apply to you, how often testing is expected, and whether a pooled test is possible.
An implementation partner prepares the environment so that the entity and its testers can work effectively and so that the evidence is complete. DeployOpen's role is to plan, implement and harden the self-hosted systems inside the client's own infrastructure, configure logging and detection, and document what the systems do. The partner can also support scoping discussions with the entity, but it does not decide scope, select testers for the entity, run the attack, or sign any submission.
- System readiness: Prepare the production-facing systems, network segments and identity controls that the test will touch, with documented configurations.
- Logging and detection: Configure log collection and detection tooling, such as Wazuh, OpenSearch Security Analytics or OpenCTI, so that the entity can see what testers do and measure its own response.
- Evidence preparation: Assemble configuration records, change history and remediation tracking that the entity can use in its submission.
- Scoping support: Provide technical input on which systems support each function, so the entity can make its own scope proposal.
- Boundaries: The partner works on the entity's instructions and does not issue reports, attestations or certificates.
Ask any partner to state in writing which tasks it performs, which tasks stay with the entity and its testers, and who holds the evidence after the engagement ends.
The competent authority validates the scope of each test and, after the test and the submitted documents are reviewed, issues the attestation that the test met the requirements of Article 26(7). External testers perform the test itself and produce the findings that the entity must act on. Their independence from the entity and from any implementation partner is the line that supervisors examine most closely.
- Scope validation: The competent authority reviews and validates the proposed scope before testing starts.
- Tester conduct: External testers carry out the test under the requirements for testers and the TLPT technical standards, including the TIBER-EU alignment set out in Delegated Regulation (EU) 2025/1190.
- Attestation: The authority issues the attestation after reviewing the summary of findings, remediation plans and compliance documentation. This attestation is the only one the Regulation provides for, and it supports mutual recognition between authorities.
- Independence line: Testers must not be the same parties that built or operate the systems under test, and the entity must keep the evidence trail separate from the attack activity.
- No DeployOpen attestations: DeployOpen does not issue attestations, reports or certificates. Only the competent authority does that.
Confirm your tester arrangements and the independence rules with your authority before the engagement begins.
Where entities usually fall short on TLPT
Why does a TLPT scope that leaves out critical functions fail?
A TLPT that does not cover the critical or important functions of the entity does not test what DORA asks it to test, and the competent authority can reject the scope. Each TLPT covers several or all critical or important functions, so the scope should start from the entity's own function mapping and then follow the threat scenarios into the systems, people, processes and third parties that support each function. The fix is to document the function-to-system mapping before the scoping workshop, have the competent authority validate it early, and record why any function was left out. Confirm the exact scoping expectations with your authority, since the supervisory process sets how the scope is reviewed.
Why must production systems be in TLPT scope?
DORA's TLPT is performed on live production systems, so an entity that carves production out of scope and tests only copies or staging environments produces results that do not reflect its real exposure. Test environments often differ in configuration, data, monitoring and patch level, which means a clean result there says little about the systems customers use. The fix is to agree in advance the controls that protect production during testing, such as rules of engagement, deconfliction contacts, kill-switch procedures, data handling limits and monitoring by the blue team, and then to bring production into scope under those controls. Ask your testers to explain how they will avoid service disruption before any live activity begins.
What goes wrong when ICT providers join a TLPT without planning?
Where an ICT third-party service provider is in scope, the entity must secure its participation, and a provider that is brought in late often refuses access, delays the test or limits what can be tested. Problems also arise when a shared provider's platform hosts several customers, because testing it may affect them. The fix is to identify provider dependencies during scoping, open the contractual route for participation early, and agree a pooled TLPT led by one designated financial entity where the provider's participation would affect other customers. Contract terms, access rules and the provider's own testing permissions should be confirmed in writing before the test window is set. Legal review of these terms is a responsibility the entity keeps.
How should entities track remediation after a TLPT?
Weak remediation tracking leaves findings open, unassigned or closed without evidence, and the submission after testing relies on remediation plans that must be credible. Many entities record findings in a spreadsheet, assign owners informally and close items without retest, which makes it hard to show what changed. The fix is to log each finding in a tracked system with severity, owner, due date, root cause and a retest result, and to link each closed item to the change record that fixed it. Tools such as Wazuh or OpenSearch Security Analytics can show whether detections fired during the test, which helps verify that the defensive gap actually closed. Confirm with your authority how remediation evidence should be presented.
Why does TLPT evidence fail when it is assembled only at the end?
When evidence is gathered only after the test, logs may have rotated, scope decisions may be undocumented and the attestation package becomes a reconstruction rather than a record. The submission requires a summary of findings, remediation plans and compliance documentation, and a package built from memory is harder to defend. The fix is to define the evidence list at the start, including scope approvals, rules of engagement, tester qualifications, provider agreements, detection logs, and change records, and to collect it continuously as the engagement progresses. Assign an owner for each evidence item and store it in a controlled repository. Self-hosted platforms such as Wazuh and MISP can retain the logs and threat intelligence records that show what was detected and shared during the test, provided retention is configured before testing starts.
Can an entity fix these TLPT gaps by doing the work itself?
Many entities can handle parts of TLPT preparation internally, such as function mapping, evidence indexing and remediation tracking, but scope design, provider contracting and the choice of testers involve decisions that need senior ownership and specialist input. An outside implementation partner can prepare systems, logging, tracking tools and evidence collection, while testing is performed by testers that meet the requirements, and the competent authority issues any attestation. Ask any partner to show how its work maps to each gap above, and confirm in writing which items are in and out of the agreed scope before work starts. DeployOpen plans and implements self-hosted open-source platforms inside the client's infrastructure and runs security testing, but it does not issue attestations or reports.
How DeployOpen prepares systems and evidence for a TLPT
DeployOpen's part in a threat-led penetration test is preparation: it helps the financial entity bring the in-scope systems to the state the agreed written scope describes, and it organizes the records the entity and its testers must hand over. The scope itself is set by the entity and validated by its competent authority, and the test covers live production systems supporting several or all critical or important functions. Before testing begins, DeployOpen works with the entity to map which applications, hosts, cloud accounts, networks and third-party components fall inside that scope, and to confirm with the entity where a provider's participation must be secured or where a pooled test is needed. Confirm early whether any ICT third-party service provider in scope will accept testing, because that answer shapes the schedule more than anything DeployOpen configures.
On the environment side, DeployOpen hardens the self-hosted platforms in scope, documents their configuration, and deploys and integrates the logging and detection tooling the entity has chosen, such as a SIEM or an open-source stack like Wazuh or OpenSearch Security Analytics. The aim is that the blue team can show what was seen, when and by which rule, and that the configuration baseline is recorded before and after the test. Ask the entity to confirm which logs must be retained, who owns the detection content, and how changes made during the test will be recorded so they do not look like unexplained drift later.
DeployOpen does not act as the competent authority, does not validate the scope, and does not issue the attestation under Article 26(7). It also does not replace the independent testers the regulation requires, and the entity remains responsible for appointing them and meeting the tester rules set out in the TLPT regulatory technical standards. The evidence package DeployOpen organizes (scope records, environment baselines, logging coverage, change logs and remediation tracking) supports the summary of findings and remediation plans that the entity and its testers submit. Check with the entity's competent authority which formats and documents it expects before the package is assembled.
