How often should a business review its firewall rules?

Firewall rules should be reviewed on a risk-based schedule rather than treated as a one-off configuration task. The review interval should reflect the access a rule permits, the sensitivity of the systems involved, how often the related service changes and whether the rule is actively used. High-risk rules need closer scrutiny than low-risk rules, while the whole rule base should remain subject to a documented governance cycle.

A useful approach is to divide rules into review groups:

• High-risk rules: Rules allowing inbound connections from the internet, broad outbound access, administrative access, remote access or connectivity to sensitive systems should be examined more frequently. The reviewer should confirm the source, destination, service, business owner and justification for each rule.
• Standard business rules: Rules supporting ordinary application traffic, site-to-site connections or established operational services can follow the organisation’s normal firewall review cycle, provided their owners and purposes are recorded.
• Legacy or rarely used rules: These deserve particular attention because they are often retained after a project, supplier arrangement or temporary requirement has ended. Usage data can help determine whether they can be removed, narrowed or replaced.

The review should assess more than whether the firewall is passing traffic. For every significant rule, check:

• Whether the rule still has a current business owner.
• Whether the source and destination are as specific as possible, rather than relying on broad address ranges or unrestricted objects.
• Whether all permitted ports and protocols are still required.
• Whether the rule is positioned correctly in the rule set and can be reached before a more restrictive rule.
• Whether temporary expiry dates, comments and approval records are present.
• Whether logging is enabled at an appropriate level without creating unnecessary noise or exposing sensitive information.
• Whether associated network address translation, VPN, security profiles or application controls remain consistent with the intended access.

Rule usage data is valuable, but it should not be treated as the sole basis for deletion. A rule may appear unused during the period examined because the related process is occasional, seasonal or dependent on a particular supplier. The owner should confirm the business need before removal. Conversely, a rule that is frequently used can still be dangerously broad; high usage does not demonstrate that its permissions are appropriate.

Each review should produce an auditable record. At a minimum, retain the date, reviewer, rules examined, evidence considered, decisions made and any actions still outstanding. Where a rule is retained despite being broader than preferred, document the reason and any compensating controls. Where a rule is removed or amended, record the approval and test results so that a later incident investigation does not depend on memory.

Responsibility should also be clear. A network or security administrator may technically inspect the configuration, but the relevant application, system or department owner should confirm that access is still needed. Separating technical implementation from business approval reduces the risk of rules being kept simply because nobody is willing to accept responsibility for changing them.

Organisations should also distinguish between a planned rule-base review and a targeted control check. A full review considers the structure and purpose of the configuration. A targeted check might examine privileged access, remote connections, exposed services, failed authentication patterns or rules associated with a particular system. These focused checks can identify risk between formal reviews without replacing them.

Warning signs that the review process is not working include rules with no named owner, duplicated objects, comments such as “temporary” with no expiry, unrestricted source addresses, a long sequence of disabled rules and repeated exceptions with no recorded justification. A growing rule base is not automatically a problem, but unexplained complexity makes errors harder to identify and increases the chance that a permissive rule will conceal an unintended path.

The outcome should be a controlled action list: remove rules that are no longer justified, narrow sources or destinations where possible, separate combined business purposes, add expiry dates to temporary access and escalate unresolved ownership questions. The schedule should then be adjusted if the review reveals that the environment, rule complexity or level of exposure is greater than previously understood.