Compliance

NIS2 Firewall Evidence: Mapping Article 21's 10 Risk-Management Measures to Firewall Documentation

Fw
Nicholas Falshaw
||10 min read

NIS2 took full effect across EU member states in October 2024. The first wave of audits is now reaching essential and important entities on 18-month cycles. Article 21 lists ten risk-management measures. Six of those ten measures require firewall documentation as evidence. This guide maps each relevant measure to the specific artifact an auditor will ask for, with the gap pattern I have seen recur across 280-plus enterprise firewall migrations.

The most common audit failure mode is not absence of firewalls. It is absence of firewall evidence. The operator runs a competent firewall estate but cannot produce the documentation in the form the auditor wants. Most audits fail on documentation; almost none fail on technical control absence.

Article 21 — The 10 Risk-Management Measures

Article 21(2) of NIS2 lists ten categories of risk-management measures. The six that touch firewall evidence directly:

  • 21(2)(a) Risk analysis and information system security policies — firewall policy must derive from documented risk analysis.
  • 21(2)(b) Incident handling — firewall logs are primary evidence in incident reconstruction.
  • 21(2)(d) Supply chain security — vendor firewall management, third-party access policies.
  • 21(2)(e) Security in network and information systems acquisition, development, and maintenance — change-management process.
  • 21(2)(g) Basic cyber hygiene practices and cybersecurity training — rule-base hygiene, recurring review.
  • 21(2)(i) Use of cryptography and, where appropriate, encryption — firewall TLS-inspection policy, key management.

The 4 Documentation Gaps Auditors Check First

From observed audit patterns, four gaps account for the majority of Article 21 findings. They are predictable and addressable.

  1. Change approval lineage. Per change request: who requested, who reviewed technically, who approved, when implemented, who validated. Email chains do not satisfy this. The system of record must be the workflow tool.
  2. Access policy mapping. A documented mapping of which user roles or service accounts require which firewall access, with effective dates and renewal cadence. Many operators have role definitions and have firewall rules, but no mapping connecting them.
  3. Segmentation evidence. Network zone diagram, current rule base showing inter-zone permitted flows, last test of segmentation effectiveness (often a pen-test report). NIS2 expects this to be reviewed annually minimum.
  4. Incident log retention. Documented retention duration, integrity controls (immutable storage or signed records), search capability. NIS2 does not specify a duration; sector frameworks suggest 12 months minimum, 24 months for KRITIS.

Evidence Checklist Per Measure

A practitioner's mapping of each relevant Article 21 measure to the specific evidence the auditor will request:

MeasureEvidence required
21(2)(a)Risk analysis document; firewall policy linked to identified risks; review cadence
21(2)(b)IR runbook with firewall actions; log retention policy; sample incident report with firewall log excerpts
21(2)(d)Vendor list with security review; third-party access rules with expiry; supplier security questionnaire results
21(2)(e)Change-management procedure; change register sample; emergency-change procedure; rollback evidence
21(2)(g)Rule-base review report (quarterly minimum); training records for firewall operators; hygiene metrics
21(2)(i)TLS-inspection policy with exceptions; key management procedure; cryptographic standard reference

Essential vs. Important Entity Differences

NIS2 distinguishes essential entities (Annex I sectors) from important entities (Annex II sectors). Both face Article 21 obligations, but the supervisory regime differs significantly.

  • Essential entities: ex-ante supervision — the competent authority can audit on demand without prior incident. Penalties up to EUR 10 million or 2 percent of global turnover. Audit cadence in practice: 12-18 months for new operators, 24 months thereafter.
  • Important entities: ex-post supervision — audits triggered by incident or evidence of non-compliance. Penalties up to EUR 7 million or 1.4 percent of global turnover. Documentation expectations are similar; audit frequency is lower in steady state.

For firewall evidence, the practical difference is preparedness cadence. Essential entities cannot defer. Important entities can in steady state, but pay heavier costs once an incident triggers an audit because the documentation is not pre-positioned.

The Common Gap Pattern from 280-Plus Migrations

Across 280-plus enterprise firewall migrations I have analyzed, a consistent gap pattern recurs. The pattern predicts which Article 21 sub-measure is most likely to fail in audit.

First, change-management discipline degrades with operational tempo. Operators who maintain disciplined change records during normal operations skip them during incidents and emergency changes. The audit pulls the emergency-change records first, because that is where the gap is.

Second, segmentation evidence ages faster than the network does. Diagrams from 18 months ago are obsolete after two zone restructures. The artifact exists but is no longer accurate. Auditors recognize stale diagrams immediately.

Third, retention policy and retention reality diverge. The policy document says 12 months. The actual SIEM rotation is 90 days because the storage budget was cut. Both documents exist; they contradict. Auditors check the actual storage configuration against the stated policy.

Fourth, third-party-access rules accumulate and never retire. Vendor access rules from completed projects remain active. Article 21(2)(d) supply-chain expectations are violated by the absence of a retirement process, not by the absence of rules.

The Pre-Audit Pack

For an essential entity facing first-cycle audit, six artifacts in a single shared folder cover most of Article 21. The folder is the artifact — not the individual documents.

  1. Risk analysis document (current version + revision history)
  2. Firewall change register export (last 12 months)
  3. Network segmentation diagram (current + last review date)
  4. Rule-base review report (most recent quarterly run)
  5. Incident-response runbook (with firewall actions section)
  6. Logging configuration evidence (retention proof, integrity controls)

These artifacts also cover most of CISA CPGs, NIST 800-53, ISO 27001 Annex A.13, and the German KRITIS BSIG §8a obligation with formatting adjustments. Operators who build the pack to NIS2 standard generally pass adjacent audits with the same evidence.

About the Author

Nicholas Falshaw is a Principal Security Architect with 17+ years of enterprise firewall and network security experience across DAX-30 clients, KRITIS-regulated operators, and EU financial services. He authored the FwChange methodology after analyzing 280+ firewall migrations.

Author and Methodology Behind FwChange

FwChange is built and authored by Nicholas Falshaw, drawing on 17+ years of enterprise firewall experience and 280+ migrations. Read the methodology behind the platform.

Stay Updated

Get firewall management tips, compliance guides, and product updates.

No spam. Unsubscribe anytime.

Fw

Nicholas Falshaw

Principal Security Architect & AI Systems Engineer. 17+ years of enterprise firewall and network security across DAX-30 and KRITIS-regulated operators. Author of FwChange and the 280-migrations dataset.

Ready to Automate Firewall Changes?

See how FwChange streamlines multi-vendor firewall management with compliance automation and AI-powered rule analysis.