PCI DSS Firewall Requirements: What Requirement 1 Asks and the Evidence a QSA Wants

PCI DSS firewall requirements sit in Requirement 1, “Install and Maintain Network Security Controls”. It has five sections: 1.1 covers policies and roles, 1.2 configuration and change control, 1.3 traffic into and out of the cardholder data environment (CDE), 1.4 connections between trusted and untrusted networks, and 1.5 devices that connect to both. In our experience, the control assessors spend the most time on is 1.2.7: every network security control (NSC) configuration reviewed at least once every six months.

Which version applies? The PCI Security Standards Council (PCI SSC) retired v3.2.1 on 31 March 2024, and the 51 future-dated v4.0 requirements became effective on 31 March 2025. PCI DSS v4.0.1 was announced in June 2024 as a limited revision with no new or deleted requirements, and v4.0 was retired on 31 December 2024. At the time of writing (October 2026), assessments run against v4.0.1, so the requirement numbers below are the ones your QSA will quote.

This guide covers the firewall side only: every Requirement 1 control, the evidence an assessor asks for, the six-month review and what belongs in a configuration standard. For the German market see PCI DSS 4.0 for German payment processors. For keeping the evidence current between assessments see PCI DSS 4.0 compliance automation.

Which PCI DSS requirement covers firewalls?

Requirement 1 covers firewalls, though the word “firewall” is gone from its title. The PCI SSC v3.2.1 to v4.0 Summary of Changes replaced “firewalls” and “routers” with “network security controls” to support a broader range of technologies used to meet the security objectives firewalls traditionally met. In practice an NSC is any control that decides which traffic passes between network segments: a hardware or virtual firewall, a cloud security group, a router ACL, a microsegmentation policy. If it decides what reaches the CDE, it falls under Requirement 1 and its rules need the same documentation as the perimeter firewall.

The five sections, as the standard titles them:

• 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.
• 1.2 Network security controls (NSCs) are configured and maintained.
• 1.3 Network access to and from the cardholder data environment is restricted.
• 1.4 Network connections between trusted and untrusted networks are controlled.
• 1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

PCI DSS firewall requirements, control by control

The table below lists each Requirement 1 control in PCI DSS v4.0.1, what it asks for in plain terms, the evidence a Qualified Security Assessor (QSA) typically requests, and how a working firewall change process produces that evidence. The evidence column reflects what assessors ask for in our experience. The testing procedures in the standard itself are the binding reference.

Requirement	What it asks	Evidence a QSA wants	How change management produces it
1.1.1	Requirement 1 policies and procedures are documented, kept up to date, in use and known to all affected parties	Current policy with revision history; proof the team knows it	The change process document is the policy, and its revision log shows upkeep
1.1.2	Roles and responsibilities for Requirement 1 activities are documented, assigned and understood	A role matrix naming who requests, approves, implements and reviews	Workflow roles in the change tool match the matrix one to one
1.2.1	Configuration standards for NSC rulesets are defined, implemented and maintained	The written standard, plus proof live rulesets follow it	Each request is checked against the standard before approval
1.2.2	All changes to network connections and NSC configurations are approved and managed under the change control process in 6.5.1	A sample of changes with request, approval, implementation and verification records	The change ticket is the record; any rule traces back to one
1.2.3	An accurate network diagram shows all connections between the CDE and other networks, including wireless	A dated diagram that matches the live configuration	Changes that alter a CDE connection carry a “diagram updated” task
1.2.4	An accurate data-flow diagram shows all account data flows, updated when the environment changes	The data-flow diagram and its update history	A change that adds a flow updates the diagram before closure
1.2.5	All allowed services, protocols and ports are identified, approved and have a defined business need	A rule inventory with owner and business justification per rule	Justification is a mandatory request field: no field, no rule
1.2.6	Security features are defined and implemented for insecure services, protocols and ports in use	The list of insecure protocols in use and the mitigation for each	The request flags insecure protocols and requires the mitigation before approval
1.2.7	NSC configurations are reviewed at least once every six months to confirm they are relevant and effective	Dated review records, reviewer names, findings and closed actions	Review findings become change tickets, so each removal is traceable
1.2.8	NSC configuration files are secured from unauthorized access and kept consistent with active configurations	Access control on config backups; proof stored and running configs match	A post-change backup and a drift check against approved changes
1.3.1 / 1.3.2	Inbound and outbound CDE traffic is restricted to what is necessary; all other traffic is specifically denied	Rulesets showing an explicit deny, with a justification for every allow	Deny by default sits in the standard; every allow comes from a ticket
1.3.3	NSCs sit between all wireless networks and the CDE; wireless traffic into the CDE is denied by default	Ruleset and diagram for each wireless segment	Wireless segments are tagged so changes touching them get CDE-level review
1.4.1 / 1.4.2	NSCs sit between trusted and untrusted networks; inbound traffic is limited to authorized public services and stateful responses, all other traffic denied	Edge rulesets and a list of publicly exposed services with owners	Exposing a new public service is its own change type with security sign-off
1.4.3	Anti-spoofing measures detect and block forged source IP addresses	Configuration showing anti-spoofing on untrusted interfaces	Part of the standard, checked on every edge change
1.4.4	System components that store cardholder data are not directly accessible from untrusted networks	Path analysis showing no direct route from the internet to storage	A change that would open such a path fails review
1.4.5	Disclosure of internal IP addresses and routing information is limited to authorized parties	NAT configuration and routing and DNS filtering	Covered by the configuration standard
1.5.1	Security controls on any device, company or employee owned, that connects to both untrusted networks and the CDE: defined settings, actively running, not alterable by users without time-limited management approval	Endpoint security policy, compliance reports, an exception list with expiry dates	Exceptions run as time-boxed changes with an end date

What changed for firewalls between v3.2.1 and v4.0.1?

Less than the 2022 launch coverage suggested, in our view. The Summary of Changes classifies most Requirement 1 edits as clarifications. These are the ones that matter to a firewall team:

• Terminology. “Firewalls” and “routers” became “network security controls”, which brings cloud and software-defined controls into scope by name.
• The six-month review was renumbered. v3.2.1 requirement 1.1.7 became 1.2.7, with the intent clarified as reviewing NSC configurations at least once every six months. The interval did not change.
• Change control points to 6.5.1. Requirement 1.2.2 now says NSC changes are managed under the change control process defined at Requirement 6.5.1, so a firewall change is assessed against the same procedure as any other production change.
• Roles became a general requirement. v3.2.1 1.1.5 asked for a description of groups, roles and responsibilities for network components. v4.0 1.1.2 asks for roles and responsibilities across all of Requirement 1.
• Configuration standards got their own requirement. 1.2.1 took a former null requirement and refocused it on defining, implementing and maintaining configuration standards for NSC rulesets.
• Personal firewalls became 1.5.1. v3.2.1 1.4 was clarified to cover security controls on any computing device that connects to both untrusted networks and the CDE.

v4.0.1 added nothing on top. PCI SSC describes it as a limited revision with no new or deleted requirements.

What belongs in a PCI firewall configuration standard?

A PCI firewall configuration standard is the written rulebook that requirement 1.2.1 asks you to define, implement and maintain for NSC rulesets. PCI DSS does not prescribe its contents, so assessors judge it on whether it is specific enough to check a ruleset against. A standard that holds up in an assessment usually covers:

• Default deny on every interface facing the CDE, inbound and outbound (1.3.1, 1.3.2).
• Object conventions: named hosts and groups, and no “any” in source, destination or service on CDE rules without a documented exception.
• Mandatory rule metadata: owner, business justification, ticket reference and last review date (1.2.5).
• The protocols your organization treats as insecure, and the security feature required whenever one is allowed (1.2.6).
• Anti-spoofing on untrusted interfaces and limits on exposing internal addressing (1.4.3, 1.4.5).
• Logging on every rule that touches the CDE, and hardening of the management interfaces.
• Where configuration backups live, who can read them and how drift from the running configuration is detected (1.2.8).

Write platform-specific sections where syntax differs, but keep one set of principles. Two standards that disagree on what “any” means will surface as a finding. A quick test: hand the standard and a random ruleset to someone outside the firewall team. If they cannot tell which rules break it, the standard is too vague to assess against.

How do you run the PCI firewall review every six months?

Requirement 1.2.7 asks for NSC configurations to be reviewed at least once every six months to confirm they are relevant and effective. Relevant means each rule still has a business need. Effective means the ruleset still enforces your configuration standard. Exporting the ruleset and filing the export proves neither. The review process we see pass assessments runs in six steps:

1. Schedule from the last review, not the calendar. Six months is the maximum gap. Teams that book reviews for “Q2 and Q4” overshoot the first time a change freeze pushes one back.
2. Export the full scope. Every NSC that filters CDE traffic: perimeter and internal firewalls, cloud security groups and segmentation controls. A forgotten cloud account is the gap we find most often.
3. Send each rule to its owner. The owner confirms the business need or marks the rule for removal. Ownerless rules go to the CDE system owner and are removed if nobody claims them by a set date.
4. Check effectiveness. Look at hit counts, shadowed and redundant rules, overly broad objects and anything that violates the standard. A zero-hit rule is a candidate, not an automatic deletion: some exist for yearly batch jobs or failover paths.
5. Turn findings into change tickets. Every removal or tightening goes through the normal 1.2.2 change process, which gives the assessor a line from review finding to implemented change.
6. Close and sign. Produce a dated record with reviewer names, scope, findings and the ticket number for each action. Open actions get a target date before the next review.

How long the review takes depends on your change process. If every rule entered through a ticket with an owner and a justification, step 3 takes days. If half the rulebase predates the change process, the first review turns into a cleanup project. The firewall rule recertification guide covers the owner workflow in more detail.

Where does the evidence come from? Requirement 6.5.1

Requirement 1.2.2 sends every NSC change through the change control process in Requirement 6.5.1. That requirement says production changes follow procedures that include the reason for and description of the change, documentation of security impact, documented approval by authorized parties, testing to verify the change does not adversely impact system security, and procedures to address failures and return to a secure state. Make each of those a mandatory field in the firewall change request and most Requirement 1 evidence builds up as a by-product:

• Reason and description give you the business justification 1.2.5 needs.
• Security impact covers the insecure-protocol check for 1.2.6 and the CDE path check for 1.4.4.
• Approval records are the 1.2.2 sample the QSA pulls.
• Testing shows the change did what was approved and nothing else.
• The back-out procedure is your rollback plan, and it also governs emergency changes approved after the fact.

Requirement 6.5.2 adds that after a significant change, the applicable PCI DSS requirements are confirmed on the new or changed systems and documentation is updated. For firewalls, that documentation is mostly the diagrams in 1.2.3 and 1.2.4. Without a “diagram updated” closing task on changes that alter a CDE connection, the diagram falls months behind before the assessment.

Changes made outside the process are the other half of the problem. A rule that appears on a firewall with no ticket breaks 1.2.2 and usually 1.2.5. Policy drift detection, which compares running configurations against approved changes, closes that gap and doubles as the 1.2.8 consistency check.

Where PCI firewall audits fail

In our experience the technical controls are rarely the problem. Most PCI firewall findings are evidence gaps:

• Justifications that justify nothing. “Requested by IT” or “application access” does not say which system, which service and which business process needs the flow. Write “payment API host group needs HTTPS to the acquirer gateway”.
• A review that happened but left no record. With no date, no reviewer and no action list, an assessor has nothing to test.
• Outbound left open. Requirement 1.3.2 restricts outbound CDE traffic as strictly as inbound, yet many rulesets still allow any outbound traffic to the internet from the CDE. The egress filtering guide covers how to tighten it without breaking updates and payment callbacks.
• Diagrams older than the ruleset. The QSA compares last year’s diagram against the live configuration, and every difference becomes a question.

All four trace back to the change process, which is why the firewall change management guide is the place to start if your Requirement 1 evidence is thin.

Will your next six-month review produce a record a QSA accepts? The free NIS2 Readiness Check walks through the change evidence that PCI DSS 1.2.2 and 1.2.7 also ask for.