It is one of the most common questions we get from CISOs and IT managers preparing for NIS 2: does the directive actually require a penetration test? The short answer is that NIS 2 never uses the word "penetration testing" — but for most in-scope organizations, a pentest is the most practical, defensible way to satisfy what Article 21 does require.
What Article 21 actually says
NIS 2 (Directive (EU) 2022/2555) sets out, in Article 21(2), ten baseline cybersecurity risk-management measures. Two of them point directly at testing:
- (e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. You have to find and manage vulnerabilities — not assume they aren't there.
- (f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. You have to prove your controls work, not just that they exist on paper.
A penetration test is the standard, evidence-producing way to do both: it uncovers exploitable vulnerabilities and demonstrates, with reproducible proof, whether your defensive measures actually hold up against a real attacker.
Why "assess effectiveness" effectively means testing
Regulators and auditors do not accept "we have a firewall" as evidence that risk is managed. Article 21(2)(f) shifts the burden to demonstrable effectiveness. In practice that means independent testing — vulnerability assessments for breadth, and penetration testing for depth — on the systems that support your essential or important services.
Add to this that Article 20 makes your management body accountable for approving and overseeing these measures, and Article 23 imposes strict incident-reporting deadlines (early warning within 24 hours, notification within 72 hours, a final report within a month). You cannot report quickly on weaknesses you have never looked for. Testing feeds both accountability and incident readiness.
How often should you test?
There is no single number in the directive, but the defensible baseline is:
- At least annually, so your evidence stays current for audits and management review.
- After any significant change to a critical system — a new application, a major infrastructure change, a cloud migration.
- Risk-based, meaning higher-exposure or higher-impact systems get tested more often.
NIS 2 vs DORA: a note on TLPT
If you are a financial entity, you may also fall under DORA, which is more explicit: it mandates a Threat-Led Penetration Testing (TLPT) programme for significant entities. If both regimes apply to you, the smart move is to run one testing programme that produces evidence for NIS 2 and satisfies DORA's stricter requirements, rather than duplicating effort.
Turning a test into compliance evidence
The value of a pentest for NIS 2 is not just the findings — it is how they are documented. Look for:
- Findings mapped to the specific NIS 2 measures they evidence.
- An executive summary your board and auditors can actually read.
- A prioritized, CVSS-rated remediation roadmap.
- A retest confirming the fixes worked.
That package is what turns "we did a test" into "here is proof our measures are effective."
Where to start
If you are scoping this for the first time, our free NIS 2 & DORA readiness checklist covers all ten Article 21 measures and shows where testing fits. When you are ready to generate the evidence, our NIS 2 penetration testing maps every finding back to your obligations.
Not sure which systems are in scope, or how deep to go? That is exactly the conversation to have before the audit, not during it.
This article is general information, not legal advice. Your specific obligations depend on your sector, size and role under NIS 2. Sources: Directive (EU) 2022/2555 (NIS 2), Articles 20, 21 and 23.