Change governance
Every rule change starts as a structured request: source, destination, port, action, intent, not a free-text ticket or a console edit nobody recorded.
NIS2 Readiness Check
NIS2 does not ask whether your firewall is configured well. It asks whether you can show who approved each change, why, and that the rule still belongs there. This is a self-check for the change governance behind the rulebase, score yourself against it before someone else does.
What this assesses
A clean rulebase is not the same as a defensible one. NIS2 Article 21 is about governance, the process around the change, not the syntax of the rule. This check looks at the four areas where firewall programs usually fall down.
Every rule change starts as a structured request: source, destination, port, action, intent, not a free-text ticket or a console edit nobody recorded.
For any rule, you can produce who/what/when/why on demand, not reconstruct it from memory or syslog the week before the audit.
An enforced, multi-level approval chain that fits the environment, with separation of duties between the person who asks and the person who signs off.
Temporary access expires on schedule, and every rule is reviewed on a cadence, so the rulebase reflects what is still needed, not what was needed three years ago.
Who this is for
NIS2 widened the net well beyond the old critical-infrastructure list. If you run network security inside one of these and a regulator can ask for your change records, this check is for you.
The same evidence answers ISO 27001, PCI-DSS, DORA and KRITIS too, the work is shared.
The self-check
Read each item and mark it yes only if you could demonstrate it today, not "we mean to," not "it's mostly there." This is static: nothing is sent anywhere, nothing is stored. Count your yeses and read the score guide below.
Every firewall change starts from a request that captures source, destination, port, action and business justification, before anything touches the device.
No change reaches production without a recorded approval, and the approver is not the person who raised the request.
Each proposed change is checked for shadowed rules, redundancy and over-permissive any/any access before it ships, not after an incident.
For any rule on any device, you can produce who changed it, when, and why, from one trail, not five disconnected systems.
Changes go in during agreed maintenance windows, and the record shows the change happened when it was meant to.
Temporary rules carry an expiry date and are removed when it passes, temporary access does not quietly become permanent.
Every rule is reviewed on a defined cadence and re-justified or retired, the rulebase is curated, not just appended to.
The same governance applies across every firewall vendor in the estate, not only the one platform that happens to have good tooling.
Rule reviews understand the subnets and assets behind the addresses, drawing on IPAM or NetBox rather than guessing at IP ranges.
When an auditor asks, the evidence pack is an export, not a fortnight of screenshots, ticket archaeology and log correlation.
Score guide. 8–10 yes: your change governance is audit-ready, keep the cadence honest. 4–7 yes: the controls exist but they are manual or partial; an auditor will find the gaps the same way you just did. 0–3 yes: the rulebase is being changed faster than it is being governed. That is the exact gap NIS2 closes, and the methodology page is where to start.
Why the gap is always evidence
Across enterprise migrations the rulebase is rarely the problem, the problem is that nobody can say, two years later, why a rule exists or who agreed to it. Rulebases grow as networks evolve and people move on. Without governance, that drift is invisible until an auditor asks for it in writing.
Make the trail a by-product of the workflow and the audit stops being a project. That is the whole argument behind FwChange.
The readiness check shows the gap. The methodology shows how to close it, the same thinking that turns 280+ migrations into evidence an auditor accepts without argument.