The mandatory programme and TLPT

What everyone must do

Article 24 requires a digital operational resilience testing programme for every entity in scope. It must be proportionate, integrated into the ICT risk framework, cover a range of tests, and be conducted by independent parties.

Article 25 specifies: all ICT systems supporting critical or important functions are tested at least annually. Expected test types include vulnerability assessments, compatibility testing, performance testing, end-to-end testing and penetration testing.

Independence does not necessarily mean an external provider: an internal team distinct from the one that designed or operates the system meets the requirement, provided its reporting line genuinely allows it.

The programme that holds

TLPT

Article 26 reserves threat-led penetration testing for entities designated by their competent authority, on criteria of size, risk profile and systemic importance.

It follows TIBER-EU, in three phases:

Preparation. Form the white team — a restricted group that alone knows about the test — define the scope on critical production functions, select providers, obtain authority validation.

Testing. A threat intelligence provider produces a targeted threat report describing plausible adversaries and their methods. The red team replays those methods against the real systems. The blue team — the SOC — is not informed: that is what gives the test its value.

Closure. Joint red/blue playback, test report, remediation plan, attestation submitted to the authority.

Exploiting the results

A TLPT report usually contains more findings than the organisation can address in one cycle. Prioritisation follows two axes: how easily an attacker could exploit it, and the criticality of the function reached.

The findings that matter most are not the technical vulnerabilities — those get fixed — but the detection failures: how long the red team operated unnoticed, and at which step it should have been caught. That is the information that durably improves posture.