NIS2 Penetration Testing Requirements Explained
While NIS2 doesn't explicitly use the phrase "penetration test", its technical requirements make manual security testing effectively mandatory for any organisation subject to the directive. Here is what the regulation actually requires and what that means in practice.
What NIS2 Article 21 requires
NIS2 Article 21 mandates that essential and important entities implement "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. The specific obligations relevant to security testing include:
- Policies on risk analysis and information system security
- Business continuity and crisis management, including incident response and recovery
- Supply chain security: security in network and information systems acquisition and maintenance
- Policies and procedures to assess the effectiveness of cybersecurity risk management measures
- Use of multi-factor authentication, secured voice, video and text communications, and secured emergency communications
The phrase "assess the effectiveness of cybersecurity risk management measures" is the key obligation. Regulators interpret this to mean active validation, not just documentation. A policy that says "we have access controls" does not satisfy NIS2. You need evidence that the access controls actually work and that a real attacker cannot bypass them.
Why automated scanning is not sufficient
Many organisations attempt to satisfy NIS2 testing requirements with automated vulnerability scanners. Regulators and national supervisory authorities are increasingly rejecting this approach for two reasons.
First, automated scanners test for known vulnerability signatures. They cannot assess whether your business workflows are exploitable, whether your access controls hold under adversarial conditions, or whether an insider threat could reach critical systems. NIS2 requires you to validate real world resilience, rather than just generating a list of known CVEs.
Second, the evidence must be auditable. A scan report from an automated tool does not demonstrate that human expertise was applied. Manual penetration testing with documented methodology, findings, and remediation guidance is the standard of evidence that modern NIS2 auditors require.
How manual testing satisfies NIS2 obligations
NIS2 obligation
Risk analysis
A Security Retainer begins with a structured Risk Discovery session that maps your business risks and produces a prioritised backlog of objectives, directly satisfying the obligation to maintain and act on risk analysis.
NIS2 obligation
Effectiveness assessment
Manual penetration testing validates whether your controls work in practice. A Privileged Access Simulation demonstrates exactly how far an attacker can go from a standard employee account. This is direct evidence of control effectiveness, rather than a theoretical assessment.
NIS2 obligation
Business continuity validation
A Cybercrime Attack Simulation tests your detection, response and recovery capabilities against a realistic threat scenario. The resulting Business Impact Report and gaps map are evidence that you have actively tested your incident response.
NIS2 obligation
Auditable evidence for regulators
Every OwlAttack engagement produces a Guide Book for management and a Book of Deliverables for technical teams, both structured specifically to serve as auditable evidence in NIS2 and DORA compliance reviews.
How often do you need to test?
NIS2 does not specify a testing frequency, but the obligation to assess effectiveness is ongoing, rather than a one-time exercise. The practical interpretation from supervisory authorities in most EU member states is that testing should occur at least annually and after significant changes to your environment.
A Security Retainer addresses this by providing continuous, monthly validation rather than point-in-time assessments. This approach produces more auditable evidence, catches newly introduced risks faster, and is more cost-effective than annual engagements that must relearn your environment from scratch.
NIS2 vs DORA: key differences for security testing
DORA (Digital Operational Resilience Act) applies specifically to financial entities, like banks, insurers, investment firms, and payment providers, and is more prescriptive than NIS2 in its testing requirements. DORA explicitly mandates Threat-Led Penetration Testing (TLPT) for significant financial institutions, modelled on the TIBER-EU framework.
For most companies, the practical difference is that DORA's testing requirements go deeper into operational resilience and third-party dependency testing. Our Cybercrime Attack Simulation is designed to satisfy DORA's TLPT requirements by using realistic threat scenarios rather than scripted test plans.
Get auditable evidence for your NIS2 compliance
Manual testing only. Reports structured for regulators. Serving EU companies subject to NIS2 and DORA.
Speak to a specialist