Straight answer: is pentest mandatory?

No, not explicitly. NIS2 does not list penetration testing as a mandatory measure area.

Yes, in practice. Art. 21 requires "appropriate and proportionate technical, operational and organisational measures", and MSB's supervisory practice treats pentest as a reasonable measure. If you don't do pentest, you must document why you don't, which is harder than just doing it.

Which NIS2 articles point to pentest?

Art. 21(2)(e): Security in acquisition, development and maintenance

"Security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure."

This is the main anchor. Pentest is how you verify that systems you've acquired (SaaS, licensed products), developed yourself, or maintain actually have the security you think. "Vulnerability handling" means:

Active detection (pentest, vulnerability scanning, bug bounty)
Triage (which are real, which are false positives, what priority)
Remediation (patching, compensating controls)
Verification (retest)

Art. 21(2)(f): Measuring + evaluating the effectiveness of measures

"Policies and procedures to assess the effectiveness of cybersecurity risk management measures."

Pentest is the measurement instrument for cybersecurity measure effectiveness. You may have installed WAF, EDR, MFA, but how do you know they work? Pentest verifies via controlled attack simulation.

Art. 21(2)(d): Supply chain security

"Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

Pentest of critical suppliers' systems + verification that their security matches your risk tolerance. For Swedish entities with cloud dependencies, SaaS providers, outsourced development, vendor pentest is often the only controllable measure.

Art. 21(2)(b): Incident handling

Indirectly: pentest trains both technology (SIEM detection) and process (response team) in controlled environment. Red Team engagements function as tabletop exercises on steroids.

Art. 23: Incident reporting

Indirectly: pentest finds incidents you didn't know about. If the pentester finds an ongoing attack, the incident reporting flow triggers.

What does MSB expect to see in documentation?

Per MSB's supervisory model (published 2025-12), audit focus is on processes, not individual findings. You must be able to show:

1. Pentest policy

A document describing:

Which systems are covered by recurring pentest
What frequency (annual / quarterly / on major change)
What methodology (OWASP Testing Guide, PTES, NIST 800-115)
How findings are handled (SLA per severity)
Who approves test execution

2. Execution evidence

The last 3 pentest reports (with scope document, supplier identity, date)
Retest evidence after remediation
Traceability from finding to ticket in your case management system

3. Risk management decisions

Which findings have not been remediated and why (compensating controls, accepted risk)
Who at management level approved accepted risk (NIS2 requires management approval)

4. Trends

Number of highest-severity findings per quarter (trend down = good security maturity)
Time from discovery to remediation per severity

5. Supplier risk

Which critical suppliers have shared their own pentest reports with you
How often updated reports are requested

Pentest frequency, what counts as "appropriate and proportionate"?

NIS2 doesn't say "at least once per year". But supervisory practice from MSB + other EU countries' equivalents converges on:

Risk level	Manual pentest	Continuous scanning
High (essential entity, critical infrastructure)	2x/year + after every major change	Daily, all external assets
Medium (important entity, financial, health data)	Annually + after major change	Daily
Low (minor digital actor)	Every other year or major releases	On demand

If you have only an annual pentest and no continuous measure: expect a supervisory remark, because 360 days of exposure between tests doesn't count as "proportionate" for essential entities.

Common mistakes in NIS2 pentest programs

1. Believing point-in-time pentests are enough

A pentest from January says nothing about vulnerabilities in June. NIS2 art. 21(2)(f) requires continuous evaluation. Combine annual manual pentest with daily automated scanning.

2. Never retesting

If you don't retest after fixes, you can't prove the risk is mitigated. NIS2 auditors ask specifically: "how do you know this vulnerability is fixed?", without retest the answer is just "the developer said so".

3. Not testing suppliers

Art. 21(2)(d) sets an explicit supplier risk requirement. Requesting pentest reports from critical SaaS suppliers is the minimum. Actively pentesting them (with permission) is better.

4. Adding pentest without management sign-off

NIS2 requires management to approve risk management measures. Pentest findings above a certain threshold should be escalated to the board. Document this, who got the report, when, what action decisions were taken.

5. Not mapping findings to NIS2 articles

CVSS scores are not enough. A NIS2 report should show: "this vulnerability violates art. 21(2)(h) (cryptography)", so management + auditor understand the implication beyond technical depth.

How Pentesting.se delivers NIS2-compatible pentest

Concretely what we do differently from generic pentest delivery:

Maps every finding to NIS2 articles automatically in the report, not just CWE/OWASP
Daily automated scanning provides continuous evaluation (art. 21(2)(f))
Vendor scanning of critical suppliers' public exposure, covers art. 21(2)(d)
MSB-ready report format, can be shared directly with supervisor without rework
Retest included, automatically scheduled 30 days after remediation proposal
Management report, concise executive summary for board escalation
Incident-ready, if we find ongoing intrusion, MSB notification templates activate within the 24h window

What do I do as a NIS2-scoped organization right now?

Three steps, in order:

Inventory what you have, which pentest reports do you have for the last 24 months? What do they cover? What do they not cover?
Identify gaps, applications / infrastructure / suppliers that haven't been covered. List in priority by business criticality.
Establish annual cycle, monthly: continuous scanning. Quarterly: vendor report update. Semi-annual or annual: manual pentest. On major change: ad-hoc pentest.

Need help building or revising your NIS2 pentest program? Contact us, we do NIS2 mapping as standard delivery, not an add-on.