Firewall Rule Review Checklist Template

Phase 1: Scope & Export

Assigned to the network security engineer who owns the devices under review.

• List the network security controls in scope — perimeter and internal firewalls, cloud security groups, router ACLs and host firewall policies
• Export the running policy from each device — and confirm it matches the saved backup, so you are reviewing what is actually enforced
• Pull hit counts for the review window — note when counters were last reset, because a reboot or failover can zero them
• List every rule change since the last review — matched to its change ticket, requester and approver
• Record whether the device filters traffic to or from the cardholder data environment — answering yes adds the PCI DSS checks in Phase 2

Phase 2: Permissive & Risky Rules

The last task appears only for devices that filter cardholder data traffic.

• Flag every any-any or overly broad rule — each needs a named reason or a plan to narrow it
• Check allowed ports and protocols against the approved list — insecure services such as Telnet or unencrypted FTP need documented justification and compensating controls
• Confirm a default deny closes every policy — traffic not explicitly allowed should be dropped and logged
• Review management access to the firewall itself — admin interfaces reachable only from a management network, over encrypted protocols, with MFA
• Confirm cardholder data environment restrictions — inbound and outbound traffic limited to what is necessary, and wireless networks denied by default

Phase 3: Rule Hygiene

• Identify shadowed rules — rules that can never match because an earlier rule already catches their traffic
• Identify redundant rules and duplicate objects — the same host defined three times under three names
• List rules with zero hits — but check for seasonal, year-end or disaster recovery traffic before assuming a rule is dead
• Check every temporary rule against its end date — expired rules go straight onto the removal list
• Remove unused address and service objects — they clutter the policy and hide real problems

Phase 4: Owner Recertification

• Send each rule group to its business owner — with the original ticket, the justification and recent hit counts
• Record the owner’s decision for each rule — keep, tighten or remove
• Escalate rules nobody will own — an unowned rule is treated as a removal candidate by default
• Update rule comments — owner, ticket reference and date of this review, so the next reviewer starts with context

Phase 5: Change Requests

Switches on when any rule is marked tighten or remove in Phase 4. The change approval is an approval step for the change manager or CAB.

• Raise a change request for each rule to change — grouped by device and risk so the CAB reviews them together
• Obtain change approval — through the same change process as any other production change
• Disable before deleting — leave a removed rule disabled and logged for an agreed period so a hidden dependency shows up safely
• Attach the post-change policy export — and close each ticket once no impact has been reported

Phase 6: Logging, Backup & Sign-Off

Sign-off is an approval step for the network security lead or CISO.

• Confirm logging on deny rules and sensitive allow rules — and that logs reach the central log platform with accurate timestamps
• Confirm alerts fire on policy changes — an unapproved edit should not wait six months to be noticed
• Back up the reviewed configuration — stored where only authorised administrators can reach it
• Write up the review record — participants, devices, configuration date, findings and ticket numbers
• Approve the review and set the next date — six months out, or sooner after a major network change