Article 26: Advanced testing of ICT tools, systems and processes based on TLPT

Article 26 requires in-scope financial entities to run advanced, threat-led penetration testing (TLPT) of ICT tools, systems, and processes on a recurring basis, with a minimum cadence set in the regulation and the ability for the competent authority to adjust it based on your risk profile. Operationalize it by defining TLPT scope, governance, qualified testers, safe testing rules, and a remediation-and-evidence package that stands up to supervisory review. (Regulation (EU) 2022/2554, Article 26)

Key takeaways:

• Confirm whether you are in scope for TLPT under Article 26 before building the program. (Regulation (EU) 2022/2554, Article 26)
• Treat TLPT as a governed exercise with clear scope, control points, third-party coordination, and tracked remediation closure. (Regulation (EU) 2022/2554, Article 26)
• Build a single evidence spine: approvals, test plan, results, remediation, and validation proof mapped to the requirement. (Regulation (EU) 2022/2554, Article 26)

For a CCO, Compliance Officer, or GRC lead, Article 26 is a “show me” requirement. You are expected to demonstrate that advanced testing happens, that it is threat-led, that it covers relevant ICT tools/systems/processes, and that findings turn into risk-reducing remediation you can prove. The operational trap is treating TLPT like an occasional red-team event owned only by security. Under DORA, TLPT becomes part of your regulatory control environment: scoping is a governance decision, testing has safety and third-party constraints, and remediation closure needs audit-grade evidence.

This page focuses on one job: turning Article 26 into an executable control package you can run repeatedly without reinventing it each cycle. You’ll leave with (1) an applicability checklist, (2) a step-by-step runbook from initiation through closure, (3) an evidence list aligned to how supervisors and internal audit tend to ask questions, and (4) a phased execution plan you can start immediately. Primary legal source: Regulation (EU) 2022/2554, Article 26. (Regulation (EU) 2022/2554, Article 26)

Regulatory text

Excerpt (provided): Financial entities (excluding certain entities referenced elsewhere and microenterprises) that are identified per Article 26’s identification approach “shall carry out at least every 3 years advanced testing by means of TLPT.” The competent authority may require you to adjust the frequency up or down based on your risk profile and operational circumstances. (Regulation (EU) 2022/2554, Article 26)

What the operator must do (in plain terms):

1. Determine if your entity is in scope for TLPT under Article 26 (including exclusions). (Regulation (EU) 2022/2554, Article 26)
2. Run TLPT as “advanced testing” that is threat-led and targets ICT tools, systems, and processes that matter to your risk profile. (Regulation (EU) 2022/2554, Article 26)
3. Meet the required cadence and be ready for the competent authority to direct changes to frequency based on risk. (Regulation (EU) 2022/2554, Article 26)
4. Retain supervisory-ready evidence that the test occurred, was governed, and produced remediation that you closed and validated.

Plain-English interpretation of the requirement

Article 26 expects you to prove resilience by running realistic, intelligence-driven attack simulations against critical technology and operational pathways. “Threat-led” means the exercise follows plausible attacker behavior relevant to your environment, not a generic vulnerability scan. “Advanced testing” means depth: end-to-end paths, control evasion attempts, and process breakdowns (for example, whether detection and response actually work under pressure), not only tool-level findings. (Regulation (EU) 2022/2554, Article 26)

A compliance-friendly way to frame it: TLPT is a regulated control test of your ability to prevent, detect, respond to, and recover from sophisticated ICT attacks, with outcomes tracked like a formal corrective action program. (Regulation (EU) 2022/2554, Article 26)

Who it applies to (entity + operational context)

Article 26 applies to financial entities within DORA’s scope that are not microenterprises and are identified for TLPT under the Article’s identification approach, with certain exclusions referenced in the excerpt. (Regulation (EU) 2022/2554, Article 26)

Operationally, TLPT typically touches:

• Crown-jewel services and supporting infrastructure (authentication, payment flows, trading, customer portals, core banking/ledger interfaces, etc.).
• Security operations (SOC processes, alerting, incident management, forensics).
• Technology operations (change management, access management, backups, recovery, environment segregation).
• Third parties that operate or secure parts of the tested service (cloud, managed security, payment processors, outsourced IT). The common constraint: you can’t fully test an end-to-end attack path without coordinated approvals and test windows with those third parties.

What you actually need to do (step-by-step)

1) Make an applicability decision and document it

• Create an Article 26 applicability memo: are you in scope for TLPT, and if so, why. If you believe you are excluded (microenterprise or other exclusion referenced by the Article), document the basis and get Compliance and Legal sign-off. (Regulation (EU) 2022/2554, Article 26)
• Define the “unit of testing”: per legal entity, per regulated perimeter, or per critical service. Pick one and stick to it so your cadence and evidence stay coherent under exam.

Artifact: Applicability assessment + approval record.

2) Establish TLPT governance that can survive scrutiny

Build a TLPT governance model with named owners and decision rights:

• Executive sponsor (often CIO/CISO) accountable for completion and resourcing.
• Compliance/CCO accountable for regulatory alignment and evidence quality.
• Risk owner(s) for in-scope business services.
• Test manager who runs the engagement end-to-end.
• Remediation owners aligned to systems and processes.

Add a simple regulatory-response workflow for supervisor requests (frequency changes, additional scope, follow-ups) with Legal/Compliance sign-off before commitments are made. This reduces the risk of inconsistent statements across Security, Risk, and Compliance.

Daydream fit (earned, not forced): Many teams fail on traceability. Daydream can act as the control-and-evidence register that ties Article 26 to owners, milestones, and artifacts, so you can answer supervisor questions without rebuilding the narrative each time.

Artifacts: TLPT RACI, steering committee minutes, regulatory communications log.

3) Define scope based on risk, not convenience

Scope should reflect risk profile and operational circumstances referenced in Article 26. (Regulation (EU) 2022/2554, Article 26) Practical scoping method:

• Identify critical services and map them to supporting applications, infrastructure, identities, and operational processes.
• Select “crown jewels” (data sets, privileged pathways, transaction authorizations).
• Set boundaries: production vs pre-prod, social engineering allowed or not, physical access assumptions, and third-party environments.

Control point: Require sign-off from the service owner, CISO, and Compliance on a single-page scope statement.

Artifacts: Scope statement, service/system diagrams, crown-jewel list, assumptions and constraints register.

4) Design the TLPT engagement like a regulated exercise

Your TLPT package should include:

• Threat scenario selection tied to plausible attacker goals for your entity (fraud, data theft, service disruption).
• Rules of engagement: safety controls, prohibited actions, time windows, “stop conditions,” and incident escalation paths.
• Tester qualification and independence: document selection criteria and conflicts management. Even if Security chooses the provider, Compliance should validate independence and documentation completeness.
• Third-party coordination: written approvals, points of contact, and test-safe handling of shared environments.

Artifacts: Test plan, rules of engagement, provider SOW/contract addendum, approvals from impacted third parties.

5) Execute, monitor, and record decisions in real time

During the exercise:

• Track material decisions (scope changes, stop conditions invoked, emergency changes).
• Confirm SOC and operational playbooks run as expected when test activity triggers alerts. If teams “white-list” the test too broadly, you lose evidence that detection and response work.

Artifacts: Execution log, communications record, SOC tickets/alerts, incident bridge notes (if used).

6) Report results in a way that drives remediation (and proves closure)

Demand reporting that separates:

• Technical findings (control gaps, misconfigurations, privilege escalation paths).
• Process failures (handoffs, escalation delays, unclear ownership, weak containment steps).
• Root cause and blast radius (systems/processes potentially affected).

Then run a corrective action program:

• Assign owners and due dates.
• Define “done” with validation criteria (re-test, configuration evidence, control design change).
• Track exceptions with explicit risk acceptance.

Artifacts: Final TLPT report, management response, remediation plan, risk acceptances, re-test/validation evidence.

7) Package evidence for supervisors and internal audit

Build a single “Article 26 dossier” that includes:

• Applicability memo and governance approvals. (Regulation (EU) 2022/2554, Article 26)
• Scope, rules of engagement, and third-party approvals.
• Test execution logs and final report.
• Remediation tracker with closure evidence and validation.
• Any communications with the competent authority about cadence changes. (Regulation (EU) 2022/2554, Article 26)

Required evidence and artifacts to retain (audit-ready list)

Use this as your minimum retention checklist:

• Applicability & cadence
  • Applicability assessment, exclusions rationale (if any), cadence policy/decision. (Regulation (EU) 2022/2554, Article 26)
• Governance
  • RACI, steering minutes, approvals, escalation paths.
• Scope & design
  • In-scope services/assets, threat scenarios, rules of engagement, test limitations.
• Third-party coordination
  • Written third-party consents, test windows, contact lists, contractual permissions.
• Execution evidence
  • Logs, tickets, incident workflow artifacts, decision register.
• Outcome & remediation
  • TLPT report, CAPA tracker, closure evidence, validation/re-test proof.

Common exam/audit questions and hangups

Expect questions like:

1. “Show me you are in scope (or excluded).” Provide the signed applicability memo. (Regulation (EU) 2022/2554, Article 26)
2. “Why did you choose this scope?” Show risk-based rationale tied to critical services and crown jewels.
3. “How do you control safety?” Provide stop conditions, change controls, and escalation procedures.
4. “Did you test processes or only technology?” Show evidence of operational process observations (SOC handling, escalation, recovery).
5. “How do you prove remediation is complete?” Provide validation artifacts, not only “status: closed” in a tracker.

Frequent implementation mistakes and how to avoid them

• Mistake: treating TLPT as a security-only deliverable.
  Avoid it: Make Compliance co-owner of the dossier and require business service owner sign-off on scope and remediation.

• Mistake: weak third-party permissions that force you to reduce scope late.
  Avoid it: Start third-party approvals early and bake TLPT rights into contracts and addenda where needed.

• Mistake: findings without closure proof.
  Avoid it: Define closure criteria up front (what evidence is required for each remediation type) and require re-test or validation notes.

• Mistake: “shadow” changes during the test.
  Avoid it: Require change tickets for material control changes even during a test window, then attach them to the TLPT dossier.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for Article 26, so this page does not list case examples.

Risk implications you should assume in supervisory review:

• Failure to run TLPT or inability to evidence it reads as a control failure against an explicit DORA obligation. (Regulation (EU) 2022/2554, Article 26)
• Poor remediation discipline creates compounding risk: the next TLPT cycle repeats the same gaps, and the competent authority may pressure frequency or scope based on your risk profile. (Regulation (EU) 2022/2554, Article 26)

A practical 30/60/90-day execution plan

Use phases, not promises. Your real calendar depends on scope, third-party coordination, and internal change windows.

First 30 days (Immediate setup)

• Write and approve the Article 26 applicability memo and identify the accountable exec sponsor. (Regulation (EU) 2022/2554, Article 26)
• Stand up TLPT governance: RACI, steering cadence, evidence owner, and regulatory-response workflow.
• Draft scoping criteria and a shortlist of critical services and crown jewels.
• Start third-party outreach to confirm testing permissions and constraints.

Days 31–60 (Design the engagement)

• Finalize TLPT scope, rules of engagement, and safety controls.
• Select testers and document independence/qualification decisioning.
• Confirm third-party approvals in writing and lock test windows.
• Pre-build the remediation tracker with closure criteria and validation requirements.

Days 61–90 (Run, remediate, validate)

• Execute TLPT with real-time decision logging.
• Produce the TLPT report and management response.
• Launch remediation with owners, milestones, and validation steps.
• Assemble the supervisor-ready Article 26 dossier in a single repository (Daydream is a practical place to keep the control mapping, evidence, and status in one record).

Frequently Asked Questions

How do I know if my entity must perform TLPT under Article 26?

Start with an applicability memo that documents whether you are a financial entity in scope, whether any exclusions apply (including microenterprise), and whether you are identified for TLPT under the Article’s approach. Get Legal and Compliance sign-off and retain it for exam. (Regulation (EU) 2022/2554, Article 26)

What does “threat-led” mean in practice?

Your test scenarios should reflect realistic attacker behavior and goals relevant to your environment, not a generic checklist of vulnerabilities. Document the scenario selection rationale so you can explain why it fits your risk profile. (Regulation (EU) 2022/2554, Article 26)

Can we limit TLPT to a single application to keep risk low?

You can set boundaries, but scope must still reflect your risk profile and operational circumstances, and it should cover meaningful attack paths across tools, systems, and processes. If you narrow scope, document compensating rationale and get business and Compliance sign-off. (Regulation (EU) 2022/2554, Article 26)

How should we handle third parties that don’t want us to test their environment?

Treat this as a contracting and governance issue early. Seek explicit written permissions, define test constraints, and record approvals; if limitations remain, document residual risk and consider alternative testing paths that still validate end-to-end resilience.

What evidence do supervisors typically expect beyond the final TLPT report?

They usually want governance approvals, scope and rules of engagement, execution logs, third-party consents, and proof that remediation was completed and validated. Build a single Article 26 dossier so you can produce it quickly. (Regulation (EU) 2022/2554, Article 26)

How do we stay ready if the competent authority changes the testing frequency?

Maintain a living TLPT roadmap, keep your crown-jewel inventory current, and run readiness drills on the governance and evidence process. That way, a frequency change becomes a scheduling decision rather than a rebuild of the program. (Regulation (EU) 2022/2554, Article 26)