Firewall policies often outlive the projects that created them. A temporary supplier connection remains after maintenance ends. An application moves to a new destination while its old rule stays in place. A broad troubleshooting exception becomes familiar enough that nobody remembers its original purpose.
FortiGate policy cleanup addresses that accumulated uncertainty. The goal is to remove or narrow access that is no longer justified while preserving the work the organisation still needs. A shorter rule list is useful only when the resulting policy is understood and verified.
The safest starting point is ownership and evidence. A rule name, a quiet counter or an engineer’s recollection can suggest a candidate for review, but none independently proves that removal is appropriate. This guide describes a controlled process that connects technical observations to business decisions.
Define what the cleanup is intended to improve
Agree the scope before inspecting individual rules. The review might focus on expired project access, rules without owners, duplicated application paths or permissions that are wider than the documented requirement. A clear objective keeps the exercise from expanding into unrelated network redesign.
Identify the devices and policy areas included. If central management is involved, confirm how changes will be reconciled and installed through the approved management process. Avoid editing a local device in a way that leaves the organisation uncertain about the authoritative configuration.
Set a realistic pace. A large estate may need several review cycles, particularly where applications have infrequent business events. The value comes from resolving the purpose and disposition of each candidate, not from reaching an arbitrary deletion target.
Describe success in operational terms. The team should be able to explain why retained rules exist, demonstrate that removed access is no longer required and show that critical workflows still operate. Those outcomes are more meaningful than a percentage reduction in the policy count.
Create a policy ownership register
For each candidate, record the intended business service, responsible owner, relevant source and destination groups, and any known expiry or review date. Link the entry to the available request or change record without copying sensitive configuration details into an uncontrolled document.
Use an owner who can make a business decision. A network administrator may understand how a rule works but may not know whether an annual reporting process still depends on it. The application or service owner should confirm the requirement, with technical staff helping interpret the traffic.
Where ownership is unknown, follow a defined investigation route. Consult application inventories, project records and the teams associated with the relevant systems. Assign a decision date so the lack of an owner does not become a permanent reason to retain unexplained access.
Improve naming and comments where appropriate, but do not mistake better labels for a completed review. A clearly named rule can still grant obsolete or excessive access. The register should capture the decision and supporting evidence as well as the description.
Use activity data as evidence, not a verdict
Fortinet documents filtering on policy list statistics introduced in FortiOS 7.4.8, including metrics such as bytes, packets, hit count and last use. Where supported in your installed release and environment, these views can help identify candidates and focus investigation.
The interpretation still requires context. A rule with little observed activity might support a seasonal workflow, an emergency process or a service that has been temporarily paused. A busy rule might be essential, unnecessarily broad or carrying traffic that should be reviewed separately.
Establish the observation period and logging limitations. Know when the available evidence begins and whether the relevant traffic is represented. Avoid assuming that a counter provides a complete historical record without checking the behaviour of the deployed platform and configuration.
Compare technical observations with the business calendar. Payroll, stocktaking, year-end reporting and scheduled partner exchanges can occur outside a convenient review window. Ask owners to identify these events before classifying a rule as unused.
Trace dependencies beyond the visible rule
A policy may reference objects used elsewhere. Before changing or deleting an address, service or group, identify its other references through the supported tools for the environment. Removing one rule does not automatically make every associated object obsolete.
Review related routing, translation and application dependencies where relevant. The visible permission may be one part of a larger path. A cleanup that changes several related components at once can make a failure difficult to diagnose and recover.
Check whether another rule would handle the traffic after a candidate changes. The resulting behaviour may differ from the engineer’s first expectation. The technical review should evaluate the effective policy outcome rather than treating each rule as an isolated line in a spreadsheet.
For shared objects or centrally managed policies, consider the full target estate. A change that appears local can affect another branch or service. Maxicon’s IT services provide a route for discussing policy ownership and controlled review across the relevant environment.
Classify candidates into clear decisions
Use a small set of dispositions: retain with an owner, narrow to a documented requirement, investigate further or remove through a controlled change. This makes the review actionable without pretending every candidate can be resolved immediately.
For retained rules, record why the scope is justified and when the decision should be revisited. Retention is a legitimate outcome when the business requirement is current and the access is appropriate. The cleanup process should not pressure owners into unsafe removal merely to produce visible progress.
For narrowing, obtain a complete application requirement. Guessing a smaller destination or service set can create intermittent faults that appear only during a less common transaction. Have the application owner and technical reviewer agree what must remain functional.
For removal, identify the evidence supporting the decision and the conditions under which the change will be tested. Keep the previous state available through the organisation’s approved recovery process. A rule that seems obviously obsolete still deserves a traceable change record.
Consider a hypothetical supplier-access review
Imagine a manufacturing business that provided a supplier with access for an equipment commissioning project. The project has finished, but the associated firewall rule remains. The rule’s name includes the supplier’s company, while the original engineer is no longer available.
The review team asks the equipment owner whether any recurring maintenance still uses that path. It checks the contract and available service records, then examines relevant activity over an appropriate period. The supplier’s original project completion does not by itself prove that all subsequent support needs have ended.
If recurring access remains necessary, the owner can define a narrower, time-bounded maintenance process. If it is no longer required, the team can schedule removal and verify the affected equipment’s ordinary operation. Any separate remote-support method should be included in the ownership discussion.
This example illustrates the central principle: technical evidence and business confirmation answer different questions. The engineer establishes what the configuration permits and what activity is observed; the owner establishes whether that access remains justified.
Stage changes so failures are explainable
Group changes by a clear purpose and manageable scope. Removing unrelated rules, altering shared objects and redesigning application access in one maintenance event can make a problem hard to attribute. A narrower batch allows the team to connect an observed effect to a specific decision.
Where the supported process and risk assessment allow, a reversible intermediate step may help validate a candidate before final removal. The implementation team should choose the method and monitoring plan for the actual environment. Do not assume that disabling a rule is harmless or that it proves future non-use.
Set a verification period based on the workflow being tested. A daily interactive application and a monthly automated exchange require different evidence. If the relevant event cannot occur during the planned window, record the limitation and decide whether to defer the change or use another approved validation method.
Define recovery triggers before implementation. Loss of a critical transaction, an unexpected access result or an unexplained effect on another service should have a named decision maker. Keep communication routes ready so users can report relevant symptoms promptly.
Test both business continuity and access reduction
Ask representative users or application owners to perform the agreed tasks after the change. Record the source location, application action and result. A generic internet test does not establish that an internal business process remains functional.
Also verify the intended restriction. If the purpose was to remove obsolete supplier access, demonstrate that the relevant path no longer permits it under the tested conditions. Otherwise, another rule or route may continue to provide the same access despite the apparent cleanup.
Examine relevant logs and policy behaviour using the supported tools. Use these observations to explain results, not to replace the business test. A successful transaction and the expected policy evidence together provide a stronger acceptance record.
If a problem appears, follow the recovery plan and preserve the diagnostic context. Restoring service should not erase the lesson about an undocumented dependency. Update the ownership record before attempting the change again.
Remove the causes of future clutter
Require new exceptions to include a business owner and review date. Temporary work should state when access is expected to end and who confirms completion. This makes later cleanup a planned lifecycle event rather than a search through forgotten configurations.
Connect application retirement and supplier offboarding to firewall review. When a system moves or a contract ends, the network team should receive enough information to assess associated access. Those business events are often better triggers than waiting for a broad annual cleanup.
Keep change records concise but useful. The next reviewer needs to know the purpose, scope and acceptance evidence, not a long conversation history. Clear documentation reduces the temptation to preserve a rule simply because nobody wants to risk investigating it.
Review unresolved candidates periodically and escalate those that lack a decision owner. To discuss a controlled policy cleanup, contact Maxicon with the device scope, management arrangement and the kinds of unexplained rules your team encounters. The result should be a policy set whose business purpose is easier to defend and maintain.
Frequently asked questions
Can a rule with zero observed hits be deleted?
Not on that observation alone. Confirm the evidence period, platform behaviour and business calendar, then obtain the relevant owner’s decision. Infrequent or contingency workflows may not appear during a short review window.
Is disabling a rule always a safe test?
No. Disabling can immediately affect traffic or cause it to match a different policy. Use a technically reviewed, authorised change with defined tests and recovery. The appropriate intermediate step depends on the actual configuration and service risk.
Should unused objects be deleted at the same time?
Only after checking their references and purpose. An object associated with a removed rule may still be used elsewhere. Separate object cleanup where that makes the impact easier to review and verify.
Who decides whether a policy is still necessary?
The business or application owner confirms the requirement, while technical staff evaluate how the policy implements it and what changes would do. Both perspectives are needed when the evidence is incomplete or the workflow is infrequent.
What is the best measure of successful cleanup?
A documented, justified policy set with obsolete access removed and required workflows verified. Rule-count reduction alone is insufficient. Track resolved ownership, completed decisions, tested restrictions and outstanding exceptions to understand the practical result.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
