The FortiManager Global Database exists for policies and objects that must be governed above an individual ADOM. Ordinary ADOMs let organizations separate customers, business units, or administrative scopes. The Global Database adds a higher management layer where selected policy packages and objects can be defined once and assigned across multiple ADOMs without erasing the local policy each ADOM still owns.
For the NSE 6 FortiManager 7.6 Administrator, the key is understanding what belongs in the global layer, how global packages are assigned, how header and footer policies surround local policies, and how version compatibility affects assignment and installation.
The Global Database is a separate policy and object layer
Fortinet documents the Global Database as containing object configurations, global policy packages, and header/footer IPS sensor configuration. Administrators switch into the Global Database ADOM to create those components, then assign them to local ADOMs or policy packages as appropriate.
This is not the same as copying a normal policy package into every ADOM. Global policy is centrally owned and can be applied across multiple local management domains. That makes it suitable for controls that should remain consistent even when local teams manage different application or customer policies.
Examples include organization-wide deny rules, mandatory management access restrictions, shared security objects, or provider controls that customers should not be able to remove. The global layer is most valuable when the requirement is genuinely universal.
Header and footer policies surround local ADOM policy
The global ADOM layer can define header and footer policies. Conceptually, header rules appear before the local policy block and footer rules after it. Fortinet uses this model to describe carrier and service-provider scenarios where the provider needs mandatory controls around customer-managed policies.
This ordering is a governance tool. A mandatory deny in the header can take effect before local rules, while a footer can enforce behavior after the local policy block. Administrators need to understand the resulting combined rulebase when troubleshooting because a packet may be denied by a global policy that is not edited in the local ADOM.
Do not use global header rules casually. An overly broad global control can affect many ADOMs at once. The very feature that gives the Global Database leverage also increases its blast radius.
Assignment connects global packages to local ADOMs
A global policy package does nothing to a local ADOM merely by existing. It must be assigned to the target ADOM or policy packages. Fortinet documents that each local policy package can have one global policy package assigned, while an ADOM can use multiple global packages across different local packages.
Assignment should follow ownership and applicability. Not every global rule belongs in every tenant. A regulated-business-unit baseline may differ from a guest-access or lab environment. Create enough global packages to express real governance boundaries rather than building one enormous universal package full of exceptions.
Before assignment at scale, preview the combined policy and test in a representative ADOM. Global mistakes are amplified by centralization, so staged rollout and change review are more important than with a single local rule.
Global objects reduce duplication but need naming discipline
The Global Database can hold object configurations that are used by global policy. Central objects reduce repeated definitions and help mandatory rules remain consistent. However, local ADOMs may also contain objects with similar names or purposes, so naming standards should make ownership obvious.
Do not move every shared-looking object into the global layer. A global object should support global policy or a true cross-ADOM governance need. Objects that are locally owned and likely to vary should remain local. Otherwise the global database becomes a dependency for ordinary tenant changes and erodes the autonomy ADOMs were meant to provide.
Firewall-policy fundamentals still apply: global and local packages express access-control intent, while FortiManager adds hierarchy and governance rather than changing what a firewall rule means.
Version compatibility affects where global policy can be assigned
The Global Database has an associated FortiOS syntax version. Fortinet documents that this version influences which local ADOM versions can be selected for assignment and how policy syntax is translated when installed to devices. Local ADOM version then determines the device versions it can manage.
Upgrade sequencing therefore matters. A global database should not be upgraded in isolation without considering every ADOM that consumes its global packages. If a local ADOM cannot support the resulting global policy syntax or assignment relationship, organization-wide governance can be disrupted.
Before a platform upgrade, inventory global-to-local assignments and the FortiOS versions behind them. Test policy compilation and installation in a non-production or pilot ADOM before moving the entire hierarchy.
Global policy is not retrieved from managed devices
Fortinet notes an important operational behavior: when a managed FortiGate configuration is re-imported, global policies and objects installed on the device are not simply re-imported into the Global Database. The global layer remains centrally owned rather than reconstructed from downstream device state.
This reinforces the source-of-truth model. Global governance should be backed up, reviewed, and changed in FortiManager. Do not assume you can recover it later by pulling configuration from a FortiGate that happens to contain the resulting installed rules.
The same principle applies when a global package is unassigned. Removing the assignment in FortiManager changes intended state, but an installation is required to remove the corresponding global policy from the target device. Database state and running device state must both be considered.
Delegate local control without weakening central controls
The strongest use of the Global Database is to separate responsibilities. A central security team can own mandatory rules and shared controls while local ADOM administrators own the business policies specific to their devices. This supports multi-tenant and large-enterprise operations without granting every administrator authority over every control.
Administrative permissions should reflect that model. Access to the Global Database should be more restricted than ordinary local policy editing because mistakes can propagate widely. Peer review and workspace locking are especially useful when global changes have a large blast radius.
Fortinet certification objectives treat governance as both a technical capability and an operational process. Global policy is safe only when ownership, review, testing, and rollback are as disciplined as the centralized rules themselves.
A practical global-policy design workflow
Start by identifying controls that are truly universal or centrally mandated. Separate them from local application policy. Create the required global objects and policy package, define header/footer placement intentionally, and assign the package to a small test ADOM with a compatible version.
Review the combined rulebase and installation preview. Verify that local administrators can still manage their intended policy block and that global rules cannot be bypassed through ordinary local changes. Then expand assignment gradually while monitoring install results.
Document every assignment and the owner of the global package. During upgrades or reorganizations, review those dependencies before changing ADOM versions. A well-designed Global Database makes security governance predictable across many domains; a poorly designed one creates an invisible layer of rules that local teams cannot explain. Transparency is the difference.
Global policy changes need a smaller blast-radius process than ordinary edits
Because a global package can affect many ADOMs, change control should be stricter than for a single local policy. Require a clear statement of intent, affected assignments, expected rule position, rollback method, and a representative test plan. Reviewers should understand both the global rule and the local policy blocks it will surround.
Use staged assignment when introducing new controls. Apply the global package to a non-production or low-risk ADOM first, then to a small production subset, and only then to the wider estate. Verify installs and traffic logs at each stage. This catches object conflicts, version issues, and unintended rule matches before they become organization-wide incidents.
Keep global packages narrow. If central security needs to enforce five mandatory controls, a concise package containing those controls is easier to audit than a large package that gradually absorbs ordinary local policy. Global policy should express central governance, not become a second general-purpose rulebase.
Plan ownership for shared objects too. When a global object changes, every global policy using it may be affected. Names should communicate scope, and destructive changes should be reviewed for all references. A global address object that silently changes from one subnet to another can alter many policies without any local administrator editing their package.
Finally, give local teams visibility into the global layer even when they cannot edit it. Troubleshooting is much faster when an ADOM administrator can see that a header rule denied traffic and knows which central team owns that rule. Governance should restrict modification, not create mystery.
Audit reports should make global-policy ownership visible. For every global package, record which ADOMs consume it, which local packages are affected, and when the assignment last changed. This relationship map becomes essential during mergers, tenant moves, or ADOM consolidation because removing an ADOM can have policy consequences beyond its local objects.
Global objects should also be reviewed for lifecycle. An address, service, or security profile created for a temporary organization-wide requirement can remain referenced long after the project ends. Periodic cleanup prevents the global layer from accumulating stale controls that local teams are afraid to remove because their purpose is unclear.
When a global rule intentionally differs by environment, use separate global packages or well-defined assignment boundaries instead of burying many exceptions inside one policy. Clear package scope is easier to review, safer to install, and less likely to create a rulebase whose behavior depends on subtle object differences across ADOMs.
Emergency changes require special handling in the global layer. If an urgent block must be deployed organization-wide, use the same review, staged validation, and rollback discipline as any other global change even when the timeline is compressed. After the incident, reconcile temporary objects and rules quickly so an emergency control does not become an undocumented permanent dependency across many ADOMs.