Three years ago I raised a PCI DSS finding on a bank that the IT team did not take well.
The bank had a next-generation firewall from a tier-one vendor — properly configured, fully patched, logs shipping to the SIEM. The network diagram was accurate. The access control list was documented. By every surface metric, the firewall was in excellent shape.
The finding was that nobody had reviewed the firewall ruleset in 26 months.
There were 34 rules referencing IP addresses and systems that no longer existed. Three rules created for a vendor migration in 2021 that the vendor had never been asked to close. And one rule — still open and active — permitting inbound traffic from an external IP range that no one in the room could explain. The technology was not the problem. The governance around it had been completely absent.
This is part of the network security fundamentals reference on Threat Manifest, covering the core controls that appear across compliance assessments in financial institutions. Understanding how does a firewall work technically takes about five minutes. Understanding how firewall governance fails in practice — and what assessors look for when they evaluate it — is what this article actually covers.
What a Firewall Actually Does — And What It Doesn't
A firewall controls traffic between two or more network zones. It inspects packets arriving at its interface and applies a configured ruleset — allowing or blocking each packet based on criteria that range from simple (source IP, destination port) to sophisticated (application identity, content inspection, user identity).
That is the complete technical definition. The rest is detail about how that decision is made.
More useful for anyone working in or around compliance is an honest account of what a firewall does not do:
- It does not stop threats that arrive via permitted channels. If your email filtering passes a malicious attachment, the perimeter firewall has no role in stopping it. The traffic is allowed. The decision was made upstream.
- It does not protect against threats originating inside the network. A compromised workstation behind the firewall, or an insider threat, is not filtered by a perimeter firewall. Lateral movement happens on the inside.
- It does not compensate for weak authentication. A firewall permitting traffic to a system with a default admin password permits an attacker to use that password as freely as a legitimate user.
- It is not a substitute for network segmentation. A firewall is one of the tools used to enforce segmentation — but a single perimeter firewall protecting a flat internal network provides dramatically less resilience than a properly segmented architecture with internal firewall controls at zone boundaries.
Being precise about what a firewall does not do is not a limitation to be apologised for. It is how practitioners think about defence-in-depth. You layer controls because no single control is complete. The firewall is a critical layer — not a perimeter behind which everything else can relax.
What this means for your compliance posture
A firewall is a necessary control — it is not a sufficient one. Every framework that requires a firewall also requires evidence that it is working as designed, and that someone is actively maintaining it. Technology without governance is a gap, not a control.
The Three Types of Firewalls You Will Actually Encounter
Most environments you assess or work in use one of three firewall types — or a combination. The distinction matters for compliance because different frameworks reference different capabilities, and an NGFW running in packet-filter mode is a finding waiting to happen.
Packet filtering firewalls
The oldest form. Packet filtering examines each network packet in isolation — source IP, destination IP, protocol, port — and permits or blocks based on static rules. No memory of prior packets. No concept of connection state.
Packet filtering still appears in legacy environments, embedded in routers, and in low-cost edge devices. It is fast and simple. It is also limited: it cannot distinguish between a legitimate HTTP response and a malicious one on the same port, because it has no understanding of what a "response" means in context.
Stateful inspection firewalls
Stateful inspection adds connection tracking. The firewall maintains a state table of active sessions and uses that context when evaluating subsequent packets. A packet claiming to be part of an established session is only permitted if the firewall recorded that session being initiated.
This is the baseline assumption across most compliance frameworks. When PCI DSS or ISO 27001 requires a firewall, they are assuming stateful inspection as the minimum viable capability.
Next-generation firewalls (NGFW)
NGFWs add application awareness, deep packet inspection, integrated intrusion prevention, and threat intelligence integration. They operate at Layer 7 of the OSI model — meaning they can distinguish between Salesforce and a file-sharing application both running over HTTPS on port 443.
For organisations processing payment card data, SWIFT transactions, or regulated financial records, NGFWs are increasingly the expected baseline. The relevant question is not "do we have an NGFW?" but "are the NGFW capabilities actually configured and operating?" Purchasing an NGFW and running it in stateful inspection mode only is a common and expensive oversight.
Stateful Inspection
- Inspects headers and tracks connection state
- Permits or blocks by IP, port, and protocol
- Does not inspect application-layer content
- Fast, well-understood, and reliable
- Baseline assumed by most compliance frameworks
Next-Generation (NGFW)
- Application awareness — knows if port 443 is Salesforce or Dropbox
- Deep packet inspection — inspects content, not just headers
- Integrated IPS — blocks known attack patterns inline
- Threat intelligence feeds — blocks known-malicious IPs automatically
- Required where compliance scope demands Layer 7 visibility
How Firewalls Appear Across PCI DSS, ISO 27001, and SWIFT CSP
One of the consistent gaps in firewall documentation at financial institutions is treating compliance as a single-framework exercise. A bank running PCI DSS, ISO 27001, and SWIFT CSP simultaneously has firewall requirements appearing across all three standards — with different language, different control identifiers, and different evidence expectations.
The PCI DSS framework reference covers Requirement 1 in full, including the specific evidence a QSA expects during a firewall review.
The key observation from the three-framework mapping: the governance requirement — documented, reviewed, justified firewall rules — appears in all three frameworks. This is not a PCI DSS-specific bureaucratic requirement. It is a universal expectation of any mature security framework, because any framework that calls for a firewall also requires evidence that the firewall is doing what it is supposed to do, and that someone is checking.
Firewall at each internet connection and between any DMZ and internal network. Restrict inbound/outbound to necessary traffic only. Review all rule sets at least every six months.
Signed ruleset review document dated within 6 months + change management records for all rule additions.
Networks secured, managed, and controlled. Segregation based on risk. Rules reviewed at defined intervals with documented justification for all active connections.
Network management procedure + dated review record + documented firewall policy with owner sign-off.
Customer infrastructure protected via documented network filters. Rules maintained with justification. Restriction of OS and application access from external networks.
Network architecture diagram + rule justification register + evidence of periodic review with dates.
What a Firewall Ruleset Review Actually Involves
The most expensive firewall finding I raise is never about the technology. It is about a ruleset that has grown unchecked for two years while the business changed around it.
Sabuj Golder — Security Assessor, Threat Manifest
Firewall ruleset review has become one of the fastest-growing compliance search terms in the past three months — almost certainly driven by organisations scrambling to meet PCI DSS v4.0.1 requirements that became mandatory in March 2025. PCI DSS Requirement 1.3.2 specifies review at least every six months. ISO 27001 A.8.20 requires documented review at defined intervals. SWIFT CSP Control 1.1 requires rules to be maintained and their justification documented.
Six months is the maximum interval. In a financial institution with frequent system changes, vendor onboarding, and infrastructure migrations, a quarterly review cycle is more defensible and easier to evidence.
What a ruleset review actually covers:
A compliant ruleset review is not a read-through of the rule list. It addresses:
Orphaned rules
Rules referencing IP addresses, hostnames, or services that no longer exist. These accumulate invisibly during migrations, decommissions, and vendor offboarding — a system retired two years ago may still have an open inbound rule because no one closed it.
Overly permissive rules
Rules using "any" as source or destination where a specific IP range should have been defined. These are shortcuts taken under time pressure — tightening was deferred and never happened.
Temporary rules made permanent
Rules created for a specific project, migration, penetration test, or incident response that were never closed after the activity concluded. The most common source of unexplained open traffic paths in a mature ruleset.
Undocumented rules
Rules with no business justification on record. When an assessor asks why a rule is open and the answer is "we're not sure" — the finding is written before the ruleset is even opened.
Change management alignment
Does the live ruleset match the approved change record? Rules with no corresponding change request indicate either a bypass or an unrecorded emergency change — both are findings regardless of whether the rule itself is appropriate.
What good documentation looks like:
Every active rule needs a structured record containing: business justification, requesting owner, approval reference, date created, and scheduled review or expiry date. Not a paragraph in a shared document. A record in your change management tool that an assessor can locate and cross-reference within thirty seconds. If an assessor cannot find the justification for a rule in the tool your organisation uses for change management, the documentation does not count.
The five-point firewall audit sequence
When a QSA reviews your firewall documentation, they check five things in order. (1) Is there a current network diagram showing where the firewall sits? (2) Does a firewall policy exist with management approval? (3) Can you produce a dated ruleset review completed within the last six months? (4) For each active rule, is there a business justification in the change management system? (5) Does the live configuration match the approved change record? If any check fails, a finding is raised before the ruleset is even opened.
The Firewall Findings I Actually Raise in Bank Assessments
These are not theoretical failure modes. They are the specific findings that appear, repeatedly, across mid-size and large financial institutions — regardless of vendor, regardless of NGFW model, regardless of how much was spent on the hardware.
Ruleset not reviewed within required interval
Most common PCI DSS firewall finding. Review cycle exists on paper. Evidence of the last completed review — signed document, dated output, change ticket — cannot be produced. Assessment cannot close until a completed review with management sign-off is produced.
the single most time-consuming finding to remediate mid-assessment.
"Any/any" rules in restricted network zones
Rules permitting traffic from any source to any destination, found in a DMZ, cardholder data environment segment, or internal zone. Typically created during a migration or incident response and never removed. High-risk finding under PCI DSS Req 1.3 and SWIFT CSP Control 1.1.
they must be removed or replaced before the assessment can close.
No documented justification for open inbound rules
Inbound rules permitting external traffic to internal systems with no traceable business justification in the change management system. The absence of documentation is the finding — not the rule itself, which may be entirely appropriate.
documentation gaps cannot be backdated once fieldwork has started.
Live configuration not aligned to change record
Rules present in the live firewall configuration that no approved change request accounts for. Indicates either a change management bypass or an unrecorded emergency change. Both are control failures independent of whether the rule's content is appropriate.
reconciliation between live config and change log must be completed before fieldwork.
NGFW operating below purchased capability
NGFW purchased and deployed, but application-awareness and deep packet inspection are not configured. The device is performing stateful inspection only. Raised when the documented architecture describes NGFW-level controls but the device is not delivering them.
capability gaps between documented architecture and actual configuration are a common observation finding.
What Good Firewall Governance Looks Like
The vendor you chose matters less than the process around it. A ten-year-old stateful firewall with a documented, reviewed, and audited ruleset will pass a PCI DSS assessment more readily than a current-generation NGFW with no governance process.
Good firewall governance rests on four components — none of which require a technology upgrade:
Documented firewall standards. A policy specifying: who can approve new rules, what justification is required, what the maximum permitted scope of a rule is, and how frequently rules must be reviewed. One specific, enforceable page is worth more than ten pages of aspirational prose.
A current and accurate ruleset. Every active rule has a business owner, a documented justification, and a next review date. Rules past their review date are escalated automatically. New rules require approval before deployment — not as a retrospective courtesy.
A regular, evidenced review cycle. Minimum every six months under PCI DSS. Quarterly in high-change environments. The output of each review is a dated, signed document recording what was reviewed, what was found, and what was changed or closed. That document is your evidence — not the fact that a review "was done."
Change management alignment. Every ruleset change is preceded by an approved change request. Emergency changes are logged at the time and retrospectively approved within a defined window. The live configuration can always be reconciled to the change record — meaning no rule can exist that a change request does not account for.
If your firewall governance does not currently meet these four standards, the gap is process, not technology. Process gaps are typically faster and cheaper to close than hardware upgrades. And they are what auditors are actually looking for.
The four-line governance self-test
Before your next assessment, answer these four questions: (1) Can you produce a signed ruleset review dated within the last six months? (2) Does every active rule have a business justification in your change management system? (3) Can you reconcile every live rule to an approved change request? (4) Is there a documented owner responsible for the next review? If you can answer yes to all four — your firewall governance will pass scrutiny. If not, fix the process, not the hardware.