PCI-DSS 4.0 Firewall Requirements: What Security Teams Need to Know
PCI-DSS 4.0, released in March 2022 with a mandatory compliance deadline of March 31, 2025, introduced fundamental changes to how organizations must manage their firewall infrastructure. Requirement 1 — now titled “Install and Maintain Network Security Controls” — has been restructured, expanded, and modernized. For security teams, this means updated processes, better documentation, and in many cases, new tooling.
This guide covers the specific PCI-DSS 4.0 requirements that affect firewall management, what has changed from version 3.2.1, and how automation helps security teams achieve and maintain compliance.
What Changed in PCI-DSS 4.0 for Firewalls
The most significant change in PCI-DSS 4.0 is the shift from prescriptive controls to outcome-based requirements. The standard no longer specifies exactly how to implement security — it specifies what the security outcome must be. For firewalls, this means:
- Terminology update: “Firewalls” is replaced with “Network Security Controls” (NSCs), reflecting that modern perimeter security includes more than traditional firewalls (cloud security groups, WAFs, micro-segmentation).
- Customized approach: Organizations can now define their own controls to meet requirements, as long as they can demonstrate the security objective is achieved. This gives more flexibility but requires more documentation.
- Expanded documentation: Every firewall rule must have a documented business justification. Network diagrams must be accurate and updated when changes occur. Change management processes must be formalized.
- Review cadence: Semi-annual review of firewall rules is now explicitly required (previously just best practice).
- New future-dated requirements: Several new requirements became mandatory on March 31, 2025, including enhanced documentation, role-based access reviews, and automated log monitoring.
Requirement 1.x Deep Dive
Requirement 1 is structured into five sub-requirements. Here is what each one means for your firewall operations:
1.1 — Processes and Mechanisms
This sub-requirement mandates that processes for managing network security controls are defined, documented, and understood. In practical terms:
- ✓ Written firewall change management policy
- ✓ Defined roles and responsibilities (who can request, approve, implement)
- ✓ Documented approval workflow
- ✓ Process for emergency changes with retroactive review
- ✓ Regular policy review (at least annually)
1.2 — Network Security Controls Configuration
This is the core of the firewall requirements and where most organizations struggle during audits:
- 1.2.1: Configuration standards defined and applied to all NSCs. Default vendor passwords changed. Unnecessary services disabled.
- 1.2.2: All changes to NSCs are approved and managed per the defined change control process. This is where a structured change management process becomes essential.
- 1.2.4: Accurate, current network diagrams that show all connections between the CDE and other networks. Must be updated when changes occur.
- 1.2.5: All services, protocols, and ports that are allowed have a defined business need, and each is documented.
- 1.2.6: Security features are defined and documented for all services, protocols, and ports in use, including justification and approval for those considered insecure.
- 1.2.7: NSC configurations are reviewed at least once every six months to confirm they are relevant and effective.
- 1.2.8 (New): Configuration files for NSCs are secured from unauthorized access and kept consistent with active configurations.
1.3 — Network Access Restrictions
Controls on traffic between trusted and untrusted networks:
- 1.3.1: Inbound traffic to the CDE is restricted to only that which is necessary.
- 1.3.2: Outbound traffic from the CDE is restricted to only that which is necessary.
- 1.3.3: NSCs are installed between all wireless networks and the CDE.
1.4 — Connections Between Trusted and Untrusted Networks
NSCs must be implemented between trusted and untrusted networks, with specific controls on traffic to and from the CDE. Personal firewalls on mobile devices connecting to the CDE are also required.
1.5 — Risks to the CDE from Computing Devices
New in 4.0: risks from computing devices that connect to both untrusted networks and the CDE must be mitigated. This affects remote access, BYOD, and contractor access policies.
Documentation Requirements That Catch Teams Off Guard
The most common PCI-DSS audit findings related to firewalls are documentation gaps, not technical misconfigurations. Auditors check for:
- Business justification for every rule. Not just “requested by IT” — the actual business need (e.g., “Application X on server Y requires HTTPS access to payment gateway Z for transaction processing”).
- Approval records. Who approved the change, when, and their authority to do so. Email approvals buried in inboxes do not count — auditors need a retrievable record.
- Change history. Complete timeline of when rules were added, modified, or removed, with before/after state.
- Semi-annual review evidence. Proof that every rule was reviewed in the last six months, with confirmation that each rule is still needed.
- Network diagrams. Current, accurate diagrams showing all connections between the CDE and other networks. These must be updated whenever firewall changes affect network topology.
- Exception documentation. If any insecure protocols or non-standard configurations exist, documented risk acceptance with compensating controls.
Preparing for Your PCI-DSS Firewall Audit
The best time to prepare for a PCI-DSS audit is the day after your last one. Compliance is an ongoing process, not a point-in-time exercise. Here is a practical preparation checklist:
- ☐ Review and update your firewall change management policy
- ☐ Verify every rule has a documented business justification
- ☐ Complete the semi-annual rule review (document the review with dates and reviewer names)
- ☐ Update network diagrams to reflect current topology
- ☐ Remove any rules that no longer have a business need
- ☐ Verify no default vendor credentials exist on any firewall
- ☐ Confirm change approval records are complete and retrievable
- ☐ Test that deny-all default policies are in place
- ☐ Verify inbound and outbound CDE traffic restrictions
- ☐ Check that configuration files are secured and backed up
How Automation Helps Achieve PCI-DSS Compliance
Meeting PCI-DSS 4.0 requirements manually is possible but painful. The documentation burden alone — business justifications, approval records, change histories, review evidence — requires significant ongoing effort. Automation transforms this:
Without Automation
- ✗ Manual rule documentation in spreadsheets
- ✗ Email-based approval chains
- ✗ No automated conflict detection
- ✗ Semi-annual reviews take weeks
- ✗ Audit preparation is a separate project
- ✗ Diagrams manually maintained
With Automation
- ✓ Business justification captured at request time
- ✓ Multi-level approval with complete audit trail
- ✓ AI-powered rule analysis catches conflicts instantly
- ✓ Semi-annual reviews completed in hours
- ✓ Every change is audit-ready from day one
- ✓ Topology auto-generated from firewall configs
FwChange was built specifically with PCI-DSS compliance in mind. Every change request requires a business justification. Approval workflows enforce separation of duties. The complete audit trail is exportable in compliance-ready formats. Semi-annual reviews can be completed in hours instead of weeks, with AI-assisted analysis highlighting rules that may no longer be needed.
If you are preparing for a PCI-DSS assessment and want to see how your current rulebase measures up, the free rulebase scanner provides an instant health check of your firewall policies. You can also view pricing to understand the full platform capabilities.
See How Your Firewall Rules Score
Upload your config and get a free compliance report with shadow rule detection, conflict analysis, and optimization recommendations.
Stay Updated
Get firewall management tips, compliance guides, and product updates.
No spam. Unsubscribe anytime.