CyberSilo Penetration Testing for NIS2 Essential Entities

The NIS2 Penetration Testing Obligation for Essential Entities

Understanding exactly where penetration testing sits within the NIS2 framework is critical for compliance planning. The Directive does not prescribe a specific testing methodology, frequency, or certification standard — that discretion is left to national transpositions and competent authorities. However, the regulatory logic is unambiguous.

Legal Basis: Article 21 and the Risk Management Measures

Article 21(2) of the NIS2 Directive (Directive (EU) 2022/2555) requires Essential and Important Entities to implement measures covering at least ten specific areas. The most directly relevant to penetration testing are:

• Paragraph (d) — Security assessments and testing: This explicitly includes vulnerability assessments and, by logical extension, penetration testing as the primary mechanism for validating those assessments.
• Paragraph (c) — Business continuity and crisis management: Penetration testing of backup systems, failover mechanisms, and disaster recovery procedures is increasingly expected by regulators.
• Paragraph (i) — Supply chain security: Testing the security of third-party services, APIs, and interconnected systems that Essential Entities rely upon.

Recital 89 reinforces this by stating that entities should take appropriate measures to test the effectiveness of cybersecurity measures, including through regular and targeted security assessments. Where national transpositions (e.g., BSI in Germany, ANSSI in France, NCSC in the UK) have published implementation guidance, penetration testing is universally cited as a core validation activity.

Evidence Burden: What Regulators Expect

The practical challenge for Essential Entities is not whether to perform penetration tests — it is proving to national competent authorities that testing has been conducted systematically, with documented scope, qualified testers, and remediation tracking. Enforcement actions under NIS2 (and its predecessor NIS1 across multiple member states) have demonstrated that regulators require:

• Dated test reports with clear scope definitions
• Evidence of tester qualifications and independence
• Remediation plans with timelines and closure evidence
• Progressive testing coverage across the entity's critical infrastructure over a defined cycle

Scoping a NIS2-Compliant Penetration Test

A penetration test that satisfies both regulatory scrutiny and genuine risk reduction requires careful scope definition. Essential Entities should structure their testing programme around three distinct dimensions.

Critical Systems and Networks

NIS2 applies to entities across energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. The testing scope must encompass all systems that support the delivery of essential services as defined in the entity's registration with the competent authority. This typically includes:

• Operational technology (OT) and industrial control systems (ICS) for energy, water, and transport sectors
• Core network infrastructure, including routers, switches, firewalls, and load balancers
• Critical application servers and databases supporting the essential service
• External-facing web applications, APIs, and customer portals

Supply Chain and Third-Party Components

Article 21(2)(i) specifically requires measures addressing supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. Penetration testing should therefore extend to:

• Managed service providers (MSPs) and managed security service providers (MSSPs) handling critical data or infrastructure
• Cloud service providers hosting essential service components
• API integrations with third-party platforms that process or transmit sensitive data
• Software supply chain components, particularly where open-source libraries or third-party SDKs are used

Testing Frequency and Triggers

While NIS2 does not mandate a specific cadence, the regulatory expectation across most EU member states is moving toward:

• Full-scope penetration testing at least annually
• Targeted testing after every major infrastructure change, including cloud migrations, network redesigns, and new application deployments
• Ad-hoc testing following significant vulnerability disclosures (e.g., critical CVSS 9.0+ vulnerabilities affecting in-scope systems)
• Tabletop and red team exercises at least every two years to validate detection and response capabilities alongside technical testing

Technical Standards and Testing Methodologies

To ensure that penetration testing evidence is defensible before national competent authorities, Essential Entities should mandate the use of established testing standards. The most widely recognised frameworks are:

Evidence Requirements: Documentation That Satisfies Regulators

The quality of penetration testing documentation directly determines whether an entity can demonstrate compliance during a supervisory investigation. Essential Entities should ensure that every test produces the following artefacts:

Formal Scoping Document

Pre-test documentation that clearly defines the systems, networks, and applications in scope, along with any exclusions and their justifications. This document should be signed off by both the testing team and the entity's CISO or equivalent senior security lead.

Methodology and Limitations Statement

Explicit documentation of the testing methodology employed, the tools used, the testing approach (white-box, grey-box, or black-box), and any limitations that could affect the validity of results (e.g., time constraints, restricted access, production system sensitivities).

Vulnerability Findings with Risk Ratings

Each finding must include:

• CVSS v3.1 or v4.0 base score with vector string
• Proof of concept or exploitation steps (without providing full weaponisation scripts)
• Business impact assessment specific to the entity's essential service delivery
• Affected systems, versions, and configurations

Remediation Guidance and Re-testing

Actionable remediation recommendations prioritised by risk, along with confirmation of re-testing methodology and timelines. Regulators increasingly expect to see evidence that critical and high-severity findings have been remediated and re-tested within defined SLAs — typically 30 days for critical, 60 days for high.

Selecting a Penetration Testing Provider for NIS2 Compliance

The independence and competence of the testing provider is a material factor in regulatory defensibility. Essential Entities should evaluate providers against the following criteria:

Implementing a Continuous Penetration Testing Programme

Annual point-in-time testing, while necessary, is no longer sufficient for NIS2 compliance in practice. National competent authorities increasingly expect a continuous or at least regularly recurring testing programme that adapts to the entity's changing threat landscape and infrastructure.

Programme Structure

A robust NIS2-aligned penetration testing programme should include:

• Annual full-scope testing: Comprehensive coverage of all critical systems and networks supporting essential service delivery
• Quarterly targeted testing: Focused assessments on high-risk components, newly deployed systems, and critical external-facing assets
• Continuous vulnerability scanning: Weekly authenticated and unauthenticated scanning with defined remediation SLAs
• Red team exercises: Scenario-based testing every 18–24 months to validate detection and response capabilities
• Supply chain testing: At least annual testing of critical third-party integrations and managed service provider environments

Remediation Governance and Tracking

Without effective remediation governance, even the most thorough penetration test delivers limited compliance value. Essential Entities should establish:

• Centralised vulnerability register with formal ownership, status tracking, and closure evidence
• Defined risk acceptance process for findings that cannot be remediated within standard SLAs, requiring CISO and relevant business stakeholder sign-off
• Quarterly compliance reporting to the board or equivalent governing body, including testing completion rates, open findings by severity, and remediation velocity

Penetration Testing vs. Vulnerability Assessment: Regulatory Distinction

It is essential for compliance teams to understand the regulatory distinction between vulnerability assessments and penetration testing, as NIS2 Article 21(2)(d) references "security assessment and testing" as separate but complementary activities.

Both activities are necessary for a NIS2-compliant security testing regime. Vulnerability assessments demonstrate consistent security hygiene and monitoring, while penetration testing provides the adversarial validation that regulators and auditors consider most probative of genuine security posture.

Common Compliance Gaps and How to Avoid Them

Based on supervisory findings across early NIS2 enforcement actions and NIS1 transitional audits, the most common penetration testing compliance gaps include:

• Insufficient scope: Testing only external-facing systems while excluding internal networks, OT environments, or supplier connections that are critical to service delivery
• Inadequate tester independence: Using the same team that designed or maintains the tested systems to perform the assessment, undermining the adversarial value of the test
• Poor remediation tracking: Conducting tests but failing to demonstrate closed-loop remediation with re-testing and risk acceptance governance
• Missing regulatory context in reporting: Producing technical reports that lack the compliance mapping and business impact analysis that regulators require
• No evidence of programme governance: Failing to document the testing policy, frequency rationale, scope review process, and management oversight of the overall programme