NIS2 is here. Now what?
The NIS2 Directive (Directive (EU) 2022/2555) entered into force in January 2023 and EU member states were required to transpose it into national law by October 2024. The scope is dramatically wider than its predecessor. Where the original NIS Directive covered a few hundred operators of essential services per country, NIS2 pulls in thousands of organizations across 18 sectors.
If you operate in energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal services, waste management, chemicals, food, manufacturing, digital providers, or research, NIS2 likely applies to you.
The directive doesn’t prescribe specific security tools or testing frequencies. What it does require is a risk-based approach to cybersecurity, with obligations around vulnerability handling, security testing, and incident response. Penetration testing is one of the most direct ways to meet several of these obligations.
What NIS2 actually requires
Article 21: cybersecurity risk management measures
This is the core obligation. Article 21 requires essential and important entities to implement “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems.”
The measures must include, at minimum:
- Risk analysis and information system security policies
- Incident handling procedures
- Business continuity and crisis management
- Supply chain security
- Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure
- Policies and procedures to assess the effectiveness of cybersecurity risk management measures
- Basic cyber hygiene practices and cybersecurity training
- Cryptography and encryption policies
- Human resources security, access control policies, and asset management
Two of these map directly to penetration testing.
Vulnerability handling and disclosure: you need a process to identify vulnerabilities in your systems. Automated scanning catches known CVEs. Penetration testing finds what scanners miss, things like business logic flaws, authentication bypasses, access control failures, chained attack paths through your specific environment.
Assessing the effectiveness of your security measures: this is where NIS2 gets interesting. Having security controls is not enough. You need to test whether they actually work. A penetration test tells you if your firewall rules, your WAF, your segmentation, and your monitoring hold up against a motivated attacker.
Article 24: supervision and enforcement
National competent authorities (in Belgium, the CCB) have the power to require entities to undergo security audits and provide evidence of compliance. A regular penetration testing program with documented findings and remediation creates the evidence trail that satisfies these requirements.
Recital 79: proportionality
NIS2 explicitly acknowledges that measures should be proportionate to the entity’s size, exposure, and the likelihood and severity of potential incidents. The testing program for a critical infrastructure operator should look different from one for a mid-size digital service provider. But “proportionate” does not mean “optional.” Every organization in scope needs some form of security testing.
How penetration testing maps to NIS2 obligations
| NIS2 requirement | How penetration testing addresses it |
|---|---|
| Vulnerability handling and disclosure (Art. 21(2)(e)) | Identifies vulnerabilities that automated tools miss. Tests exploit chains and business logic. |
| Assessing effectiveness of measures (Art. 21(2)(f)) | Validates that security controls work under adversarial conditions. |
| Risk analysis (Art. 21(2)(a)) | Provides empirical evidence for risk assessments. Real exploitation data, not theoretical scores. |
| Incident handling (Art. 21(2)(b)) | Red team exercises test detection and response capabilities. |
| Supply chain security (Art. 21(2)(d)) | Tests integrations with third party services and dependencies. |
| Security in acquisition and development (Art. 21(2)(e)) | Application security testing validates that new systems meet security baselines. |
What a NIS2-aligned testing program looks like
Frequency
NIS2 doesn’t specify testing frequency. But the intent is clear: measures must be “regularly” assessed. For most organizations, this means annual penetration tests covering external and internal infrastructure, web applications, and APIs. On top of that, quarterly or continuous automated security testing integrated into CI/CD pipelines, event-driven tests after significant infrastructure changes or incidents, and red team assessments annually or biennially for essential entities in critical infrastructure sectors.
Financial institutions subject to DORA have more specific requirements, including TIBER-EU testing for significant entities.
Scope
A NIS2-compliant testing program should cover the full attack surface. That means external infrastructure (internet-facing systems, VPNs, email gateways, cloud services), web applications and APIs (authentication, authorization, business logic, data handling), internal networks (lateral movement paths, privilege escalation, Active Directory security), cloud environments (configuration review, identity management, cross-tenant isolation), and OT/IoT systems where applicable. Manufacturing, energy, and transport sectors especially.
Documentation
NIS2 compliance is about demonstrating that you manage risk, not just that you test. Your penetration testing program should produce scoping documents that connect testing to your risk assessment, detailed technical reports with reproducible findings, executive summaries for management and board reporting, remediation tracking showing that findings get addressed within defined timelines, and year-over-year trend analysis showing security posture improvement.
This documentation is what you show a regulator. It is your evidence that Article 21 measures are implemented and assessed.
National implementation: Belgium and beyond
Belgium
The Centre for Cybersecurity Belgium (CCB) is the national competent authority for NIS2. Belgium’s transposition expands the scope significantly from the original NIS implementation. The CCB’s CyberFundamentals framework provides a tiered approach to security measures, with penetration testing featuring in the higher assurance levels.
The CCB has been proactive about enforcement. The fines under NIS2 are substantial: up to 10 million euros or 2% of global annual turnover for essential entities, and up to 7 million euros or 1.4% for important entities.
Other EU member states
Implementation varies across member states, but the core obligations under Article 21 are consistent. If you operate across multiple EU countries, a standardized penetration testing program that satisfies the most stringent national implementation will cover you everywhere.
Germany’s BSI has been particularly specific about technical testing requirements. France’s ANSSI maintains a qualification scheme for security testing providers. The Netherlands’ NCSC has published guidance linking penetration testing to NIS2 compliance.
Common mistakes
Treating vulnerability scanning as penetration testing
Running Nessus or Qualys and calling it a penetration test does not satisfy NIS2. Automated scanning identifies known vulnerabilities in known software. Penetration testing identifies how those vulnerabilities, and ones the scanner can’t see, can be exploited in your specific environment. Both are necessary. They are not interchangeable.
Testing once and calling it done
A single annual penetration test is a snapshot. It tells you your security posture on that day. NIS2 requires ongoing assessment. The testing program needs to be continuous, or at least frequent enough to catch regressions and new exposures as your environment changes.
Not connecting testing to risk management
A penetration test report that lives in a drawer doesn’t satisfy NIS2. Findings need to feed into your risk register. Remediation needs to be tracked. The testing program needs to inform your security investment decisions in a way you can actually demonstrate.
Ignoring supply chain testing
Article 21(2)(d) explicitly requires supply chain security measures. If your penetration testing scope stops at your network boundary, you are missing the attack paths through your vendors, SaaS providers, and development dependencies.
Building a compliant program
If you are starting from scratch or upgrading an existing program to meet NIS2, here is a reasonable sequence.
Start by mapping your scope: identify which systems and services fall under NIS2. That becomes your testing perimeter. Then assess risk and prioritize testing based on criticality and exposure. Not everything needs the same depth of testing. Define a testing cadence that matches your risk profile and how often things change. Whether you use internal or external testers, make sure they can go beyond automated scanning. Document everything: reports, remediation tracking, retests. Build the evidence trail now. And make sure testing findings reach your risk management process and board reporting.
Where things stand
NIS2 has raised the bar for cybersecurity across Europe. Penetration testing is not the only thing you need, but it is one of the most effective ways to demonstrate that your security measures actually work. Organizations that build a structured, documented testing program now will have an easier time with compliance and, more importantly, will be harder to attack.
If you need help building a NIS2-aligned penetration testing program, reach out to us. We work with organizations across Belgium and Europe on testing programs that satisfy compliance and actually improve security.
