NIS2 and DORA penetration testing: what is required and what TLPT means

Summary: NIS2 (Directive (EU) 2022/2555) requires essential and important entities to assess the effectiveness of their cybersecurity measures — in practice, regular security testing including penetration tests. DORA (Regulation (EU) 2022/2554), applicable to the financial sector since 17 January 2025, is more explicit: an annual testing programme (Articles 24–25) and, for entities designated by their regulator, TLPT — threat-led penetration testing — at least every three years (Articles 26–27). Non-EU vendors serving regulated European customers inherit these expectations through contracts.

This guide explains what each regulation asks for, what TLPT is, and how to build a testing programme that survives an audit without becoming theatre.

NIS2 on one page

Who is in scope: "essential" and "important" entities in sectors such as energy, transport, health, banking, digital infrastructure, cloud and managed service providers, and manufacturing of critical products — generally medium and large companies in those sectors. Each member state transposes the directive into national law, so check the specific obligations and deadlines where you operate.

What it asks about testing: Article 21 lists minimum risk-management measures, including security in the acquisition, development and maintenance of systems (with vulnerability handling) and policies and procedures to assess the effectiveness of those measures. The directive does not prescribe "one pentest per year", but periodic testing and testing after significant changes is the most direct way to demonstrate effectiveness.

Why it matters: fines reach €10 million or 2% of worldwide annual turnover for essential entities (€7 million or 1.4% for important ones), and management bodies are held accountable. NIS2 also requires attention to supply-chain security — which is where vendors come in.

DORA on one page

Who is in scope: almost the entire EU financial sector — banks, payment and e-money institutions, insurers, asset managers, crypto-asset service providers — and, indirectly, their critical ICT third-party providers.

What it asks about testing:

• Article 24 — digital operational resilience testing programme, proportionate to size and risk, with at least annual tests of systems supporting critical or important functions.
• Article 25 — test types: vulnerability assessments, source code review where feasible, scenario-based tests, compatibility and performance testing, penetration testing, and more.
• Article 26 — TLPT: entities identified by competent authorities must run threat-led penetration tests at least every three years on live production systems, covering critical functions — including outsourced ones.
• Article 27 — tester requirements: good repute, proven technical capability, certification or adherence to a code of conduct, and professional indemnity insurance.

What TLPT is (and what it is not)

TLPT (Threat-Led Penetration Testing) is a threat-intelligence-driven red team exercise aligned with the TIBER-EU framework. A threat intelligence team describes realistic adversaries for the institution; the red team executes those scenarios against production in a controlled way; ideally the blue team does not know a test is running; a purple teaming phase and a regulator-tracked remediation plan close the exercise.

TLPT is not an enlarged application pentest. It measures the organisation’s ability to prevent, detect and respond as a whole. Application, API and AI-system penetration tests remain the backbone of the Article 24–25 annual programme — and they find the weaknesses a red team later exploits.

Building a testing programme that survives the audit

1. Map critical functions. Link each system to a business function; scope starts there, not from a list of IPs.
2. Schedule by risk. Annual pentest for everything supporting critical functions; extra cycles after significant changes (new integration, new digital channel, new AI feature).
3. Right depth. Grey box with per-role accounts and documentation for applications and APIs; dedicated testing for customer-facing AI systems.
4. Traceability. Every finding with an owner, a deadline, evidence of the fix and a retest. Auditors want the closed loop, not the PDF.
5. Supply chain. Request recent reports from ICT providers supporting critical functions — and be ready to share yours.
6. Documented tester qualifications, as DORA explicitly requires.

For payments, see what assessors expect from a PCI DSS 4.0 pentest report. For budgeting, how much a penetration test costs.

Frequently asked questions

Does NIS2 require penetration testing?

The directive requires assessing the effectiveness of security measures and handling vulnerabilities. Periodic penetration tests are the evidence regulators and auditors accept most readily, and national transposition laws tend to spell the requirement out.

How often does DORA require testing?

Tests of systems supporting critical or important functions at least once a year (Article 24) and, for designated entities, TLPT at least every three years (Article 26).

Does automated pentesting satisfy DORA?

Automated tools help with the annual programme, but DORA lists penetration testing as its own test type and requires qualified testers. TLPT requires a human red team.

We are a non-EU software vendor. Does this affect us?

If you provide ICT services to EU financial or essential entities, yes — contractually. Your customer must show its regulator that it manages third-party risk and will ask you for evidence, including recent test reports.