What a NIS2 penetration test actually needs to cover

Scope: web and API, not a checklist scan

A NIS2-scoped pentest against your web applications and APIs is the most direct way to evidence Article 21(2): point (e) because it tests the systems you build and maintain, and point (f) because exploitation-based testing, not a vulnerability scan, is what actually shows your controls hold up under a realistic attack.

Why an exploitation-based pentest, not a vulnerability scan, satisfies Article 21(2)(e) and (f)

Article 21(2) lists security in system acquisition, development, and maintenance, including vulnerability handling (point (e)), and policies to assess the effectiveness of risk-management measures (point (f)), among the ten categories every essential and important entity must implement. A NIS2-scoped pentest against your web applications and APIs is the most direct way to evidence both: point (e) because it tests the systems you build and maintain, and point (f) because exploitation-based testing, not a vulnerability scan, is what actually demonstrates whether your controls hold up under a realistic attack.

A checklist-driven vulnerability scan is not the same exercise. Automated scanning matches known signatures; a pentest chains findings together, probes business logic, and proves exploitability with reproducible steps - the difference between "we ran a tool" and "we know our controls work."

Not sure you're even in scope for NIS2? Run the free NIS2 scope check first - it takes about 2 minutes and the result is ungated.

How often

NIS2 sets no fixed testing cadence. Article 21(2)(f) requires a process for assessing effectiveness, not a numbered frequency, so the honest answer is risk-based - annually is standard practice for the baseline test, with extra testing after any material change.

NIS2 does not set a fixed testing cadence. Article 21(2)(f) requires a process for assessing effectiveness, not a numbered frequency, so the honest answer is risk-based: proportionate to your exposure, the sensitivity of what you process, and how often your applications change. In practice, annually is standard practice for the baseline test, with additional testing after any material change to the application or infrastructure.

What the report needs to contain to satisfy Article 21(2)(f)

A report that holds up with your competent authority, your board, or a customer security questionnaire needs to do more than list findings. At minimum, expect:

• Severity ratings for every finding, not just a pass/fail summary
• Reproduction steps for high and critical findings - reproducible proof-of-exploit, not a screenshot
• Remediation guidance a developer can act on without a follow-up call
• Findings mapped to the Article 21(2) measures they evidence, so a reviewer can see the connection directly instead of inferring it

Why mapping findings to Article 21(2) matters more than it sounds

That last point matters more than it sounds. A generic pentest report that never mentions NIS2 or Article 21 leaves the mapping work to whoever reviews it. A report built for NIS2 does that mapping upfront.

The overclaim to watch for

Some vendor pages state flatly that "NIS2 requires a penetration test." It does not - the directive never uses the phrase. What NIS2 actually requires is narrower and harder to fake: proof that your risk-management measures work, under Article 21(2)(f).

Some vendor pages state flatly that "NIS2 requires a penetration test." It does not - the directive never uses the phrase, and stating otherwise is the kind of overclaim that answer engines and careful buyers increasingly discount. What NIS2 actually requires is narrower, and if anything harder to fake: proof that your risk-management measures work, under Article 21(2)(f). A pentest is the standard way to produce that proof, but the accurate framing is "this is how you evidence the requirement," not "this is the requirement."

How Intrudify approaches a NIS2-scoped pentest

Intrudify runs a full web and API pentest and produces a report that maps each finding to the relevant Article 21(2) measures, with reproducible proof for high and critical findings and developer-ready remediation.

• Findings mapped to the relevant Article 21(2)(e) and 21(2)(f) measures
• Reproducible proof-of-exploit for high and critical findings, not a scanner printout
• Developer-ready remediation and a re-test window
• Delivered in hours, validated by OSCE3-certified testers

Intrudify runs a full web and API pentest and produces a report that maps each finding to the relevant Article 21(2) measures, with reproducible proof for high and critical findings and developer-ready remediation. It supports your NIS2 risk-management evidence; Intrudify does not itself determine your essential/important classification or certify you against the directive.

See the full penetration testing service or explore the platform it runs on.

Control	What a pentest evidences
Art. 21(2)(e)	Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure.
Art. 21(2)(f)	Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.