Does NIS2 require penetration testing?

If you've spent any time reading the NIS2 Directive text (or more likely, trying to decode it) you may have noticed that the word "penetration testing" never actually appears. So does NIS2 require pentesting or not? The short answer is: not explicitly, but in practice, yes. Here's what the legislation really says, why auditors treat pentests as non-negotiable, and what you actually need to have in place.

What Article 21 actually requires

The operational heart of NIS2 is Article 21 of Directive (EU) 2022/2555. It requires all essential and important entities to implement "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. The directive then lists ten minimum measures, two of which bear directly on testing:

• Article 21(2)(e) — policies and procedures for the handling and disclosure of vulnerabilities
• Article 21(2)(f) — policies and procedures to assess the effectiveness of cybersecurity risk-management measures

That second point is where pentesting enters the picture. If you're required to assess whether your security controls are actually working, a vulnerability scanner simply doesn't cut it on its own. Scanners tell you what patches are missing. A penetration test tells you whether an attacker can walk through the front door anyway. The two are complementary, not interchangeable, as our piece on red teaming vs penetration testing vs vulnerability scanning explains in more detail.

Why regulators treat pentesting as the default answer

Because NIS2 is a directive rather than a regulation, each EU member state transposes it into national law with some flexibility. But across jurisdictions, supervisory authorities have converged on the same expectation: regular penetration testing is the standard way to demonstrate compliance with Article 21(2)(f).

ENISA's June 2025 Technical Implementation Guidance explicitly includes VAPT (Vulnerability Assessment and Penetration Testing) among the expected controls for ongoing risk management. The Dutch NCSC and Belgium's CCB have both signalled that audit-readiness for NIS2 requires documented evidence of testing, remediation, and retesting cycles, not just a paper-based policy.

So while the word "pentest" isn't in the legislation, regulators aren't really leaving it up for debate. The NIS2 Directive explained covers the full scope of these requirements if you want a broader overview.

How often does NIS2 require testing?

Again, the directive doesn't specify a calendar. What it says is that measures must be "appropriate and proportionate" — and regulators' interpretation of that phrase is more demanding than many organisations expect.

The general industry consensus, reflected in ISACA's 2025 white paper on NIS2 and DORA, is:

• Essential entities should conduct external and internal penetration tests at least annually, and after significant infrastructure changes
   
• Important entities face a less intensive supervision regime but are still expected to perform regular testing — at minimum annually, with documentation available on request

High-risk environments (financial, health, digital infrastructure) are increasingly expected to test more frequently. A single annual test passed years ago won't hold up to scrutiny if your systems have changed significantly since then. Our article on why one-time pen testing isn't enough goes into the practical implications of this.

What auditors actually want to see

Knowing that pentesting is expected is only half the battle. The other half is understanding what auditors consider sufficient evidence. Based on current supervisory expectations across the EU, here's what you'll need:

1. A scoped pentest report — dated, covering internal and external attack surfaces, with clearly identified vulnerabilities and their exploitability
2. A remediation log — showing which findings were addressed, by whom, and when
3. Retest evidence — confirmation that critical and high-severity vulnerabilities were actually fixed, not just noted
4. An asset inventory — showing the scope of what was and wasn't tested, and why

Missing the remediation and retest documentation is one of the most common reasons organisations fail NIS2 audits. A report sitting on a shelf with no evidence of follow-up action tells an auditor very little. For a structured approach to identifying what your environment actually exposes, a ransomware vulnerability assessment can be a useful starting point.

Pentesting and the broader NIS2 compliance picture

Penetration testing sits within a wider set of obligations. Article 21 also covers incident handling, supply chain security, access controls, MFA, and encryption — all of which interact with your testing programme. A pentest that only checks the web application perimeter and ignores identity infrastructure, third-party integrations, or internal network segmentation will leave real gaps.

For SaaS and tech companies already working towards ISO 27001 or SOC 2, the good news is that much of the governance groundwork maps across directly. You can see how these frameworks relate in our ISO 27001, SOC 2, ISAE 3000, and NIS2 compliance comparison. Securance's Single Audit, Multiple Standards approach is specifically designed to avoid duplicating effort across these overlapping requirements.

If you're currently trying to determine whether your organisation's existing testing programme is sufficient for NIS2, or you're starting from scratch, it's worth running a proper gap assessment before your next audit cycle rather than hoping the existing documentation holds up.

The directive didn't name penetration testing. Regulators filled in that gap quickly enough.