NIS2 and Penetration Testing – What the Law Requires

NIS2 raises the bar for how organizations manage cybersecurity risk. For security managers and compliance officers, that raises a practical question: what does it actually mean for security testing?

If you want a broader overview of NIS2, who it applies to, what it requires, and the consequences of non-compliance, start with our introductory article: What is NIS2 and what does it mean for you?

This article focuses on a specific question that rarely gets a straight answer: does NIS2 require penetration testing, and what actually counts as sufficient?  

Does NIS2 require penetration testing? Short answer.

NIS2 does not explicitly require penetration testing, but the directive requires organizations to conduct risk assessments, manage vulnerabilities systematically, and verify that security measures actually work. In practice, that points toward structured security testing – and for critical systems and essential entities, that typically means penetration testing.

Supervisory authorities across the EU have also started clarifying what "appropriate and proportionate measures" actually looks like in practice. Automated scanning rarely holds up on its own for high-risk systems. Manual, methodical testing is what is expected.

Relevant provisions of Article 21

Article 21 of NIS2 requires covered organizations to implement technical and organizational measures to manage risks to their network and information systems. Several provisions are directly relevant to security testing.

• Risk analysis and information security requires organizations  to continuously assess their risk exposure. A penetration test provides concrete input: what is actually exploitable, and how serious is it?
  ‍

• Vulnerability management means organizations  must identify, prioritise, and remediate vulnerabilities systematically. Penetration testing is one of the most effective ways to validate that vulnerabilities are real and actually exploitable in your specific environment.
  ‍

• Security of systems and networks covers requirements to protect critical infrastructure and applications. Testing those systems under controlled conditions is a direct way to demonstrate compliance.
  ‍

• Incident handling connects to testing in a way that is often overlooked. Regular penetration tests reduce the likelihood of an incident occurring, and give organizations  better footing to understand and contain damage if something does happen.

NIS2 does not require penetration testing in so many words, but the requirements around verification, risk assessment, and vulnerability management make it difficult to argue you are meeting the directive without it – at least for high-risk systems.

What kind of penetration test meets the requirements?

Not all penetration tests carry equal weight under NIS2. The directive calls for proportionate measures, meaning the testing should match the risk profile of the systems being tested. For essential entities and critical systems, automated scanning and surface-level manual testing are not enough.

This is also where many organizations trip up. They tick the box marked "penetration test completed" without asking whether the test would actually hold up to scrutiny. Often, it would not.

What supervisory practice points toward:
‍

• Recognized methodology. The test should follow established frameworks such as OWASP, OSSTMM, PTES, or ISSAF. This demonstrates that testing is systematic and consistent with industry standards.
  

• Qualified testers. Certifications such as OSCP or CREST are a way to document the competence of those conducting the test. Supervisory authorities expect testers to have relevant experience and be able to justify their methods.
  ‍

• Independence from the development team. NIS2's emphasis on independent testing weighs against having your own security or development team test critical systems. Internal teams often have deep technical knowledge, but they lack the external perspective needed to see what an attacker sees.
  ‍

• A documented report with classified findings. The test should produce a written report where vulnerabilities are rated by severity, and remediation steps are clearly defined. A report that simply lists findings without context or prioritization does not meet what is expected.

How often should you test?

NIS2 does not specify a testing frequency. What the directive requires is that security measures are ongoing and adapted to the risk profile – meaning frequency should be driven by how quickly the environment changes and how critical the systems are.

Comparable frameworks offer a practical reference point. PCI-DSS requires at least one external penetration test per year and testing after significant changes to the network environment. ISO 27001 expects security testing to be part of a systematic information security programme and carried out on a regular basis.

For organizations  covered by NIS2, a reasonable baseline is:
‍

• At least once a year for critical systems and infrastructure

• After significant system changes, new integrations, or security incidents

• Continuous vulnerability scanning as a complement between deeper tests

What matters is being able to demonstrate that testing is regular and risk-based, not that it follows a fixed schedule regardless of what has changed in the environment.

Documentation for the supervisory authority

The relevant national authority does not routinely request penetration test reports, but during a supervisory review, organizations are expected to produce documentation showing that security work is systematic and has actually been carried out.

What should be documented:
‍

• Test reports covering methodology, scope, findings, and severity ratings. The report should be dated and signed by the responsible tester.
  ‍

• A remediation plan showing how identified vulnerabilities were addressed, by whom, and within what timeframe.
  ‍

• Verification of remediation, ideally through a follow-up test or documented internal verification confirming that issues have been resolved.
  ‍

• Management sign-off on security measures. NIS2 places clear responsibility on leadership, and documentation should reflect that security work is anchored at the right level in the organization.

So, make sure to keep all documentation from each test in a structured archive, organized by system and date. When a review comes, you want to be able to produce a clear audit trail quickly – not piece it together from email threads going back three years.