Firewall rule bases grow and never shrink, because adding a rule solves a problem today and removing one might cause an outage tomorrow. This log makes removal safe by requiring evidence of use before a rule is retired.
Require a justification and an owner per rule. A rule whose purpose nobody can state is a rule nobody can safely remove. Backfill justifications during the review; rules you genuinely cannot explain are your highest-value cleanup candidates.
Use hit counts before deciding anything. Export hit counts over at least ninety days, long enough to cover quarterly processes. A rule with zero hits in that window is a strong retirement candidate; a rule with hits you cannot explain deserves investigation.
Disable before deleting. Disable the rule, leave it for two weeks, and watch for complaints. Deleting outright turns a reversible change into an archaeology exercise.
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
One row per rule. 'Any' in source, destination, or service is worth flagging on sight.
| Rule ID | Source | Destination | Service / port | Action | Business justification | Owner | Hits (90d) | Finding | Decision |
|---|---|---|---|---|---|---|---|---|---|
| 12 | any | 10.20.0.0/24 | tcp/3389 | allow | Unknown (predates current team) | - | 0 | Over-permissive + unused | Disable, review 14d |
| 27 | 10.10.20.0/22 | 10.20.0.10 | tcp/5432 | allow | App servers to finance DB | A. Mehta | 2.1M | Scope could narrow to app subnet | Tighten source |
More free templates IT teams use alongside this one.
Network documentation fails because it is written once, as a project deliverable, and then diverges from reality within a quarter. This template is scoped to the things that change slowly and are expensive to rediscover at 02:00.
A scanner gives you findings. What auditors, boards, and your own future self need is the thing scanners do not produce: who owns each finding, when it is due, and what happened to the ones you decided not to fix. This tracker is built around the remediation clock rather than the scan.
Change control earns its reputation for bureaucracy when every change gets the same paperwork. This form routes by risk: standard changes are pre-approved and need almost nothing, while the genuinely risky ones get the scrutiny that would otherwise be spread thinly across everything.
Every six months for most organisations, annually for small and stable rule bases. Several compliance frameworks require a documented review at least annually, and PCI DSS specifies every six months for in-scope environments.
Confirm zero hits over a window long enough to cover quarterly processes, disable rather than delete, observe for about two weeks, then delete through your change process. Record the observation window so the removal is defensible later.
A rule that can never be evaluated because an earlier rule in the list already matches the same traffic. Shadowed rules add noise and often conceal the fact that the effective policy differs from the one people believe is in place.
