15 firewall checks to run before the auditors arrive

An audit asks three questions

This firewall audit checklist starts from what an auditor actually asks: what the rule base permits, whether that matches what you intended, and who changed it since the last review. PCI DSS v4.0 wants that review at least every six months (requirement 1.2.7). SOX and HIPAA audits don’t set a firewall-specific schedule, but their change-control and access reviews end up asking the same three questions.

Traffic logs show what did pass. They can’t tell you what could, or who changed the rule that let it through. The configuration can: the rules, the objects, NAT and the change history. The 15 checks below are vendor-neutral and work whether you run Palo Alto, FortiGate, Cisco, Juniper, or all of them at once.

Start with the paperwork

“Whether it matches what you intended” only works if the intent is written down. Before you open a single rule base, find the firewall standard: which zones may talk to which, what may be published to the internet, who approves exceptions and for how long, and how often rules get reviewed. If it doesn’t exist, write a one-page version first. Without it, every finding turns into an argument about what the rule was supposed to do.

Auditors will also ask for a few documents no configuration can show: the change procedure itself, the runbook for a firewall incident (who gets paged, who can make an emergency change, how the business is told), and training records for the people with admin rights. Gather them in the same week. The 15 checks below cover everything the configuration can answer.

Clean up the rule base (checks 1–5)

1. Inventory every enforcement point. Firewalls, management planes (Panorama, FMC), and the ACL-bearing routers and switches between them. An audit scoped to “the firewalls we remembered” is not an audit.
2. Find shadowed rules. A shadowed rule never matches, because an earlier rule already catches its traffic. The dangerous kind is a shadowed deny: the block you think you have never fires.
3. Find redundant rules. A redundant rule does what another rule already does. Removing it changes nothing about what the firewall permits, and every one you keep makes the next review slower.

4. Flag overly broad rules. Any-any sources, /8 destinations, service “any”. Rank them by exposure so the widest-open rules get handled first, not found on page forty of the report. Read the outbound rules too: an any-to-internet rule from the server VLAN is how data leaves without anyone noticing.
5. Resolve every object. A rule that reads “web-group to db-group” tells an auditor nothing. Expand nested address and service groups to real IPs, protocols and ports before you judge a single rule, because that’s what the firewall enforces.

Work out what can reach what (checks 6–9)

6. Compute effective access for critical segments. Look end to end, not rule by rule. What can actually reach the database VLAN, the management network or the OT segment once every rule, object and NAT translation is applied? That’s the question a policy analyzer exists to answer.
7. Reconcile inbound NAT with intended exposure. Every destination NAT and VIP is a promise to the internet. List them, resolve each to its real internal target, and check it against what you meant to publish.

8. Review VPN and remote-access scope. IPSec tunnels, GlobalProtect and SSL-VPN populations, and the policies that decide what remote users reach once they’re inside.
9. Check who can administer the firewall. Start with reach: which networks can get to the management interfaces, and over what. Then the accounts. Compare every admin account against the HR list, remove people who have left or changed roles, and replace shared logins with named ones behind MFA. Finish with the software: is the OS version still getting vendor fixes for known advisories? The rule base is only as safe as the path to its admin login.

Account for every change (checks 10–12)

10. Attribute every change in the audit window. Each policy change since the last review should map to a named admin and a ticket that was approved before the change, not after. Then spot-check a few: does the change on the device match what the ticket asked for? Unattributed changes are findings by definition.
11. Diff the configuration against the last audited baseline. A side-by-side diff of then and now is the fastest honest answer to “what changed this year?” If you can’t produce one, every audit starts from zero.
12. Catch the changes the audit log missed. Some changes arrive with no audit-log entry at all, and others only name a shared service account: an automation run, a bulk import, a configuration restore. Snapshot-based change detection compares the device’s actual state with the last snapshot, so the change shows up even when the log doesn’t say who made it.

Keep it auditable next time (checks 13–15)

13. End every rule base in a deny that logs. The built-in defaults usually don’t log, and on PAN-OS the intrazone default even allows. Add an explicit deny with logging on, then look at what sits just above it. Confirm your allow rules log too: a rule that permits traffic without logging it leaves you nothing to show. What NIST SC-7(5) asks for goes deeper on the deny itself.

14. Check naming, ownership and leftovers. Rules and objects should say what they’re for and who owns them. While you’re there, clear out address objects no rule uses and rules that were disabled “for now” a year ago. Convention drift is how a rule base becomes unauditable in the first place.
15. Export the evidence. Auditors want artifacts: the rule inventory, the hygiene findings, the change timeline. Producing them should be an export, not a week of screenshots.

An audit finding is just a question you could have answered a quarter earlier.

Running these checks every quarter

You can do every check above by hand, once. Teams rarely repeat it every quarter, because resolving nested objects by hand across four vendors takes days. That’s the part SAMURAI’s Policy Analyzer automates: it computes effective access with objects and NAT resolved, flags shadowed, redundant and overly broad rules, and ranks every rule by exposure, across Palo Alto, Cisco FTD, FortiGate, Juniper SRX and ACI. Change attribution and snapshot diffs cover checks 10–12, and every table exports straight into the evidence file. The firewall audit tool page lists what it reads from each vendor.

Three checks stay with a person: who can administer the firewall (9), the explicit deny and its logging (13), and naming and leftovers (14), along with the paperwork. Check 10 is half done, since changes are tied to an admin but not matched to your tickets. SAMURAI also works from configuration state, so it can’t do usage-based cleanup (“zero hits in 90 days” needs traffic hit counts), and it doesn’t run rule recertification or approval workflows, which the policy-management suites own. It deploys as one docker run, self-hosted.