Choice Guide Lab

Whether you’re heading into a PCI-DSS QSA assessment, an ISO 27001 surveillance audit, or an internal security review, your FortiGate firewall policy table is always in scope. Auditors look for overly permissive rules, missing logging, and stale objects that create unaccountable network paths. A structured pre-audit checklist is the difference between a clean pass and a flurry of findings.

This guide walks through ten concrete checks every network engineer should perform before a compliance review. Each check includes the exact CLI command or GUI path so you can work through the list systematically.

Why FortiGate Policy Audits Are Complex

FortiGate deployments grow organically. A policy added for a project three years ago may never have been reviewed since. Unlike code, firewall rules don’t throw errors when they become obsolete — they simply sit there, consuming processing resources and widening the attack surface. Over time, the policy table becomes a mix of active rules, dead rules, and rules whose original intent is unknown.

Compliance frameworks require you to demonstrate that every allow rule has a documented business justification and that access is restricted to the minimum necessary. That is impossible if you can’t explain what half your rules do.

The 10-Point Pre-Compliance Checklist

Work through each item below. The checklist is interactive — check items off as you complete them.

Using Automation to Speed Up the Process

Running these checks manually across hundreds of policies is time-consuming and error-prone. The APO Tool was built specifically to automate the most labour-intensive parts: identifying zero-hit policies, flagging unnamed rules, and detecting any/any configurations across your entire policy table in seconds.

For the CLI-based checks, the following one-liner exports a filtered policy summary useful for offline review:

show full-configuration firewall policy | grep -E "(edit|set name|set srcaddr|set dstaddr|set service|set logtraffic|set status)" > policy_summary.txt

Documenting Results

Auditors expect evidence, not just assertions. For each check, save the output of the relevant command with a timestamp. Store it in version control alongside your configuration backup. This creates an auditable history that demonstrates ongoing compliance rather than a point-in-time snapshot.

What Auditors Actually Look For

In practice, most audit findings on FortiGate deployments fall into four categories:

• Overly permissive source or destination — any/any rules or rules scoped to entire subnets when specific hosts would suffice.
• Missing UTM inspection — allow rules that bypass AV, IPS, or application control on internet-facing traffic.
• No log evidence — rules with set logtraffic disable that produce no forensic trail.
• Stale configuration — address objects pointing to decommissioned systems, or rules for services that were retired months ago.

The checklist above targets all four categories. Run it at least 30 days before an audit to give yourself time to remediate findings and generate fresh traffic logs that prove the changes are working.

Scheduling Regular Policy Reviews

Compliance is a continuous process, not a pre-audit sprint. Configure a calendar reminder to repeat this checklist quarterly. Pair it with the APO Tool for automated hit-count analysis, and you’ll spend less than an hour per quarter keeping your policy table audit-ready.

For a deeper look at one of the most common issues this checklist surfaces, see our previous post: FortiGate Hit Count Zero Policies: How to Find and Clean Them Up.