NIS2 penetration testing is not a checkbox exercise. Article 21 does not name one single testing tool that every entity must use. It requires organisations to handle vulnerabilities and assess whether their cybersecurity risk-management measures work in practice.
That distinction matters. A vulnerability scan can tell you that a known weakness exists. A DAST scan can test a running web application for common issues. A penetration test goes further: it checks whether weaknesses can be exploited, how far an attacker could move, and whether existing controls stop the attack path.
For EU companies preparing for NIS2, the practical question is: “Can we prove what was tested, what failed, what was fixed, and what evidence closes the finding?”
This article explains what NIS2 Article 21 means for vulnerability testing, when penetration testing is the right evidence mechanism, what a NIS2-ready report should contain, and how Dutch organisations can use MIAUW as a useful reference for audit-value testing.
TL;DR
NIS2 Article 21 requires vulnerability handling under Article 21(2)(e) and control effectiveness assessment under Article 21(2)(f). Automated scans help find known vulnerabilities, but they do not prove whether controls prevent exploitation. For high-risk systems, a scoped penetration test can produce stronger Article 21 evidence: scope, methodology, validated findings, remediation actions, and retest results. Dutch organisations can use MIAUW as a practical reference for audit-value penetration testing.
Does NIS2 require penetration testing?
NIS2 requires organisations to manage cybersecurity risk with measures that are appropriate and proportionate to their exposure. Article 21(2)(e) covers security in acquisition, development and maintenance, including vulnerability handling and disclosure. Article 21(2)(f) covers policies and procedures to assess whether cybersecurity risk-management measures are effective.
That does not mean every system in every organisation needs the same penetration test every year. It means the organisation must be able to show that vulnerabilities are found, assessed, remediated, and that security controls work.
For a low-risk internal tool, vulnerability scanning and secure configuration review may be enough. For an internet-facing application, payment platform, customer portal, operational technology gateway, or API handling sensitive data, a manual penetration test is often the stronger evidence route.
A good NIS2 testing plan should answer three questions:
- Which systems are in scope for Article 21 risk?
- Which testing method proves the risk is being managed?
- Which evidence will satisfy management, auditors, customers, or supervisory authorities?
The answer may include vulnerability scanning, DAST, penetration testing, code review, configuration review, or supplier testing evidence. Penetration testing becomes necessary when the organisation needs proof of exploitability and control effectiveness, not only a list of known CVEs.
Which NIS2 Article 21 obligations require vulnerability testing
Article 21(2)(e) and Article 21(2)(f) are the two relevant obligations for vulnerability testing.
Article 21(2)(e): vulnerability handling and disclosure
Article 21(2)(e) requires security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
In practice, this means the organisation needs a repeatable process for finding, assessing, prioritising, fixing, and documenting vulnerabilities. Vulnerability scans support this requirement because they identify known weaknesses in systems, ports, software versions, packages, and configurations.
But scanning alone is not the full process. The organisation also needs ownership, remediation tracking, exception handling, supplier coordination, and evidence that the finding was closed.
Article 21(2)(e) answers: “Do we have a process for finding and handling vulnerabilities?”
Article 21(2)(f): control effectiveness assessment
Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
This is where penetration testing becomes more relevant. A scan may detect that a weakness exists. A penetration test checks whether that weakness can be exploited despite the controls that are supposed to prevent or limit the attack.
For example, an access control rule may exist in policy. A penetration test can show whether privilege escalation is still possible. A web application firewall may be configured. A penetration test can show whether it blocks the attack path that matters. Logging may be enabled. A penetration test can show whether the incident trail captures the right events.
Article 21(2)(f) answers: “Can we prove our controls work under realistic attack conditions?”
If your team is still mapping all 10 Article 21 measures, start with the broader NIS2 Article 21 security requirements guide before narrowing the testing scope.
The three NIS2 testing methods: what each satisfies (and what it does not)
NIS2 specifies the outcome: vulnerability handling and control effectiveness. It does not prescribe one tool.
That is why the testing method matters. A vulnerability scan, DAST scan and penetration test all have a role, but they are not interchangeable.
A useful testing plan starts by separating three jobs:
- Find known vulnerabilities.
- Test application behaviour while the system is running.
- Prove whether an attacker can exploit weaknesses and bypass controls.
When those jobs are mixed together, companies often overestimate what their scan report proves. The report may be useful for Article 21(2)(e), but weak for Article 21(2)(f).
Vulnerability scan vs DAST vs penetration test: NIS2 compliance comparison
| Testing type | What it is | NIS2 Article 21 measure it supports | Limitation — what it does not cover |
|---|---|---|---|
| Vulnerability scan | Automated scan of known CVEs, exposed services, ports, software versions and misconfigurations. Common tools include Nessus, Qualys and OpenVAS. | Supports Article 21(2)(e) by helping identify known vulnerabilities. Also supports risk assessment when findings are prioritised. | It cannot chain vulnerabilities, test business logic, validate attack paths, or prove whether controls stop exploitation. |
| DAST | Dynamic Application Security Testing against a running web application or API. It can detect issues such as XSS, SQL injection, weak authentication flows, and API exposure. | Supports Article 21(2)(e) for application vulnerability handling. It can partly support Article 21(2)(f) for application control checks. | It does not cover full infrastructure risk, supplier exposure, manual attack chains, or complex authorisation flaws without human validation. |
| Penetration test | Human-led simulated attack against a defined scope. It tests exploitability, attack paths and whether controls work under realistic conditions. | Strong support for Article 21(2)(e) and Article 21(2)(f), especially for high-risk systems. | It is point-in-time, scope-dependent and not a replacement for continuous vulnerability management. A narrow scope leaves out-of-scope systems untested. |
NIS2 testing methods are complementary. A vulnerability scan helps find known issues; a penetration test is stronger evidence when the organisation must prove control effectiveness.
A common compliance mistake is treating a scan result as proof that controls work. It is not. A scan can tell you that a server is missing a patch. It cannot tell you whether an attacker could combine that issue with weak access control, poor segmentation and exposed credentials to reach sensitive data. For the technical stages of scoping, exploitation, reporting and retesting, use the full penetration testing methodology guide as the deeper reference.
For NIS2 evidence, the test method should match the risk of the system. The more exposed or business-critical the system is, the more the organisation should move from automated detection to validated exploitability evidence.
How often must NIS2 entities conduct penetration testing?
NIS2 does not set one fixed penetration testing cadence for every entity. The safer way to write the requirement is this: testing frequency should be risk-based, documented, and updated when the environment changes.
For many essential and important entities, an annual penetration test for high-risk systems is a practical evidence baseline. It shows that the organisation is not relying only on historic scan results. It also gives management a yearly view of exploitability, remediation status and residual risk.
Annual testing is not enough when a major change occurs. A targeted test should be considered after changes such as:
- a new internet-facing application,
- a major cloud migration,
- a new customer portal or API,
- a significant identity and access management change,
- onboarding of a critical supplier platform,
- major architecture changes affecting segmentation or data flow.
A practical cadence can look like this:
| Trigger or entity context | Practical penetration testing cadence | Vulnerability scan cadence | Evidence to keep |
|---|---|---|---|
| High-risk internet-facing systems | At least annually, based on risk and scope | Monthly or quarterly, depending on exposure | Scope, findings, remediation plan, retest evidence |
| Important business systems with sensitive data | Annually or after major change | Quarterly or semi-annually | Risk acceptance, scan results, remediation tracking |
| New application or major release | Targeted test before or shortly after release | Scan before release and after remediation | Test report, release decision, unresolved risk sign-off |
| Supplier-operated system in scope | Review supplier test evidence annually or at renewal | Request supplier scan or assurance evidence where relevant | Supplier report summary, exceptions, follow-up actions |
NIS2 testing cadence should be risk-based. Annual testing is a practical baseline for high-risk systems, not a universal legal minimum.
The cadence should be documented in a policy or security testing plan. The plan should state which systems are tested, which method is used, who owns remediation, and when retesting happens.
If a supervisory authority, sector authority, customer contract or cyber insurance requirement sets a stricter cadence, that requirement should override the general baseline.
MIAUW: the Dutch standard for NIS2-compliant pen tests
For Dutch organisations, MIAUW is a useful methodology reference when penetration testing needs audit value. It stands for Methodiek voor Informatiebeveiligingsonderzoek met Audit Waarde, or Methodology for Information Security Research with Audit Value.
The wording matters. MIAUW should not be presented as a NIS2 certification. It does not make a company compliant by itself. Its value is that it helps structure the test so the outcome is easier to validate, repeat and present as evidence.
A MIAUW-style approach is useful for NIS2 because Article 21(2)(f) is not only about doing security work. It is about assessing whether risk-management measures are effective. That requires traceability.
A pen test with audit value should show:
- what was tested,
- what was excluded,
- which methodology was used,
- which findings were validated,
- which evidence supports the finding,
- what remediation is required,
- whether the remediation was retested.
That is different from a loose “ethical hacker report” where the scope is unclear, severity scoring is subjective, and the client cannot reproduce the evidence path later.
For Dutch entities preparing for the Cyberbeveiligingswet, MIAUW can help procurement and security teams ask better questions before commissioning a test:
- Will the report make scope and exclusions explicit?
- Will findings use a consistent scoring method such as CVSS?
- Will the report include exploit evidence where exploitation was possible?
- Will retest results be documented?
- Will the report be usable by management and auditors, not only engineers?
For full MIAUW methodology details, download our checklist to ensure that your penetration tests comply with the MIAUW framework, address inconsistencies and improve cybersecurity controls.
Need a security baseline before commissioning a full NIS2 penetration test? Start with CyberCheck if your team is not yet sure which systems carry the most risk, which gaps should be fixed first, or what evidence is already missing.
What a NIS2-compliant pen test report must contain
A NIS2-ready penetration test report should do more than list vulnerabilities. It should produce evidence that can support Article 21 risk management, internal governance, customer due diligence and remediation planning.
A strong report should contain seven elements.
1. Scope statement
The report should state what was tested and what was not tested. This includes systems, applications, APIs, IP ranges, user roles, environments, suppliers and test limitations.
Out-of-scope systems matter. If a critical payment API or identity provider was excluded, the report should say so. Otherwise management may assume coverage that the test did not provide.
2. Methodology used
The report should name the testing methodology or framework. For Dutch organisations, MIAUW can be used as a reference for audit-value testing. For application testing, OWASP WSTG or OWASP API Security Testing guidance may also be relevant.
The methodology section should not be decorative. It should explain how testing was planned, executed and documented.
3. Findings with severity scoring
Each finding should have severity, affected asset, exploit conditions and business impact. CVSS can help standardise technical severity, but the report should also explain business priority.
A medium technical finding can become high priority if it affects a public system, critical supplier connection or sensitive data flow.
4. Exploitation evidence
For Article 21(2)(f), this is the most important part of the report. The organisation needs evidence that shows whether controls worked.
Useful evidence may include screenshots, logs, request/response examples, proof-of-concept steps, affected user roles, access paths or attack chain diagrams. Sensitive proof should be handled carefully and stored under access control.
5. Remediation recommendations
A good report tells the team what to fix first. Findings should be grouped by severity, exploitability and business impact.
The remediation view should be specific enough for engineering, infrastructure, security and management teams to assign owners. “Fix access control” is not enough. “Restrict role X from endpoint Y and add server-side authorisation check before release Z” is actionable.
6. Retest results
Retesting closes the evidence loop. Without retest results, the organisation can show that a finding was reported, but not that it was fixed.
For NIS2 evidence, keep the original finding, remediation action, owner, target date and retest result together. Critical and high findings should not be left as open-ended tickets without a documented decision.
7. Executive summary
The report should include a management summary that explains risk in business terms. It should state what was tested, what the main findings were, what remains open, and what decision management needs to make.
This summary can also support Article 20 governance evidence, because management bodies need enough information to oversee cybersecurity risk. For leadership responsibilities beyond the test report, see how NIS2 Article 20 management accountability connects security evidence to board-level oversight.
These records should sit inside the wider NIS2 evidence pack, together with risk decisions, remediation tracking and management approval records.
NCSC guidance for Dutch NIS2 entities
For Dutch organisations, the Cyberbeveiligingswet is the national implementation route for NIS2. At the time of publication on 29 May 2026, the Dutch House of Representatives had approved the Cyberbeveiligingswet, and the proposal was in the Senate process. Dutch government sources advised organisations not to wait for the law to enter into force before preparing.
That timing affects how this article should be read. Dutch entities should not treat penetration testing as a last-minute audit activity. A practical way to avoid that last-minute pressure is to run a NIS2 gap analysis first, then use the results to decide which systems need scanning, DAST, penetration testing or supplier evidence. The test only creates value if there is enough time to remediate findings and retest critical issues before customer due diligence, supervisory review or board reporting.
NCSC’s expertblog on penetration testing also points to a practical problem: penetration testing can mean different things in different contexts. Without clear scoping and reporting expectations, a test can become hard to compare, hard to audit, and hard to use for management decisions.
MIAUW is relevant in that Dutch context because it creates a more structured way to commission and document penetration testing. For NIS2 preparation, that structure is the point. The organisation needs evidence that can be reviewed later, not only technical findings that live in a PDF.
How Sunbytes delivers NIS2-compliant vulnerability testing
Sunbytes helps EU companies move from unclear security posture to evidence-backed remediation. For NIS2 penetration testing, the first step is often not a full-scope test. It is a baseline: which systems matter, which risks are already known, which evidence exists, and which gaps should be fixed first.
That is where CyberCheck fits. CyberCheck is a baseline + gap + roadmap assessment. It helps teams understand their current security posture, identify priority gaps, and define what needs deeper testing. It helps decide where a penetration test should focus and what evidence the organisation should prepare.
Why Sunbytes?
Sunbytes is a Dutch technology company headquartered in the Netherlands, with a delivery hub in Vietnam. For 15 years, we have helped clients worldwide Transform · Secure · Accelerate — turning strategy into reliable delivery with security built into the way systems are designed, tested and maintained.
- CyberSecurity Solutions: Sunbytes helps reduce security and compliance risk through practical security services, CyberCheck baseline assessments and compliance readiness support. For NIS2 Article 21, CyberCheck gives teams a clear starting point: current security baseline, priority gaps and a roadmap for what to fix first before deeper testing or evidence preparation.
- Digital Transformation Solutions: Sunbytes helps companies build and modernize digital products with senior engineering teams across custom development, QA/testing, maintenance and support. For NIS2 readiness, this matters because penetration testing findings often lead back to delivery work: insecure architecture decisions, weak access control, missing test coverage, poor logging, or technical debt that needs to be fixed in the product backlog.
- Accelerate Workforce Solutions: Sunbytes helps companies scale capability and capacity through recruitment and workforce support when growth demands it. When penetration testing exposes gaps that require extra engineering, QA, security or documentation capacity, Accelerate Workforce Solutions can help teams add the right support without slowing down remediation.
If your team needs to understand where your NIS2 testing evidence stands today, start with CyberCheck: baseline, gap and roadmap before deeper testing decisions.
FAQs
No, not for every system. A vulnerability scan supports Article 21(2)(e) because it helps identify known vulnerabilities. It does not prove that controls prevent exploitation. For high-risk systems, a penetration test can provide stronger evidence for Article 21(2)(f).
NIS2 does not set one universal cadence. A practical baseline is to test high-risk systems at least annually and after major changes. The exact cadence should be based on exposure, system criticality, sector guidance, customer requirements and the organisation’s risk assessment.
MIAUW does not certify NIS2 compliance by itself. It helps structure penetration testing so the scope, evidence, scoring and reporting are easier to validate. For Dutch organisations, that can make the report more useful for NIS2 evidence and supervisory discussions.
CyberCheck is a baseline + gap + roadmap assessment. It helps identify current posture, priority gaps and next actions before a full penetration test is scoped. A full penetration test goes deeper into exploitability within a defined scope. If your team does not yet know where to test first, CyberCheck is the practical starting point.
Keep the full report, scope, methodology, findings, exploit evidence, remediation tracking, risk acceptance decisions and retest results. Store them together as one evidence package. The report alone is weaker than a complete trail showing what was found, what was fixed and what remains open.
No. Testing should be risk-based. Start with systems that are internet-facing, business-critical, connected to sensitive data, or used by critical suppliers. Document why lower-risk systems were handled through lighter testing methods such as scanning, configuration review or supplier evidence.
DAST can support application security testing, especially for web applications and APIs. It does not fully replace manual penetration testing when the organisation needs to validate attack chains, business logic flaws, authorisation issues or control effectiveness across systems.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
