FortiManager Change Control Across Multiple Branches

A policy change that is straightforward at one office can become difficult when it must reach several branches. The sites may share a business application but use different addressing, internet connections or local services. A central management platform helps organise configuration work, but the organisation still needs to decide what should change, who may approve it and how success will be demonstrated.

FortiManager change control is most useful when it separates those decisions from the mechanics of installation. An approved request is not the same as a successful deployment. A successful deployment is not the same as a working business transaction. Each stage needs its own evidence and responsible person.

This guide describes a practical process for teams managing multiple FortiGate locations. Product behaviour and available workflow features depend on the installed FortiManager and FortiOS releases, the management design and supported compatibility. Validate those details before translating this operating model into configuration.

Start with a branch-aware change request

The request should describe a business outcome that a reviewer can understand. “Update firewall rules” offers little basis for approval. “Allow the warehouse team at the Lahore branch to reach the approved inventory service using the documented application flow” establishes purpose, location and a testable result.

Include the affected sites explicitly. If the same policy package serves several branches, the requester should still identify where the business requirement applies. A shared configuration structure must not quietly expand the scope of approval to offices that were never considered.

Record application ownership and the source of technical requirements. Destination details supplied by an application owner should be distinguished from assumptions made during troubleshooting. Where the requirement is incomplete, resolve that uncertainty before the change becomes a broad access exception.

The request should also state timing constraints. A retail branch may have different quiet hours from a warehouse, and a finance team may have periods when even a brief interruption is unacceptable. Use those differences to plan deployment groups instead of imposing a single convenient engineering window.

Distinguish the approval responsibilities

Business approval establishes that the requested access or behaviour is necessary. Technical review checks whether the proposed configuration implements that requirement with an appropriate scope. Deployment authority decides when the reviewed change may be installed. These responsibilities can be held by a small number of people, but they should remain identifiable.

For a small IT team, separation does not require an elaborate committee. A second person can review the intended effect and the target list before the engineer installs it. Where staffing makes independent review difficult, document the limitation and use a more deliberate checklist and business validation process.

Fortinet’s FortiManager 7.6.6 documentation describes a workflow workspace mode. Its existence should not be confused with a complete organisational approval process. Confirm how your chosen release handles sessions, permissions and approvals, then decide how those platform controls connect to your change record.

Keep emergency authority distinct from routine authority. An urgent service restoration may follow an accelerated route, but it still needs an identified decision maker, a record of what changed and a subsequent review. Otherwise, emergency access becomes a permanent way around the normal process.

Know what central management will affect

Before editing, identify the relevant policy package, devices and shared objects. Ask whether another branch or application uses the objects being changed. A seemingly local edit to a shared address or service definition can have consequences beyond the rule visible on the engineer’s screen.

Maintain a branch exception register. Each exception should explain why a site differs, who owns that difference and when it will be reconsidered. Without this record, engineers may mistake an intentional local requirement for configuration drift, or preserve an obsolete difference because nobody understands it.

Reconcile the intended central configuration with the device state using the supported process for the installed releases. Investigate unexplained differences before a planned installation. Do not let a routine application request become the occasion for unintentionally overwriting unrelated local work.

This is also a useful point to assess the wider design. Maxicon’s network infrastructure services can be used to discuss branch requirements, management responsibilities and the practical boundaries of a shared configuration approach.

Review the installation output as a separate gate

Fortinet documents installation preview functionality in FortiManager, including a preview step for installing objects in version 7.4.8. Use the applicable preview and validation tools for your deployment method and release to inspect what is actually proposed for the selected targets.

A reviewer should compare the proposed installation with the approved request. Look for unexpected deletions, additional objects, changes outside the named application and differences between target branches. If the output is broader than expected, stop and explain the discrepancy before proceeding.

Do not treat the absence of an obvious error as proof that the business requirement is satisfied. Configuration review can show what will be sent; it cannot independently confirm that the application owner’s destination list is complete or that a branch user can finish the required workflow.

Retain the reviewed evidence with the change record in an appropriate controlled location. If the configuration changes after approval, reassess whether the review remains valid. Approval should relate to a concrete proposal, not to a general intention that can expand during implementation.

Build deployment groups around useful differences

Select a pilot site that represents relevant conditions and can support testing. The easiest branch is not always the most informative. If the change affects a warehouse application, a head-office pilot with no warehouse clients may provide little evidence about the real outcome.

List the characteristics that justify each group: access method, addressing pattern, application usage, device platform or operating hours. The purpose is to reveal meaningful differences before deployment reaches the entire estate. Avoid creating groups solely because the branch names happen to be adjacent in a list.

Define a pause between groups that allows the agreed checks to occur. The right interval depends on the workflow. An interactive transaction may be tested promptly, while a scheduled exchange may need a specific business event. A waiting period has value only when someone knows what evidence to collect during it.

Make expansion conditional. If the pilot reveals an unexplained failure, do not continue simply because the maintenance window is running out. Record the issue, assess the recovery decision and revise the plan. A controlled pause can prevent a local misunderstanding from becoming an estate-wide interruption.

Verify installation and business behaviour separately

After each group, inspect the installation result and investigate warnings or failures. A partially completed deployment deserves explicit attention: branches may now operate under different configurations. Record which devices changed successfully and which require further action.

Next, perform the business checks. Ask a representative user or application owner to complete the relevant task from the intended location. Where appropriate, verify both permitted access and access that should remain restricted. A change that makes the application work by widening unrelated access has not met the full requirement.

Use fresh evidence rather than relying solely on an existing session. Depending on the application and network behaviour, an already established connection may not exercise the changed path in the same way as a new transaction. Agree the test method with the technical team and describe its limits.

Observe related services that might be affected by shared objects or routing dependencies. The test list should be proportionate, but it should include the plausible consequences identified during review. Link each check to a reason so verification does not become a generic collection of screenshots.

Prepare recovery before the first branch changes

The recovery plan should identify the previous approved state and a supported way to return to it. Do not assume that reversing one visible edit will undo every dependency or automatically restore every active session. The implementation team must validate the recovery method for the actual configuration and releases.

Set decision thresholds before deployment. Examples include failure of a critical transaction, loss of management connectivity or an unexplained change outside scope. Identify who can authorise recovery and who will communicate with branch staff while the technical work proceeds.

Allow enough maintenance time for the recovery route. A plan that uses the entire window for installation leaves the team choosing between an untested state and an unapproved extension. Include time for reconnecting, retesting and documenting the result.

If recovery occurs, preserve evidence of the unsuccessful attempt. The purpose is to understand the cause before another deployment, not merely to restore a familiar screen. Record whether the previous business behaviour returned and which questions remain unanswered.

Close the change with an accurate estate view

Closure should show the final state of every intended target. Mark branches that were completed, deferred, recovered or excluded, with reasons. A single “done” status can conceal a mixed estate and confuse the next engineer who assumes the change reached all locations.

Update the policy ownership and exception records where necessary. Temporary access needs an expiry or review date. A new shared object needs a clear purpose. A branch-specific adjustment needs an explanation that will survive staff changes.

Review recurring deployment problems as process findings. Frequent unexpected differences may point to unclear local administration rules. Repeated approval delays may indicate that the wrong business owner is being consulted. Improving those conditions can make future changes both safer and faster.

For a discussion of branch change control, contact Maxicon with the number of sites, current management arrangement and examples of changes that are difficult to coordinate. Those details make the conversation more useful than starting with a request for a generic central management installation.

Frequently asked questions

Does FortiManager approval guarantee a change is safe?

No. A platform approval step records a decision within the configured workflow. The organisation still needs a complete requirement, technical review, correct target selection and business testing. Verify the exact capabilities and permissions of the installed release.

Should every branch receive a change at once?

Only when the risk assessment and verification plan justify that approach. Staged deployment is useful when branches differ or when a pilot can expose an incomplete assumption. Group sites by relevant conditions and make expansion dependent on agreed evidence.

What should an installation preview reviewer look for?

Compare the proposed output with the approved scope, including affected devices, shared objects, unexpected removals and unrelated changes. Resolve discrepancies before installation. A preview supports configuration review but does not replace application testing.

How should urgent local changes be handled?

Use a defined emergency route with named authority, a recoverable record and prompt reconciliation with central management. Document what the local change addressed and whether it should remain. Avoid leaving an emergency adjustment outside the managed configuration indefinitely.

What evidence is needed to close a multi-branch change?

Record the installation outcome for each target, the agreed business test results, any exceptions and the final recovery status. Include ownership and review dates for temporary arrangements so the next change begins from an accurate understanding of the estate.

Related technology support

For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.