Firewall Rule Review Checklist: How Often to Review and How to Clean Up

The short version: Review every firewall rule at least once a year, review internet-facing and remote-access rules every quarter, and review every rule that changes at the time it changes. Check each rule for an owner, a reason, a narrow source, destination and service, logging, and recent use. Do not delete in one step: disable first, watch, then delete, and keep a configuration backup you can restore.

This guide is for IT managers and engineers who look after a firewall they did not build, or built years ago. After reading it you will have a review schedule, a rule-by-rule checklist, a cleanup procedure with a rollback, and a one-page record you can reuse.

How often should firewall rules be reviewed?

NIST SP 800-41 Revision 1 (September 2009), "Guidelines on Firewalls and Firewall Policy", says firewall rulesets become more complicated with age, and that the policy should be reviewed at regular intervals so that reviews do not happen only during audits or emergencies. It also recommends reviewing everything changed since the last review, who made the changes and why, and occasionally having people outside the normal review team audit the ruleset. It does not set a number of days (checked 28 October 2026).

So the schedule below is our recommended starting point, not a figure from NIST. Adjust it to your risk and change rate.

• At every change: a second person reviews the new rule before it goes live. The rule gets a comment, an owner and a ticket reference.
• Monthly (light): look at rules added in the last month, expiring temporary rules, and any rule that suddenly has heavy hits or denies in the logs.
• Quarterly: review all rules that allow traffic from the internet, from partners, and from VPN or remote-access groups.
• Yearly: review the whole ruleset and test it. Ask someone outside the normal team to review it if you can.
• After an event: review again after a security incident, a merger or office move, a major application change, or a firewall replacement.

Before you start

1. Back up the configuration in every format your firewall offers. NIST recommends regular backups, and keeping each format if the device offers a binary one and a human-readable one.
2. Export the rules with hit counters or a log query for a period that covers at least one full business cycle (month-end or quarter-end jobs count).
3. Get the current network diagram and address list. If you do not have them, see the network documentation template.
4. Find the rule owners. A rule without a known owner is the first one to question.
5. Check the firmware version and patch status. The network firmware upgrade checklist covers the upgrade itself.
6. Open a change record for the review and the cleanup, with a maintenance window and a named approver.

The rule-by-rule checklist

For each rule, answer these questions. Any "no" or "unknown" is a finding.

1. Does it have a named owner and a business reason written in its comment?
2. Is there a ticket or change reference showing who approved it and when?
3. Is the source as narrow as it can be (a named address, group or subnet), not "any"?
4. Is the destination as narrow as it can be, not "any"?
5. Is the service a named port or protocol list, not "any"?
6. Is the direction correct, and is it clear whether the rule is for inbound, outbound or internal traffic?
7. Is logging turned on for allow rules that reach sensitive systems, and for deny rules at the edge?
8. Did it match traffic in the review period? (A hit counter or log query shows this. Counters often reset after a reboot, failover or policy reinstall, so confirm how long yours has been running before treating zero hits as unused. This is general practice, not from NIST.)
9. If it is temporary, does it have an expiry date, and is that date in the future?
10. Is it shadowed or duplicated by a rule above it, so that it can never match?
11. Is order sensible? Many firewalls check rules top to bottom until one matches, so a broad rule high in the list can hide everything below it (some products evaluate deny rules first, so check yours).
12. Does it expose a management interface (the firewall, a switch, a server console, remote desktop or SSH) to the internet?
13. Does it allow unencrypted protocols (such as telnet or FTP) where an encrypted one is available?
14. Is the final rule a deny, so that traffic not expressly permitted is blocked? NIST calls this "deny by default" and says it is more secure than allowing everything that is not explicitly forbidden.

Also review the settings around the rules: who can log in to the firewall and change rules, whether administrator accounts are individual, whether the management interface is limited to a trusted network, and whether time is synchronised so logs line up across systems. NIST recommends restricting who and from where can change the ruleset.

A one-page record keeps the review auditable:

Firewall: ______  Model/firmware: ______  Review date: ______
Reviewer: ______  Second reviewer: ______  Change ref: ______
Config backup saved to: ______  Rules reviewed: ___ of ___
For each rule: ID | owner | reason | source | dest | service
 | logging Y/N | hits in period | temp? expiry | finding
Decision per rule: KEEP / TIGHTEN / DISABLE / DELETE
Disabled on: ______  Planned delete date: ______
Exceptions accepted (rule, risk, approver, review date): ______
Next review date: ______

What to do with each finding

Choose one outcome per rule.

• Keep: it has an owner, a reason, narrow scope and recent hits. Record the review date.
• Tighten: it works but is broader than needed. Replace "any" with the real addresses or services, test, then remove the broad version.
• Disable, then delete: no owner, no hits over a full business cycle, expired, or shadowed. Disable first, do not delete yet.
• Delete now: only for an exact duplicate, or a rule already disabled and watched for the hold period.
• Escalate: the rule exposes a management interface, uses an unencrypted protocol, or allows "any to any". Handle it as a risk with an owner and a date, not as housekeeping.

Cleanup steps

1. Save a fresh configuration backup and note where it is.
2. Agree the list of changes and the maintenance window with the rule owners and the business.
3. Tighten broad rules first, one at a time, testing the affected application after each.
4. Disable the unused and expired rules. Add a comment with the date and the ticket number.
5. Watch the logs for the hold period you chose. Pick a period long enough to include your longest regular job; as a starting point, at least one full month-end, usually 30 to 35 days. Check for new denies and for user reports.
6. Delete the disabled rules once the hold period ends without a complaint. Record the deletion.
7. Update the network diagram, the rule comments and the review record.
8. Schedule the next review and put the date in someone's calendar.

Your rollback is the configuration backup from step 1, plus the fact that disabled rules can be switched back on in seconds. Keep both until the hold period ends.

Common mistakes

• Deleting rules that have zero hits after a short window. Month-end, quarterly and annual jobs will fail later. Fix: use a full business cycle and disable before deleting.
• Reviewing only the rules and not who can change them. Fix: include administrator accounts, access sources and change logging in every review.
• No comments. Nobody can tell why a rule exists, so nobody dares remove it. NIST says commenting rules "takes little effort" and helps people auditing later. Fix: make owner, reason and ticket mandatory at creation.
• Temporary rules that become permanent. Fix: every temporary rule has an expiry date, and the monthly check looks for expired ones.
• Ignoring outbound rules. Fix: review what leaves the network as well as what comes in.
• Reviewing during a crisis only. Fix: put the dates on a calendar and treat them like patch windows.

How to check it worked

1. Compare the rule count before and after, and list every rule changed.
2. Test the critical flows from a list prepared in advance: web, email, VPN, key business applications, and backups.
3. Check the logs for the next week for new denies on legitimate traffic.
4. Confirm the final rule is a deny and that no rule allows any source to any destination on any service.
5. Confirm that the configuration backup restores to a test device or at least opens in a text viewer.
6. Confirm the review record is stored, the next review date is set, and each disabled rule has a delete date.

FAQ

Can you give me an example of a firewall rule?

A rule normally matches on source, destination, protocol and port, then applies an action. For example: allow TCP port 443 from the guest Wi-Fi network to the internet, and deny the guest network to every internal network.

What are the four main types of firewall rules?

There is no single standard list of four. A practical grouping is by direction and action: inbound allow rules, outbound allow rules, deny or drop rules, and address translation or port-forward rules. NIST SP 800-41 organises policy by IP address and protocol, application, user identity and network activity instead.

What are the best practices for firewall rules?

Deny by default, keep rules as specific as possible, comment every rule, manage changes through a formal process with a log, back up the ruleset, restrict who can change it, and review it at regular intervals. All of these appear in NIST SP 800-41 Revision 1.

How does a firewall rule work?

The firewall compares each connection with the rules. Many firewalls check rules in order and apply the first one that matches, which is why rule order matters. Traffic that matches no rule is handled by the default action, which should be deny.

Is there a firewall rule review template?

Yes. The one-page record in this guide covers the fields most reviews need. Add columns your auditors or customers ask for.

To have your firewalls reviewed on a schedule by engineers who do this every week, see our managed IT security services.