Firewall Security Audit: Checklist, Method and Report Template

A firewall security audit checks the whole firewall estate, not only the rules. It asks which firewalls exist, who can administer them, whether they run supported firmware, whether the configuration meets a hardening standard, and whether logging, change control, backups, VPN and segmentation work as designed. The checklist below covers eleven areas. The output is a report: executive summary, scope, method, risk-rated findings with owner and due date, evidence appendix.

This guide is for whoever owns the audit: the lead who scopes it, chases the evidence and signs the report. Two other guides go deeper on parts of it. The firewall rule audit guide is the method for one area, the rule base. The ISO 27001 firewall audit checklist maps controls to Annex A for a certification audit. This page is the full engagement, from inventory to signed report, whichever standard you report against.

What does a firewall security audit cover?

A firewall security audit covers eleven areas, and each one needs its own evidence. The table lists what to test, what to collect and where audits most often find the gap. Use it as the work plan: one row per area, one owner per row, and a status column you add yourself.

How do you scope a firewall security audit?

Scoping a firewall security audit starts with the inventory, and the inventory is often the first finding. Reconcile three lists: the CMDB, the monitoring system and the devices that routing shows actually forward traffic. Anything that appears on one list and not the others needs an answer before fieldwork starts. Include virtual systems and contexts, firewalls in public cloud accounts and the second unit of every HA pair, because peers drift apart.

Write down what is out of scope and why, and put that in the report. An audit that quietly skipped the OT firewalls reads like a clean OT estate a year later. Decide early whether you test every device or a sample. Rule bases and change records can be sampled. Management access and firmware get checked on every device, because one exposed admin interface is enough.

Collect the configuration exports once, at a fixed point in time, and record the date, the device and a SHA-256 hash for each file. Every finding in the report will point back at one of those files.

What do auditors check on management access and admin accounts?

Management access is where firewall security audits find the most serious problems, because whoever reaches the admin interface controls the policy. In its IT-Grundschutz module NET.3.2 Firewall, the German BSI requires that all administration and management access is restricted to specific source addresses and cannot be reached from untrusted networks (requirement A6). It recommends a separate out-of-band management network (A18). Both make good test criteria outside Germany too.

Test it from the network. From an ordinary user subnet, try to open the HTTPS and SSH management ports on every firewall in scope. The config tells you what someone intended; the connection attempt tells you what is true. Then export the local and remote admin accounts and check five things:

• Named accounts only. With a shared admin login, the change log cannot tell you who made a change.
• MFA on all interactive admin access, usually through RADIUS, TACACS+ or SAML to the identity provider. NIS2 Article 21(2)(j) names multi-factor or continuous authentication among the minimum measures.
• Roles that match the job. Auditors and the SOC get read-only roles. NIST SP 800-41 Rev. 1 recommends accounts with read access only for auditing and log inspection.
• Service and API accounts. Automation tokens with superuser rights and no expiry are the account type audits most often miss.
• The local emergency account. BSI NET.3.2.A7 requires that local administration stays possible when the whole network is down, so this account should exist. The finding is a password unchanged since installation, or one the whole team knows.

Firmware and support status

For each firewall, record the hardware model, the software version and the vendor's end-of-sale and end-of-support dates, taken from the vendor's own lifecycle page. NIST SP 800-41 Rev. 1 states that firewall software "should be patched as vendors provide updates to address vulnerabilities". The audit checks two things: whether the version is a supported release, and how far it lags behind the latest maintenance release of that train.

A device past end of sale is not a finding. A device past end of support with no funded replacement plan is, and we rate it High, because no new security fixes will come for it. If the estate holds several of those, the real decision is a migration project, which the end-of-support decision guide walks through for one common platform.

Configuration baseline: what counts as hardened?

A configuration baseline is the written standard each firewall is measured against: enabled services, management protocols, time sync, SNMP version, log targets, session timeouts, login banners. Many organisations do not have one in writing. That is the finding. Until it is fixed, audit against the CIS Benchmarks, which include vendor-specific benchmarks for Palo Alto Networks, Check Point, FortiGate and Cisco firewalls.

BSI NET.3.2.A4 gives a short test: a firewall offers only the services it strictly needs, and unused services and extensions are disabled or removed. Then diff the running configs of HA peers and of firewalls that should be identical, such as branch firewalls built from one template. Differences nobody can explain are drift, and drift usually means someone changed the device outside the process.

Rule base review: report the summary

The rule base has its own method, set out step by step in the firewall rule audit guide: hit counts per vendor, shadowed and redundant rules, overly permissive rules, risky services, expired temporary rules and rules without an owner. The security audit report needs the summary: how many rules were reviewed, findings by category, and the few rules that carry real exposure.

Keep the rule review from eating the audit budget. In our experience it expands to fill whatever time it gets, while the admin interface that answers from the user network goes unchecked. Timebox it, and rate a busy any-service rule into a server zone above a hundred unused rules. PCI DSS requires network security control configurations to be "reviewed at least once every six months to confirm they are relevant and effective" (requirement 1.2.7), so in cardholder environments the rule review runs more often than the full audit anyway.

How do you test firewall logging and SIEM retention?

Test firewall logging end to end: create an event and watch it arrive. During fieldwork, log in as an admin, make a harmless change agreed in advance and fail one login on purpose. Then ask the SOC to show all three events in the SIEM with correct timestamps. If the config change raised no alert, that is a finding: NIST SP 800-41 Rev. 1 lists "any modifications or disabling of the firewall rules" among the events that should trigger real-time alerts to administrators.

BSI NET.3.2.A9 lists the minimum events to log, from rejected connections to configuration changes. Retention comes from your policy and your regulators. PCI DSS requirement 10.5.1 says to "retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis". Read the retention setting in the SIEM, where the logs actually live. Check time sync too, because logs from devices with drifting clocks cannot be correlated in an investigation.

Change management evidence

Sample change evidence from the firewall, not from the ticket system. Pull entries from the device's config log or revision history and trace each one to an approved ticket. A sample drawn from tickets only proves that approved changes happened. A sample drawn from the device also finds the changes nobody approved. NIST SP 800-41 Rev. 1 asks each review to include "a detailed examination of all changes since the last regular review, particularly who made the changes and under what circumstances".

The usual findings are changes with no ticket, tickets approved after the change went in, and emergency changes nobody reviewed afterwards. The process the audit tests against is described in the firewall change management guide.

Backup, restore and HA testing

Backups pass the audit when a restore has been tested, not when the job reports success. Ask for the last restore test: which device, which file, who did it and how long it took. NIST SP 800-41 Rev. 1 says firewall policies and rulesets "should be backed up regularly", and where a firewall offers both a binary and a human-readable format, "backups should be kept in all of them". NIS2 Article 21(2)(c) names backup management and disaster recovery among the minimum measures.

High availability gets the same question: when did the cluster last fail over on purpose, and what broke? If the answer is never, the HA pair is an assumption. The HA failover testing guide shows how to test it without causing the outage it is meant to prevent.

VPN and remote access

Remote access VPN is a front door, so audit it as one. Check that every remote user authenticates with MFA, that local VPN accounts on the firewall are gone or justified, and that the crypto settings (IKE version, encryption, integrity, DH groups) match your standard. For site-to-site VPN, list every tunnel with its peer, owner and purpose. Tunnels to partners whose contract ended long ago turn up in most estates, and so do certificates that expire next quarter with nobody assigned to renew them.

Segmentation

Test segmentation from a host inside each zone. Compare the zone design with the firewall's actual zone-to-zone matrix, then run connection tests from a host in each relevant zone towards the zones it should not reach. The segmentation requirements guide covers what NIS2 and PCI DSS expect. When the diagram and the matrix disagree, the matrix shows the network you actually run, and the diagram becomes a finding.

How do you rate firewall audit findings?

Rate each finding by what an attacker or a failure could do with it, not by how many items it contains. One admin interface reachable from the internet outweighs four hundred unused rules. The scale below is the one we use. Adjust the due dates to your own risk policy, but print the scale in the report so nobody argues about labels later.

What goes in a firewall security audit report?

A firewall security audit report has six sections and two appendices. The executive summary is the only part most managers read, so it fits on one page: the overall result, the top findings and the decisions you need from them. Everything after it exists so that each finding can be checked, assigned and closed.

FIREWALL SECURITY AUDIT REPORT
Organisation / environment:  ...
Audit period:                YYYY-MM-DD to YYYY-MM-DD
Audit lead:                  ...          Report version: 1.0

1. EXECUTIVE SUMMARY
   Overall result:           e.g. "Material weaknesses in 2 of 11 areas"
   Top findings:             3-5 lines, highest severity first
   Decisions needed:         budget, owners, risk acceptances

2. SCOPE
   In scope:                 devices, sites, cloud accounts (Appendix B)
   Out of scope:             what, and why
   Standards referenced:     internal baseline, CIS, ISO 27001, PCI DSS, NIS2

3. METHOD
   Evidence sources:         config exports, logs, tickets, interviews
   Sampling:                 population, sample size, selection method
   Tests performed:          reachability, logging, restore, failover
   Limitations:              what could not be tested, and why

4. FINDINGS SUMMARY
   Count by severity and by area

5. FINDINGS TABLE
   ID   | Area        | Finding                          | Severity | Evidence | Owner | Due date   | Status
   F-01 | Mgmt access | HTTPS admin reachable from users | Critical | E-03     | ...   | YYYY-MM-DD | Open

6. REMEDIATION PLAN AND RISK ACCEPTANCES
   Accepted risk:            finding ID, accepted by (name, role), expiry date

APPENDIX A  EVIDENCE INDEX
   ID | File or record | Device | Collected by | Date | SHA-256

APPENDIX B  DEVICE INVENTORY
   Device | Model | Version | End of support | Role | Owner

Three habits keep a report from being disputed. Every finding points to an evidence ID, because a finding without evidence turns into a debate. Every finding has one owner, named as a person. And every risk acceptance carries an expiry date; without one, an acceptance quietly becomes permanent.

Mapping the audit to ISO 27001, PCI DSS and NIS2

The same evidence serves all three frameworks; only the control references change. For certification audits, the ISO 27001 firewall audit checklist maps each area to its Annex A control. For cardholder data environments, the PCI DSS firewall guide covers Requirement 1, and the requirement texts are in the PCI SSC document library. For NIS2, Article 21(2)(f) asks for "policies and procedures to assess the effectiveness of cybersecurity risk-management measures". In our view a dated audit report with tracked findings is the most direct evidence for that point. The NIS2 firewall evidence guide maps the rest of Article 21.

How often should you audit firewalls?

Our recommendation: run the full firewall security audit once a year and after major changes such as a migration, and run the rule review more often, at least every six months where PCI DSS applies. NIST SP 800-41 Rev. 1 recommends reviewing the policy at regular intervals "so that such reviews do not only happen during policy or security audits (or, worse, only during emergencies)", and suggests occasional ruleset audits by people outside the normal review team. BSI NET.3.2.A24 recommends regular penetration tests and audits, and NIST adds that penetration testing belongs "in addition to, rather than instead of, a conventional audit program".

Run the free NIS2 Readiness Check to see which of the eleven areas your current evidence already covers, then plan the audit around the gaps.