NIS2 Article 21 evidence requirements — what national CSIRTs actually accept

Why evidence quality matters more than directive language

NIS2 (Directive (EU) 2022/2555) entered into force on 17 January 2025. National transposition was due 17 October 2024 — most member states delivered on time; a few are still finalising regional gaps. 16 months in, the enforcement reality is consistent across national CSIRTs:

• Article 21(2) requires "appropriate and proportionate" cybersecurity risk-management measures. The language is intentionally broad — auditors fill it in with concrete expectations.
• The expectations are not arbitrary. They're built on existing national frameworks (BSI IT-Grundschutz in Germany, ANSSI guidelines in France, NIST in Italy/Spain).
• Submissions that bluff or paper-over weak evidence are flagged. CSIRTs see hundreds of submissions per quarter; they recognise template language and weak supporting chains immediately.
• Pentest reports are the single most common evidence artefact for the technical measures (Art. 21(2)(d), (e), (f), (h), partial (i), (j)). The other measures (a, b, c, g) require policy + process evidence sourced elsewhere.

Who's in scope

NIS2 expands the NIS1 perimeter substantially. Two entity tiers:

• Essential entities — energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management (B2B), public administration, space. Large entities only (≥250 employees or ≥€50M turnover) unless otherwise designated.
• Important entities — postal/courier services, waste management, manufacture of chemicals/food/medical devices, digital providers, research organisations. Medium entities (≥50 employees or ≥€10M turnover) and large.

The DORA-vs-NIS2 distinction: financial entities are covered by DORA (lex specialis) AND NIS2 (lex generalis). DORA Article 24 testing satisfies NIS2 Article 21(2)(e) — same evidence, different submission portal.

The ten Article 21(2) measures — mapped to pentest evidence

Art. 21(2)(a) — Policies on risk analysis and information system security

Pentest coverage: indirect. The pentest informs the risk-analysis policy by surfacing exploitable conditions the policy should have caught. Findings demonstrate whether the policy is empirically effective.

What auditors expect: the entity's written risk-analysis methodology + the pentest report as evidence the methodology was applied + a gap-closure log showing how high-severity findings updated the risk-analysis baseline.

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

Pentest coverage: indirect. Each finding doubles as a hypothetical incident scenario for the entity's tabletop exercises. Pre-incident detection capability is empirically measured by what the pentest surfaces.

What auditors expect: incident-response runbook + tabletop exercise records + a demonstration that the runbook addresses categories of incident the pentest identified.

Art. 21(2)(c) — Business continuity, backup, DR, crisis management

Pentest coverage: indirect. Availability-impacting findings (DoS, ransomware precursors, exposed admin interfaces) inform BC/DR scope and tabletop coverage.

What auditors expect: BC/DR plan + last exercise record + the pentest's affected-asset list filtered for availability-impacting findings as input to the next BC/DR review cycle.

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

Pentest coverage: direct via third-party components. Findings tagged to specific Open Source dependencies, SaaS integrations, supplier APIs, and dependency CVEs attribute to the relevant supplier under Article 28 supplier-register obligations.

What auditors expect: supplier register + per-supplier security review evidence + the pentest's third-party-finding list mapped to specific suppliers with disclosure-status tracking.

Art. 21(2)(e) — Acquisition, development, maintenance security including vulnerability handling

Pentest coverage: direct. The canonical Art. 21(2)(e) evidence artefact. Every finding ships with CVSS, evidence artefact, affected asset, remediation chain, and retest result.

What auditors expect: the pentest report directly. SQUR's report is purpose-built for this section.

Art. 21(2)(f) — Effectiveness assessment of risk-management measures

Pentest coverage: direct. The pentest IS the assessment. Frequency, scope coverage, and finding-trend over time evidence the entity's effectiveness-assessment cadence.

What auditors expect: the pentest engagement history (showing cadence — quarterly, semi-annual, annual minimum) + finding-trend chart showing whether high-severity-finding count is decreasing over time.

Art. 21(2)(g) — Basic cyber hygiene practices and cybersecurity training

Pentest coverage: out of scope. Pentest data does NOT inform training evidence. The SQUR NIS2 Evidence Package flags this explicitly so the consultant doesn't bluff it.

What auditors expect: phishing simulation reports (KnowBe4, Hoxhunt, etc.) + training completion records + tabletop-exercise participation list. Pentest report should NOT be cited here.

Art. 21(2)(h) — Policies and procedures regarding cryptography and encryption

Pentest coverage: direct. Findings tagged "cryptography" or "transport-security" (weak TLS, deprecated ciphers, missing HSTS, certificate mishandling, weak password hashing) directly evidence cryptographic posture.

What auditors expect: cryptographic-controls policy + the pentest's cryptography-category findings as empirical evidence of policy effectiveness.

Art. 21(2)(i) — HR security, access control, asset management

Pentest coverage: partial. Access-control findings (default credentials, weak passwords, exposed admin interfaces, missing authorization checks) directly evidence access-control adequacy. Asset management is partially covered (in-scope discovery only). HR security is out of scope.

What auditors expect: access-control policy + pentest's access-control findings + CMDB / asset register + HR security policy + offboarding-procedure evidence (sourced elsewhere).

Art. 21(2)(j) — MFA / continuous authentication, secured voice/video/text/emergency comms

Pentest coverage: partial. Authentication endpoints discovered without enforced MFA directly evidence Art. 21(2)(j) gaps. Secured-comms scope (voice/video/text/emergency) typically out of scope unless explicitly tested.

What auditors expect: MFA enforcement policy + the pentest's authentication-findings list (especially endpoints without MFA enforced) + secured-comms evidence sourced from IT records.

The SQUR NIS2 Evidence Package — what it covers, what it doesn't

The SQUR partner-program ships a co-brandable NIS2 Article 21 Evidence Package as a deliverable. The package wraps a SQUR pentest report with a section-by-section narrative pre-mapped to Art. 21(2)(a–j). Coverage summary:

Consultant workflow saving: 8–12 hours per client engagement. Source: ambassador-program strategy notes 2026-03-30, validated against typical EU SME NIS2 submission scope.

National CSIRT expectations (national variation)

• BaFin (Germany financial) + BSI (Germany general): read Art. 21(2) through MaRisk + IT-Grundschutz. Closed evidence chain (identification → assessment → plan → fix → retest) is the most common failure point.
• AMF (France) + ANSSI (France general): guidance documents emphasize supplier-register attribution under Article 28(3). Third-party findings must attribute to specific suppliers.
• AFM (Netherlands): focus shift toward cloud-provider concentration risk. Multi-cloud architectures with single-region failover face scrutiny.
• Bank of Italy + CSIRT Italia: still in the "scoping" phase for many sub-sectors; expect tighter enforcement late 2026.
• CSSF (Luxembourg): revised TLPT scoping memo for fund-management entities; entity classification is in flux.

The directive-text floor is universal across member states; the enforcement texture varies. Submissions should map to the relevant national CSIRT's published guidance where available.