The Rule That Outlived Its Project: A Quarterly Review of Inbound Access

At many small and mid-sized UK organisations, the firewall is not designed in a single act. It accumulates. A port is opened for a migration, a NAT entry is added for a supplier, a remote-access exception is granted while someone works from home. The project ends. The rule remains. Over time the rule set becomes a record of past urgency rather than a statement of current business need.

Port 3389 is a useful example because Remote Desktop Protocol is common and frequently exposed by accident. But the principle applies to any inbound rule: a database port for a reporting tool, a web port for a legacy application, a management interface for a managed service provider. The question is not whether the rule was justified when created. It is whether a named person can justify it now.

A quarterly review makes that question routine. It should be short enough to complete, evidence-based, and documented so the next review does not begin with a blank page.

Start with the rule set as it actually is

Begin by exporting the current configuration from the firewall, the NAT table and the remote-access platform. Include VPN user groups, published applications and any vendor support tunnels. Do not rely on the diagram in the document store; it will be incomplete. The exported configuration is the source of truth.

Build a simple register with one row per inbound rule or exception. At minimum record the rule identifier, source, destination, service or port, purpose, business owner, date approved, review or expiry date, evidence of current use and the decision from the review. A spreadsheet is sufficient. The value lies in the fields being completed, not in the tool.

Where possible, add usage evidence. Firewall logs may show hit counts, but a hit count is not the same as business need. A rule can be busy because it is being probed from the internet. A rule can show no hits because the service is seasonal. Pair log data with the owner's account of the process it supports.

Give every rule a named owner

The most common weakness in a firewall review is the owner field. It is easy to write IT, or network, or support. Those are functions, not accountable people. A rule should have a named role or individual who can explain what business process would stop if the rule were removed.

For supplier rules, the owner is usually the internal contract manager, not the supplier. For application rules, it is the product or service owner. For remote-access exceptions, it is the line manager who approved the working arrangement. The IT team can maintain the register and run the tests, but it should not be asked to invent business justification for rules it inherited.

If no owner can be found, that is a finding. It does not automatically mean the rule should be deleted the same afternoon, but it does mean the rule should be treated as unowned and reviewed with priority.

Test the need, not just the port

A review that only asks whether a port should be open will miss the more important question: whether the access method is still appropriate. Direct exposure of RDP to the internet is difficult to justify for a UK SME when VPN or a zero-trust remote-access service is available. If direct access is retained, it should be restricted by source address, protected by multi-factor authentication and monitored.

Testing should be staged. For a rule suspected to be obsolete, first identify the dependent users and applications. Then agree a change window and a rollback path. Disable the rule rather than deleting it immediately, monitor for a defined period, and confirm with the owner that no business process has failed. Only then remove it. This is slower than deleting on sight, but it produces evidence and avoids an outage that discredits the review.

NAT entries deserve the same treatment. A port-forwarding rule may be hiding a service that was moved, replaced or decommissioned. Map each NAT entry to the internal host and the business service. If the host no longer exists, the entry should go. If the service has moved to a cloud platform, the entry should go unless there is a documented transitional need.

Record the decision in a form the next review can use

The output of the review is not a cleaner firewall alone. It is a decision record. Each rule should end with one of four outcomes: keep with an expiry date, modify to reduce exposure, remove, or replace with a different access method. Record the date, the owner, the evidence and the change reference.

Expiry dates are particularly useful. A temporary rule should carry a temporary approval. When the expiry date arrives, the rule is reviewed automatically rather than waiting for someone to remember it. This single habit prevents the slow accumulation that makes quarterly reviews necessary in the first place.

Naming conventions also help. A rule labelled project phoenix temporary says nothing to the next administrator. A rule labelled with the service, owner group and ticket reference is easier to assess. The same applies to NAT entries and remote-access profiles.

Make the next quarter easier

A quarterly review should take less time each time it is run. That happens when the register becomes part of change control. New firewall rules should not be approved without an owner, a purpose and a review date. Temporary exceptions should be created with an expiry date from the start. Supplier access should be tied to the contract review cycle.

The review itself should be scheduled, not triggered only by an incident. A fixed quarterly slot, with a defined scope and a named coordinator, is more likely to happen than an annual exercise that tries to cover everything at once. The aim is not a perfect firewall. It is a firewall that can be explained.

Inbound access is a maintained asset. Like any asset, it needs an owner, a purpose and a periodic check. The question to ask is not who opened the port, but who still needs it and what evidence supports that need. If the answer is clear, the rule can stay. If it is not, the review has done its job.