
With the full enforcement of the Cybersecurity Act (Cbw), the burden of proof for digital resilience has shifted toward demonstrable effectiveness. The duty of care requires organizations to go beyond static compliance frameworks, implemented measures must be proven to withstand modern attack techniques.
An NIS2 pentest provides the necessary offensive validation to test this resilience. It delivers the technical evidence required to close the gap between theoretical risk management and operational reality.
The transition from the European NIS2 Directive to the Dutch Cybersecurity Act marks a fundamental shift in cybersecurity regulation. Where previous legislation often focused on best-effort obligations, the Cbw places emphasis on accountability for results. Organizations within the “essential” and “important” sectors must not only have secure systems, but must also proactively and periodically validate their effectiveness.
Under the Cbw, organizations must be able to prove that their measures are effective against modern threats such as ransomware-as-a-service and complex supply chain attacks. Static audits, which provide only a snapshot of processes, are no longer accepted by the Dutch Inspectorate for Digital Infrastructure (RDI) as sufficient evidence.
The duty of care under the Cbw (Article 21 of the directive) requires organizations to take “appropriate and proportionate” measures. Their effectiveness can only be demonstrated by exposing them to realistic stress tests. Technical validation has become the new standard because it is the only way to verify whether layered security (defense in depth) actually works in practice.
A simulated attack by a specialized party reveals where configuration errors, weak protocols, or human mistakes undermine theoretical security. For the Cbw, this is essential, the report of an NIS2 pentest serves as objective evidence that the organization is fulfilling its duty of care.
A common pitfall in NIS2 compliance is confusing automated scanning with penetration testing. For Cbw evidence requirements, this distinction is critical:
| Feature | Vulnerability Scanning | NIS2 Pentesting (Offensive Validation) |
|---|---|---|
| Method | Automated | Manual and expert-driven |
| Focus | Known vulnerabilities (CVEs) | Logical flaws, misconfigurations, and chained attacks |
| Depth | Surface-level identification | Exploitation and post-exploitation (how far can an attacker go?) |
| Outcome | List of technical fixes | Strategic insight into risks and resilience |
While a scan shows that the “door is locked”, a pentest determines whether an attacker can still gain access through a misconfigured API or weak trust relationship. Only the latter meets the requirements for deep validation under the Cbw.
The Cbw introduces a stronger focus on executive liability. Directors and executives can be held directly accountable for negligence in fulfilling the duty of care. The absence of periodic technical validation is seen by regulators as a serious deficiency in risk management.
The risks of inadequate compliance include:
- Regulatory sanctions: Fines that can scale significantly based on global turnover.
- Operational impact: Undetected vulnerabilities leading to downtime and disruption of critical services.
- Supply chain trust: In an interconnected economy, partners, especially MSPs, require hard evidence of security before continuing or renewing contracts.
The principle under the Cbw is clear, no evidence means no compliance. An NIS2 pentest provides the necessary documentation for the GRC (Governance, Risk and Compliance) framework. To effectively embed these technical findings into policy and risk management cycles, close collaboration between technical and governance teams is essential. Specialists such as GRC Kompas help organizations translate offensive validation into a solid and defensible compliance position.
A complete Cbw evidence file includes:
- Approach and Scoping: Proof that critical business processes within Cbw scope have been tested.
- Findings and Impact: A realistic assessment of risks based on actual exploitation.
- Remediation Plan: A structured approach to resolving identified weaknesses.
- Retest Statement: Final proof for regulators that critical vulnerabilities have been resolved.
An effective pentest for WebSec clients follows a structured process to deliver maximum value for both technical teams and compliance officers:
- Scoping: Identifying which assets (IT, OT, cloud) are critical for services under the Cbw.
- Reconnaissance: Extensive analysis of the attack surface, including leaked credentials and shadow IT.
- Exploitation: Actively attempting to exploit vulnerabilities to determine real-world impact.
- Reporting: Translating technical findings into business risks and a prioritized action plan for leadership.
For Managed Service Providers (MSPs), an NIS2 pentest is not only a legal requirement but also a strategic commercial asset. Since MSPs often act as an entry point for attacks on their clients (supply chain attacks), their own resilience directly impacts the compliance of their entire customer base. An independent pentest report is, in 2026, one of the most powerful tools to demonstrate that the MSP is a secure and reliable link in the chain.
Not every test delivers the same legal and technical value. For valid Cbw evidence, a provider must offer:
- Certified experts: Such as OSCP, OSCE, or CREST-certified professionals.
- Ethical standards: Transparent methodologies and strict confidentiality.
- Business context: The ability to map technical findings to specific Cbw and NIS2 requirements.
An NIS2 pentest is not a one-time activity, it forms the foundation of a continuous improvement cycle (Plan-Do-Check-Act). In today’s threat landscape, it is the only reliable method to confirm that cybersecurity investments deliver their intended results. By integrating offensive validation into your GRC strategy, you not only comply with the Cbw, but also build an organization that is demonstrably resilient against future attacks.
