NIS2 Penetration Testing: Article 21 Compliance and Technical Measures

The NIS2 Directive (EU 2022/2555) — in force across all EU member states since October 17, 2024 — extends mandatory cybersecurity obligations to roughly 160,000 entities across 18 critical sectors. Article 21 specifically requires 'appropriate and proportionate technical, operational and organisational measures' to manage the risks posed to network and information systems. Penetration testing is the primary technical control that competent authorities accept as evidence of compliance with Article 21. This guide explains what NIS2 actually requires, who qualifies as an essential vs. important entity, what supervisors expect, and how to build a testing programme that satisfies national competent authority scrutiny.

Run free NIS2 scan

Written by Malte Wagenbach

Founder of Matproof Security. Specialized in AI-driven penetration testing and EU compliance (DORA, NIS2, ISO 27001, SOC 2).

Last reviewed: May 17, 2026

Why NIS2 makes penetration testing a de facto mandatory control

Article 21(2) of the NIS2 Directive lists ten minimum security measures, all of which must be in place. Among these: 'handling of incidents', 'business continuity', 'supply chain security', 'network and information system security', 'policies and procedures to assess the effectiveness of cybersecurity risk-management measures', and 'basic cyber hygiene practices and cybersecurity training'. The phrase 'policies and procedures to assess the effectiveness of cybersecurity risk-management measures' (Art. 21(2)(g)) is the legal anchor for penetration testing. Competent authorities — ENISA, BSI, ANSSI, ACN, NCSC-NL, CCN-CERT, and national transposition bodies — have consistently stated that a vulnerability scan does not constitute a sufficient effectiveness assessment. A penetration test with documented scope, methodology, proof of exploitation, and a remediation plan is the accepted standard. Beyond the technical obligation, NIS2 introduced personal liability for management bodies (Art. 20): board members can face personal fines and temporary bans from management roles if they have not ensured adequate security measures, including regular testing. This is a material change from NIS1, which focused enforcement on the entity itself.

NIS2 Article 21(2)(g) requires documented procedures to assess the effectiveness of security measures — penetration testing is the industry-standard methodology accepted by EU supervisors as evidence of compliance.
Article 20 NIS2 holds management bodies personally accountable for cybersecurity governance. Board members who cannot demonstrate they reviewed recent penetration test results and oversaw remediation risk personal sanctions.
Essential entities (energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space) face fines up to €10 million or 2 % of global annual turnover (whichever is higher) under Article 34.
Important entities (postal services, waste management, chemical manufacture, food, manufacturing of medical devices/computers/electronics/vehicles, digital providers including cloud, data centre, CDN, online marketplace, search engine, social networking) face fines up to €7 million or 1.4 % of global annual turnover.
Competent authorities can conduct on-site inspections and require access to penetration test documentation at any time — entities that cannot produce a test report within the past 12 months face immediate enforcement risk.
NIS2 Article 21(3) requires entities to take into account 'the state of the art' in security measures — an annual point-in-time pentest no longer reflects the state of the art; continuous or quarterly testing is becoming the supervisory expectation.
Supply chain obligations (NIS2 Art. 21(2)(d)) mean that essential entities must assess the security of their ICT supply chain — including requiring penetration test evidence from critical SaaS and infrastructure providers.

What a NIS2-compliant penetration test must cover

Network and information system security (Art. 21(2)(e)): external attack surface enumeration, exposed services, TLS/SSL configuration (RFC 8446), DNS hygiene, subdomain takeover vulnerabilities
Authentication and access control (Art. 21(2)(a) incident handling prerequisite): credential attack resistance, MFA bypass techniques, session management, JWT signature weaknesses (CWE-327), OAuth 2.0 flows (RFC 6749 / PKCE RFC 7636)
Vulnerability and patch management (Art. 21(2)(h) basic cyber hygiene): SCA scanning against NVD/GHSA, detection of CVE-2024-43481 (Next.js middleware bypass, CVSS 9.1), CVE-2024-4577 (PHP-CGI argument injection, CVSS 9.8), CVE-2023-44487 (HTTP/2 Rapid Reset), dependency version drift
Application security — OWASP Top 10 (2021): A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection (SQL, NoSQL, LDAP, command), A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures
API security — OWASP API Top 10 (2023): API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization
Business continuity and resilience (Art. 21(2)(b)): testing backup access controls, ransomware simulation paths, availability of administrative recovery mechanisms
Supply chain security (Art. 21(2)(d)): third-party script loading risks, SRI (Subresource Integrity) validation, vulnerable npm/PyPI/Maven transitive dependencies
Incident detection capability: verifying whether attack activity during testing generates SIEM/SOAR alerts — 'we attacked and you did not notice' is a reportable finding under NIS2 Art. 21(2)(a)
Security header and transport configuration: HSTS (RFC 6797), CSP (W3C Level 2), Referrer-Policy, Permissions-Policy, CORS misconfiguration, DNSSEC, DMARC (RFC 7489)
Cloud infrastructure configuration (Growth plan): IAM privilege escalation paths, overly permissive S3 bucket policies, exposed cloud metadata endpoints (CVE-2019-11510 style SSRF), serverless misconfiguration

Sample finding

Critical

Authentication bypass via unsanitised SAML response — NIS2 Art. 21(2)(i) violation

The service provider processes SAML 2.0 authentication responses from the identity provider without validating XML signature integrity on the assertion element. The application validates the outer response signature but accepts arbitrary unsigned assertions embedded within. Using the 'XML Signature Wrapping' (XSW) technique, a tester was able to forge an authentication assertion claiming to be an administrative user, bypassing SSO entirely. All administrative functions were accessible without valid credentials from the identity provider. CVE-2023-36661 (python3-saml, CVSS 9.8) and CVE-2022-31197 (ruby-saml) describe the same class of vulnerability. This violates NIS2 Art. 21(2)(i) ('policies and procedures on cryptography and, where appropriate, encryption') and Art. 21(2)(a) ('incident handling').

Fix: Validate the XML signature on the Assertion element specifically — not only the envelope. Use a well-maintained SAML library that enforces assertion-level signature validation by default (e.g., OneLogin SAML2 for Python, xmlsec for Node.js). Enable strict mode in the library configuration. Regularly review SAML library CVEs — SAML parsing libraries have a persistent history of XSW vulnerabilities. For the identity provider configuration: disallow unsigned assertions entirely, require SP-initiated flows, set short assertion TTLs (max 5 minutes). Post-fix re-test with the Matproof Sentinel replay of the forged assertion request.

Reference: CVE-2023-36661 python3-saml · CVE-2022-31197 ruby-saml · OWASP A07:2021 Identification and Authentication Failures · NIS2 Art. 21(2)(a)(i) · CWE-347 Improper Verification of Cryptographic Signature

NIS2 penetration testing options

—	Free scan	Matproof Sentinel	Traditional consultancy
Automated scan engine	✓ (3-min preview)	✓ Full scan	✗ Manual only
OWASP Top 10 coverage	Partial	✓ Complete	✓ Complete
Proof-of-exploit evidence	✗	✓ Per finding	✓ Per finding
Regulatory mapping (DORA/NIS2/ISO 27001)	✗	✓ Automated	✓ Manual
Audit-ready PDF report	✗	✓ Instant	✓ 2–4 weeks delivery
Continuous / recurring scans	✗	✓ Per deploy	✗ Annual engagement
Time to first result	~3 min	~30 min full scan	2–4 weeks
Price	€0	From €149	€8,000–€25,000
Source code review (SAST)	✗	✓ On Growth plan	✓ Scoped engagement
API testing (REST/GraphQL)	✗	✓ Automated	✓ Manual

Matproof Sentinel for NIS2 compliance

Single Run

€149 one-time

1 full pentest scan
AI-prioritized findings with CVSS 3.1
Proof-of-exploit per finding
Audit-ready PDF report
Regulatory mapping (DORA, NIS2, ISO 27001)

Unlimited scans (up to 3 domains)
Continuous monitoring
CI/CD integration (GitHub, GitLab)
All regulatory mappings
Priority support

Start Starter →

Growth

€799 / month

Unlimited scans + domains
Authenticated / White-Box testing
API & cloud infrastructure tests
Dedicated security account manager
24h SLA response time

Contact for Growth →

Frequently asked questions about NIS2 penetration testing

Which entities must comply with NIS2 Article 21 security requirements?

NIS2 applies to two categories. Essential entities include operators in energy (electricity, gas, oil, hydrogen, district heating/cooling), transport (air, rail, water, road), banking, financial market infrastructure, health (hospitals, pharmaceutical manufacture, medical devices), drinking water, wastewater, digital infrastructure (IXPs, DNS providers, TLD registries, cloud providers, data centres, CDN, Trust Service Providers, public electronic communications), ICT service management (B2B managed service providers, managed security service providers), certain public administration bodies, and space. Important entities cover postal and courier services, waste management, chemicals manufacture/distribution, food production/processing/distribution, medical device/computer/electronics/vehicle/machinery manufacturers, digital providers (online marketplaces, online search engines, social networking platforms), and research organisations. The size threshold is generally 50+ employees or €10M+ annual turnover — micro and small enterprises are excluded unless they operate in digital infrastructure or are identified as critical by member state competent authorities.

What does 'Article 21 penetration testing' mean in practice?

Article 21 does not use the word 'penetration test' explicitly. It requires entities to assess the effectiveness of their cybersecurity risk-management measures. In practice, competent authorities have accepted penetration tests as the primary technical mechanism for this assessment. The test must be: (1) conducted by parties with documented technical competency (the RTS on Art. 23 reporting and the ENISA guidelines reference OSCP/CREST-level qualifications), (2) scoped to cover critical systems per an asset inventory, (3) documented with a methodology reference (OWASP Testing Guide v4.2, PTES, or NIST SP 800-115), (4) evidenced with proof of exploitation for material findings, and (5) accompanied by a remediation plan with timelines and follow-up testing confirmation.

How often does NIS2 require a penetration test?

NIS2 does not specify a minimum testing frequency — it requires that measures be 'appropriate and proportionate' and reflect 'the state of the art'. ENISA guidance and national authority publications (BSI, ANSSI, NCSC-NL) consistently point to annual testing as the baseline for most entities. After significant changes to ICT architecture, a new test is expected. For continuous compliance and to satisfy the 'state of the art' standard, quarterly or continuous automated testing (as provided by Matproof Sentinel) increasingly meets supervisor expectations. A common practical approach: annual structured pentest by an external provider + continuous scanning (Matproof Sentinel) + ad hoc tests after major releases.

What are the NIS2 fines and can management be held personally liable?

For essential entities: up to €10 million or 2 % of global annual turnover, whichever is higher (Art. 34(4) NIS2). For important entities: up to €7 million or 1.4 % of global annual turnover, whichever is higher. These are maximum figures — actual fines depend on member state transposition and regulator discretion. The personal liability dimension (Art. 20) is new: management bodies — typically the board — can be held personally accountable if they have not approved adequate cybersecurity measures, overseen their implementation, and ensured training. Individual board members who cannot demonstrate they reviewed recent penetration test reports and saw evidence of remediation can be subject to personal fines and temporary bans from management positions. This is why penetration test reports must be Board-visible, not just kept in the security team.

Is a Matproof Sentinel scan sufficient for NIS2 Article 21 compliance?

Matproof Sentinel provides automated technical testing that directly supports NIS2 Art. 21 evidence generation. The audit-ready PDF report includes: OWASP Top 10 and API Top 10 coverage, proof-of-exploit for each finding, CVSS 3.1 severity scoring, remediation roadmap, and explicit mapping to NIS2 Art. 21 requirements. For most important entities (Annex II), Sentinel's automated testing supplemented by annual structured external testing will satisfy supervisory expectations. For essential entities (Annex I) in high-risk sectors (energy, banking, health, digital infrastructure), we recommend combining Sentinel's continuous scanning with annual or biannual structured external pentests by qualified providers — some national authorities have published sector-specific guidance requiring external human-led testing.

What is the difference between NIS2 and DORA for financial entities?

For financial entities that fall under both NIS2 and DORA, the lex specialis principle applies: DORA takes precedence as sector-specific regulation. Article 4 of the NIS2 Directive explicitly states that sector-specific EU legal acts applicable to essential or important entities (including DORA) constitute specific cybersecurity rules equivalent to NIS2. Financial entities supervised under DORA are therefore not required to separately comply with NIS2 Art. 21 — satisfying DORA Art. 24 covers the equivalent obligation. However, if a financial entity has subsidiary operations in non-financial sectors that fall under NIS2 (e.g., an insurance group operating an energy subsidiary), NIS2 applies to those non-financial subsidiaries.

What documentation is required for a NIS2 Article 21 audit?

Competent authorities conducting inspections (Art. 32-33 NIS2) typically request: (1) an asset inventory covering critical ICT systems, (2) a risk assessment methodology (ISO 27005, NIST RMF, or ENISA methodology), (3) penetration test reports from the past 12-24 months with documented scope and methodology, (4) proof-of-exploit documentation for material findings, (5) a remediation tracking register showing status of each finding (open, in progress, resolved, accepted with justification), (6) evidence that management reviewed and approved the remediation plan, (7) re-test evidence confirming that Critical and High findings were resolved. Matproof Sentinel auto-generates items 3, 4, and 5. Items 6 and 7 are supported through re-test reports.

How does NIS2 apply to supply chain security testing?

NIS2 Article 21(2)(d) requires entities to manage security in the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. In practice, this means essential and important entities must assess their critical SaaS, cloud, and infrastructure providers' security posture. Mechanisms include: contractual requirements for suppliers to undergo annual penetration tests and provide reports (with appropriate NDA/confidentiality), inclusion of pentest requirements in procurement criteria, spot-check reviews of supplier security reports, and where technically possible — supplier APIs and integration points being included in scope for the entity's own penetration test. For the most critical supply chain relationships, some entities arrange 'pooled testing' where they share a penetration test scope with their critical provider — this is explicitly envisioned by the NIS2 framework.

Go deeper — related blog articles

Start your NIS2-compliant penetration test

Get a free 3-minute surface scan to see your current exposure — no login, no credit card. The full Matproof Sentinel scan delivers an audit-ready PDF report mapped to NIS2 Article 21 requirements in under 60 minutes. From €149 one-off or €299/month for continuous compliance coverage.