NIS2 Penetration Testing Requirements: Meeting the Directive's Security Testing Obligations

NIS2 and the Explicit Requirement for Security Testing

The Network and Information Security Directive 2 (NIS2), which EU Member States were required to transpose into national law by October 17, 2024, represents a substantial expansion of cybersecurity obligations across the European Union. Where the original NIS Directive (2016) applied primarily to operators of essential services and digital service providers, NIS2 extends mandatory security requirements to a far broader set of entities across 18 sectors.

Unlike HIPAA or SOC 2, where penetration testing is implied but not explicitly named, NIS2 Article 21(2)(e) is direct. It requires entities to implement "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." More significantly, Article 21(2)(f) mandates "policies and procedures to assess the effectiveness of cybersecurity risk-management measures."

That second provision -- assessing the effectiveness of security measures -- is the regulatory hook for penetration testing. You cannot credibly assess whether your security measures are effective without testing them against realistic attack scenarios. Vulnerability scans tell you whether patches are missing. Penetration testing tells you whether an attacker can compromise your organization.

ENISA (the EU Agency for Cybersecurity), which provides guidance on NIS2 implementation, has consistently identified penetration testing as a core component of the security testing programs that entities should maintain.

Essential vs. Important Entities

NIS2 classifies entities into two categories with different obligations and enforcement regimes.

Essential Entities

Essential entities operate in sectors considered critical to the functioning of the EU internal market and society. These include:

• Energy (electricity, oil, gas, hydrogen, district heating)
• Transport (air, rail, water, road)
• Banking and financial market infrastructure
• Health (healthcare providers, pharmaceutical manufacturers, medical device manufacturers)
• Drinking water and wastewater
• Digital infrastructure (DNS, TLD registries, cloud computing, data centres, CDNs, trust service providers)
• ICT service management (managed service providers, managed security service providers)
• Public administration
• Space

Essential entities are subject to proactive supervision by national competent authorities, meaning regulators can inspect compliance at any time without waiting for an incident or complaint.

Important Entities

Important entities operate in sectors that are significant but not classified as essential:

• Postal and courier services
• Waste management
• Manufacturing of certain critical products (chemicals, medical devices, electronics, machinery, motor vehicles)
• Food production, processing, and distribution
• Digital providers (online marketplaces, search engines, social networking platforms)
• Research organizations

Important entities are subject to reactive supervision -- regulators investigate after an incident or when evidence of non-compliance surfaces.

Implications for Penetration Testing

Both essential and important entities must implement the risk management measures specified in Article 21, including security testing. The difference is in enforcement intensity and penalties:

• Essential entities face fines of up to 10 million EUR or 2% of total worldwide annual turnover (whichever is higher)
• Important entities face fines of up to 7 million EUR or 1.4% of total worldwide annual turnover (whichever is higher)

The scale of these penalties -- comparable to GDPR -- signals that NIS2 compliance is not a suggestion. Organizations that cannot demonstrate they have tested the effectiveness of their security measures are exposed to significant financial and reputational risk.

How Penetration Testing Maps to NIS2 Requirements

Article 21 specifies ten categories of cybersecurity risk-management measures. Penetration testing provides evidence for several of them.

Article 21(2)(a) -- Risk Analysis and Information System Security Policies

Entities must adopt policies for risk analysis and information system security. Penetration testing is a risk identification mechanism that feeds directly into the risk analysis process. It identifies real, exploitable vulnerabilities rather than theoretical risks, providing the empirical data that risk analysis requires to be credible.

Article 21(2)(b) -- Incident Handling

Entities must implement processes for incident handling. Penetration testing exercises the incident detection and response chain. When a penetration tester triggers an alert, the response workflow -- from detection through triage through containment -- demonstrates that incident handling procedures function in practice.

Organizations that conduct penetration tests without notifying their security operations team ("blind testing") get the additional benefit of validating their detection capabilities against realistic attack activity.

Article 21(2)(d) -- Supply Chain Security

NIS2 places significant emphasis on supply chain security. Article 21(2)(d) requires entities to address security-related aspects of relationships with direct suppliers and service providers, taking into account the vulnerabilities specific to each supplier and the overall quality of products and cybersecurity practices of suppliers.

Penetration testing supports supply chain security in two ways:

1. Testing your own supply chain integration points. APIs, data feeds, authentication delegations, and shared infrastructure that connect your systems to suppliers and service providers are all penetration testing targets. Compromising a supply chain integration is one of the most common attack paths in sophisticated campaigns.

2. Requiring penetration testing from your suppliers. As part of your supplier risk management program, you can require that critical suppliers perform regular penetration testing and share summary results. This provides evidence that the supplier's security controls are effective, not just documented.

Article 21(2)(e) -- Security in System Acquisition, Development, and Maintenance

This provision explicitly addresses vulnerability handling and disclosure. Penetration testing is the primary mechanism for identifying vulnerabilities in custom applications, bespoke integrations, and internally developed systems that vulnerability scanners cannot effectively evaluate.

For organizations that develop software, penetration testing before production deployment validates that secure development practices have been effective. For organizations that procure software, penetration testing validates that the vendor's claims about security are accurate.

Article 21(2)(f) -- Assessing Effectiveness of Risk Management Measures

This is the most direct mandate for penetration testing in NIS2. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures are not optional -- they are a required element of every entity's security program.

"Effectiveness" is the operative word. A firewall rule exists (that is a control). Does the firewall rule actually block the traffic it is supposed to block (that is effectiveness)? An application requires authentication (that is a control). Can the authentication be bypassed (that is effectiveness)?

Penetration testing is the most rigorous method available for assessing control effectiveness because it tests controls against the same techniques that real attackers use. Policy reviews confirm that controls are documented. Vulnerability scans confirm that patches are applied. Penetration testing confirms that the combination of all controls actually prevents unauthorized access.

Article 21(2)(g) -- Basic Cyber Hygiene Practices and Training

While penetration testing is not itself a "cyber hygiene practice," its findings drive targeted security awareness training. Social engineering testing -- phishing simulations, pretexting calls, and physical access attempts -- identifies specific hygiene gaps that training programs should address.

Article 21(2)(j) -- Use of Cryptography and Encryption

Penetration testing evaluates whether cryptographic implementations are effective, not just present. Weak TLS configurations, improper certificate validation, hardcoded encryption keys, and insecure key management practices are all findings that penetration testers identify but automated scanners often miss.

For ongoing monitoring of cryptographic controls and other external security measures, see our NIS2 directive external security guide.

Member State Implementation Variations

NIS2 is a directive, not a regulation. This means each EU Member State transposes the directive into national law, and implementations can vary. Some Member States may impose requirements that go beyond the directive's minimum provisions.

As of early 2026, several patterns have emerged in national transpositions:

Explicit Penetration Testing Requirements

Some Member States have transposed NIS2 with explicit references to penetration testing as a required security testing activity. In these jurisdictions, there is no ambiguity: entities must perform penetration testing at a specified frequency (typically annual).

Prescriptive Testing Frameworks

Certain Member States have issued supplementary guidance specifying the testing frameworks, methodologies, and tester qualification requirements that entities should follow. These may reference CREST, CHECK, PTES, or national equivalents.

Sector-Specific Requirements

National competent authorities for specific sectors (energy regulators, financial supervisors, health authorities) may impose additional testing requirements beyond the NIS2 baseline. Financial entities subject to both NIS2 and DORA, for example, must meet whichever set of requirements is more stringent.

Reporting Requirements

Some transpositions require entities to report penetration testing results to their competent authority, either proactively or upon request. Others require only that evidence be available for inspection.

Organizations operating across multiple EU Member States must navigate these variations and ensure their penetration testing program satisfies the most stringent applicable requirements.

Demonstrating NIS2 Compliance Through Penetration Testing

Building a penetration testing program that demonstrates NIS2 compliance requires more than performing an annual test. The program must be structured to produce evidence that maps to specific Article 21 provisions.

Scope Aligned to Critical Services

The penetration test scope should align with the network and information systems that support the entity's essential or important services. A manufacturing company classified as an important entity under NIS2 should ensure that its industrial control systems, OT (Operational Technology) networks, and supply chain management systems are in scope -- not just its corporate IT environment.

Risk-Based Prioritization

NIS2's risk-management approach means that testing should prioritize the systems and services that pose the greatest risk to the entity's operations and to the broader sector. A DNS provider classified as essential digital infrastructure should prioritize testing of its resolution infrastructure and management plane. A hospital should prioritize patient-facing systems and medical device networks.

Documented Methodology

Maintain a documented penetration testing methodology that references industry-accepted frameworks (PTES, OWASP Testing Guide, NIST SP 800-115). The methodology document should map each testing phase to the NIS2 provisions it supports.

Remediation Tracking

Implement a formal process for tracking remediation of penetration testing findings from identification through resolution through verification. This process demonstrates Article 21(2)(e) (vulnerability handling) and Article 21(2)(f) (effectiveness assessment) in action.

Finding:       Unauthenticated access to internal monitoring dashboard
NIS2 Mapping:  Art. 21(2)(a) — Information system security
               Art. 21(2)(f) — Effectiveness assessment
Severity:      High
Detected:      2026-02-10
Remediated:    2026-02-15 (authentication + network ACL added)
Verified:      2026-02-17 (retest confirmed access denied)

Supply Chain Testing

Include third-party integration points in your penetration test scope. Document which supplier systems were tested, what vulnerabilities were identified, and how the findings were communicated to the affected supplier. This provides evidence for Article 21(2)(d) (supply chain security).

Incident Response Validation

Use penetration testing to validate incident handling procedures (Article 21(2)(b)). Document whether the security team detected the penetration tester's activity, how long detection took, and what response actions were triggered. This evidence demonstrates that incident handling is not just documented but operational.

Frequency and Timing

NIS2 does not specify a penetration testing frequency. The requirement to assess effectiveness of risk management measures is ongoing, which implies regular rather than one-time testing.

Industry practice and emerging regulatory guidance suggest:

• Annual penetration testing as a minimum baseline for all essential and important entities
• More frequent testing for entities with higher risk profiles, rapid change cycles, or sector-specific requirements
• Event-triggered testing after significant changes to network architecture, critical applications, or supplier relationships
• Pre-deployment testing for new systems that will support essential or important services

Organizations should document their testing frequency rationale as part of their risk management framework. The rationale should reference the entity's risk profile, the criticality of its services, and any sector-specific guidance from the national competent authority.

Penalties and Enforcement

NIS2's penalty regime is designed to ensure that non-compliance has meaningful consequences.

Beyond the financial penalties (up to 10 million EUR / 2% of turnover for essential entities), NIS2 Article 32 grants competent authorities broad enforcement powers:

• On-site inspections and off-site supervision
• Targeted security audits performed by an independent body
• Ad hoc audits, including where justified by a significant incident
• Requests for evidence of cybersecurity risk-management measures

An entity that cannot produce evidence of security testing when requested by its competent authority is in a weak position. A structured penetration testing methodology with documented scope, findings, and remediation records provides the evidence that competent authorities expect.

Management bodies of essential and important entities can be held personally liable for ensuring compliance with Article 21. This personal liability provision elevates NIS2 compliance from an IT concern to a board-level obligation.

Next Steps

If your organization operates in one of the 18 sectors covered by NIS2 and provides services within the EU, compliance with Article 21 is not optional. The question is not whether to perform penetration testing -- it is whether your current testing program produces the evidence that demonstrates compliance.

If you are evaluating whether your organization needs a penetration test, NIS2 compliance is a clear driver for any entity classified as essential or important under the directive.

Our Penetration Testing Scoping Wizard helps you define the right scope for a NIS2-aligned penetration test, mapping your critical services to testing targets. And our services team can help you build a testing program that satisfies Article 21 across all applicable provisions and Member State requirements.