DORA and NIS2: what the EU now expects you to test

Two pieces of EU regulation — DORA for the financial sector and NIS2 for essential and important entities — have turned security testing from a good idea into an expectation backed by law. If either applies to you, "we do a pentest sometimes" is no longer a defensible position. This is a plain-language primer. It is guidance, not legal advice.

DORA: operational resilience for finance

The Digital Operational Resilience Act applies to financial entities across the EU and their critical ICT providers. Alongside broad resilience and incident-reporting requirements, it expects a programme of testing across important ICT systems — not a one-off. For significant entities, it goes further: periodic threat-led penetration testing (TLPT), intelligence-led red teaming aligned to the TIBER-EU framework, run against live systems under careful controls.

NIS2: a much wider net

NIS2 widens the EU's cybersecurity rules to many more sectors and organisations, classifying them as "essential" or "important." It requires appropriate risk-management measures and the means to assess their effectiveness — which in practice means regular vulnerability assessment and penetration testing, with the ability to demonstrate it to regulators. Management can be held accountable, which tends to concentrate minds.

How to prepare

• Map what applies. Determine which regime(s) cover you, and to which systems and providers.
• Make testing a programme. A recurring cadence tied to risk, not a single annual tick-box.
• Plan for threat-led testing if you're a significant financial entity — TLPT needs intelligence, scoping and risk controls well ahead of execution.
• Keep the evidence. Reports, remediation tracking and retest letters are what demonstrate compliance.
• Map findings to controls. Work with testers who can tie each finding to the obligation it supports.

The common thread is that regulators now want to see that your controls work, tested independently and documented. The organisations that will find this easy are the ones already testing seriously; the rest have some catching up to do.

Your supply chain is in scope too

Both regimes deliberately look past your own perimeter. DORA explicitly covers critical ICT third-party providers, with oversight and testing expectations that flow to them. NIS2 pulls supply-chain risk management directly into the required measures. The practical consequence is two-sided: testing your own systems is necessary but no longer sufficient — you’ll be expected to show what assurance you hold over the vendors you depend on, and increasingly you’ll be the vendor asked to provide that assurance to your customers. A clean, independent test report is fast becoming table stakes for selling into regulated buyers.

Start with an honest gap assessment

Before any testing, know where you actually stand. A short gap assessment against the relevant regime turns a vague legal obligation into a prioritised plan: which systems are in scope, which measures already exist, and where the real holes are. It also tells you which testing to do first, so your budget goes to the gaps that matter rather than to re-confirming what already works.

Inside a threat-led test: the TIBER-EU phases in practice

Where DORA requires threat-led penetration testing (TLPT) for designated significant entities, the European framework of reference is TIBER-EU. It is useful to understand its shape conceptually, even if your entity is not in scope, because it sets the quality bar regulators have in mind. A TLPT typically moves through four broad phases.

• Preparation. Scope is agreed with the authorities and a control team inside the entity; critical functions and the supporting systems that must be exercised are identified; and the engagement, roles and risk controls are established before any testing begins.
• Threat intelligence. A dedicated provider builds a targeted threat profile, producing realistic scenarios based on the actors most likely to attack an organisation of your type. The intent is that the test reflects plausible adversaries rather than a generic checklist.
• Red team. Testers attempt to achieve the agreed scenario objectives against live production systems, under strict control-team oversight, emulating the intelligence-led behaviours rather than merely scanning for known weaknesses.
• Closure. Findings are documented, replayed and discussed, often through a purple-team exercise where attackers and defenders walk through what was and was not detected, followed by remediation planning and reporting to the relevant parties.

Proportionality: how obligations scale

Neither regime expects a small entity to do what a systemically important one does. Both are built on proportionality, meaning that what is "appropriate" depends on an organisation's size, the nature and complexity of its activities, its risk exposure and how critical its services are.

• Under NIS2, obligations differ between essential and important entities, and the risk-management measures are expected to be proportionate to the risks actually faced rather than uniform across every organisation.
• Under DORA, the full ICT risk-management framework applies broadly, but the heaviest obligations, including threat-led testing, fall on entities designated as significant on the basis of defined criteria.
• Proportionality is not a licence to do less than the baseline. It shapes depth and frequency; it does not remove the core duties to manage risk, test, and demonstrate that measures work.

Evidence, retention and incident-reporting timelines

A recurring theme across both regimes is that it is no longer enough to have controls; you must be able to show that they exist, that they are operated, and that their effectiveness has been assessed. In practice that means keeping durable, dated evidence: policies and their approval history, risk assessments, test scopes and results, remediation tracking, and records of decisions.

• Retention. Treat evidence as something a supervisor may ask to see later. Keep it organised, version-controlled and retained in line with your sector's requirements and your own policies, rather than discarding it once a test is closed.
• Incident reporting. Both regimes impose notification duties on significant or major incidents, and these run on tight, staged timelines, typically beginning with an early warning shortly after an incident is detected, followed by a more detailed report and, later, a final report. The precise triggers, thresholds and deadlines are set in the regulations and technical standards for your regime and sector.
• Rehearse the reporting path before you need it: who declares an incident, who notifies, to whom, and within what window.

From test findings to controls, and who is accountable

A penetration test or TLPT delivers most value when each finding is mapped back to a specific control requirement, so that remediation is traceable rather than ad hoc. Tie a finding to the measure it relates to, for example access control, encryption, logging and monitoring, vulnerability management or supply-chain oversight, and record the risk decision and remediation owner for each.

• This mapping turns a test report into evidence that your risk-management measures are being assessed and improved, which is exactly what both regimes expect.
• Accountability sits with the top. Both DORA and NIS2 push responsibility to management bodies: they are expected to approve and oversee risk-management arrangements, and management can be held accountable for failures. Governance, training and documented oversight are part of compliance, not an afterthought.