Firewall Rule Review Checklist

Firewall rulesets only ever grow: rules are added for projects, migrations and urgent fixes, and almost nobody removes them, so after a few years nobody can say which rules are still needed or who asked for them. This template gives you a repeatable rule review procedure and worksheet: what to export, what to check on every rule, how to check the ruleset as a whole, how to review the management plane and administrator accounts, and how to track findings to closure and sign off. It is built on NIST SP 800-41 Rev. 1, PCI DSS v4.0.1 requirement 1.2.7 and CIS Controls v8.1, so the completed worksheet doubles as audit evidence. It is written for network and security engineers who run reviews and the compliance staff who need the evidence.

How to use this template

• Replace text in square brackets, such as [Organisation], [Network security team] and [X days], with your own terms and values.
• "Must" is mandatory; "should" is recommended, with exceptions handled under section 9.
• Run one review per firewall, cluster or policy package. Copy the worksheet tables in sections 6, 7 and 8 into your tracker and add a result column (Pass, Fail, N/A) per rule or check.
• A rule passes only when the evidence column is filled in: a ticket number, a named owner, a hit count. "Believed to be needed" is not evidence.
• Read it alongside the Firewall Management Guide, which covers architecture, platform choice and day-to-day operations.

1. Purpose

This procedure ensures that every rule on [Organisation]'s firewalls and other network security controls (NSCs) is still required, is as specific as possible, has an accountable owner and is logged, and that the devices themselves can only be administered by named, strongly authenticated people. It implements the periodic ruleset review recommended by NIST SP 800-41 Rev. 1, which advises that "It is important to review the firewall policy often", and the PCI DSS v4.0.1 requirement 1.2.7 that "Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective."

2. Scope

This procedure applies to:

• Perimeter, internal segmentation and data centre firewalls, including virtual and next-generation firewalls, owned or operated by [Organisation] or by [managed service provider] on its behalf.
• Cloud network controls: [AWS security groups and network ACLs / Azure network security groups and Azure Firewall / Google Cloud firewall policies].
• Remote access and VPN policies, firewall management systems, configuration backups, and the accounts, API keys and service accounts that can change rules.

Host firewalls on servers and end-user devices (CIS safeguards 4.4 and 4.5) are covered by [Endpoint Hardening Standard] and [Server Build Standard].

3. Roles and responsibilities

• [Head of Network Security]: owns this procedure, approves the review schedule and signs off each review.
• [Network security team]: exports rulesets, runs the analysis, chairs owner reviews and implements approved changes through change management.
• Rule owners: the business or application owner named on each rule; must confirm or retire their rules within [10 working days] of a request.
• [Security operations] and [IAM team]: confirm logging and change alerts, and supply the list of administrator accounts and machine credentials with firewall access.
• [Internal audit or second line]: independently samples completed reviews. NIST SP 800-41 recommends that periodic ruleset audits are done by people outside the normal review team.

4. Review cadence and triggers

5. Preparing the review: rule inventory export

1. Export the running ruleset from the device, not from documentation, and record the export time and firmware version. Confirm it matches the stored backup: PCI DSS 1.2.8 requires NSC configuration files to be "Kept consistent with active network configurations."
2. Export hit counts and last-hit timestamps for every rule. Check whether counters on your platform survive reboots, failovers and upgrades; if they were reset, extend the observation window or use firewall logs in [SIEM] instead.
3. Export objects, groups, NAT rules and VPN policies (a rule that looks specific can reference a group containing "any"), pull the change tickets since the last review, and load everything into the worksheet below, one row per rule.

6. Checks for every rule

Treat a rule that fails FR-1 or FR-2 after the owner deadline as a removal candidate. Disable it first, with logging on, for [14 days] before deleting it, so a missed dependency can be restored from the disabled rule rather than rebuilt.

7. Ruleset-level checks

Policy analysers find RS-2 and RS-3 candidates quickly (NIST notes some firewalls can look for "redundant rules"), but a person must decide which overlapping rule survives.

8. Management plane and administrator access

A perfectly reviewed ruleset is worthless if an attacker can log in to the firewall and change it. ATT&CK tracks this as T1686 Disable or Modify System Firewall (sub-technique T1686.002 Network Device Firewall), and the Salt Typhoon telecom intrusions show how stolen credentials and network device secrets let an intruder stay inside network infrastructure for years. Review these items each quarter.

MP-3 to MP-8 are identity controls and fail the usual ways: a former engineer's local account still active, an orchestration API key with full write access and no owner. See the Privileged Access Management Guide, the Break-Glass Account Guide and the API Key Management Guide.

9. Change management and exceptions

1. Every rule change must follow [change management procedure]. PCI DSS 1.2.2 requires changes to network connections and NSC configurations to be "approved and managed" through the change control process in requirement 6.5.1.
2. Rule requests must state source, destination, service, business justification, owner and, for temporary access, an expiry date of no more than [90 days].
3. The approved ticket number must be written into the rule comment at implementation.
4. Exceptions to this procedure, including any/any or broad rules that cannot be narrowed yet, must be risk assessed by [Security team], approved by [approver], given compensating controls (such as extra logging or IPS inspection) and an expiry date of no more than [12 months], and recorded in [risk register].
5. Removals and corrections from a review go through the same change process, never as direct edits during the review.

10. Findings and remediation tracking

Record every failed check as a finding. Use these severities unless your risk framework defines its own.

Tracking worksheet (copy one row per finding):

A finding closes only when the next export shows the change, not when the ticket is closed.

11. Review summary and sign-off

Keep the export, the completed worksheet, the tracking table and the sign-off together in [evidence repository] for [retention period]; this pack is what an assessor asks for under PCI DSS 1.2.7.

12. Source references

1. NIST: SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
2. PCI Security Standards Council: PCI DSS (v4.0.1 Requirements and Testing Procedures, requirements 1.2.2, 1.2.5 to 1.2.8, 1.3.1 and 1.3.2)
3. CIS: Controls Assessment Specification, Control 4 Secure Configuration of Enterprise Assets and Software
4. CIS: Controls Assessment Specification, Control 12 Network Infrastructure Management
5. CIS: Controls Assessment Specification, Control 13 Network Monitoring and Defense
6. NSA and CISA: AA23-278A, Top Ten Cybersecurity Misconfigurations
7. MITRE ATT&CK: T1686 Disable or Modify System Firewall

Implementation guidance

1. Start with the riskiest device: run the first review on the internet edge or CDE firewall, where any/any rules, exposed management and expired vendor rules do the most harm.
2. Fix ownership before cleanup: send each owner their rules with a deadline; unclaimed rules become removal candidates.
3. Disable before delete: disable unused or unowned rules with logging on for [14 days], watch for denies matching the old rule, then delete. Rollback is re-enabling the rule, or restoring the pre-change configuration backup.
4. Close the front door: fix management plane failures (MP-1, MP-4, MP-5, MP-6) before the rule cleanup finishes; they are faster and higher impact.
5. Make it continuous: enforce ticket, owner and expiry fields at rule creation and compare exports automatically between reviews (CIS 12.3 cites version-controlled infrastructure as code).

Small organisations can run the procedure in a spreadsheet twice a year, focusing on FR-7, FR-9, MP-1 and MP-5. Large estates need a policy analyser, owner data in the CMDB and review packages split by business unit. Common failure patterns are reviews that only look at new rules, owners who approve every rule by default, hit counts read without checking for a counter reset, and remote access rules and accounts left behind after a project; the Colonial Pipeline attack began with an unused VPN account. Track these measures each cycle:

• Coverage: percentage of in-scope devices reviewed on schedule (target [100]%).
• Ownership: percentage of permit rules with a current owner and ticket.
• Ruleset hygiene: count of any/any, zero-hit and expired temporary rules, trended per review.
• Remediation: findings closed within the severity deadline.
• Admin hygiene: administrator accounts without MFA or without a named person (target zero).

For ports and protocols to restrict, see the Network Ports and Protocols Security Guide; for firewall log retention, the Log Management and Retention Guide; for machine credentials on network tools, the Service Account Security Guide.

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Firewall Management Guide · Network Segmentation Guide · PCI DSS 4.0 Guide · Privileged Access Management Guide