Your QSA just asked for the documented business justification for every active rule on your perimeter firewall, including the temporary “any/any” your network team opened for a vendor PoC eighteen months ago. Under PCI DSS v3.2.1 you might have talked your way through it. Under PCI DSS v4.0.1, you don’t.
This post breaks down what actually changed in Requirement 1 between PCI DSS v3.2.1 and v4.0.1, which sub-requirements bite hardest in real assessments, and what your firewall change management process needs to look like now that every future-dated control became mandatory on March 31, 2025.
Key Takeaway
PCI DSS v4.0.1 reframes Requirement 1 around “Network Security Controls” instead of firewalls and routers, makes semi-annual rule review explicitly required, requires documented business justification for every approved service, protocol, and port, and introduces a formal roles and responsibilities control (1.1.2). If your change management process can’t produce a complete audit trail per rule, you will fail an assessment.
What Are Network Security Controls Under PCI DSS v4.0?
Network Security Controls (NSCs) are any technology that enforces network policies governing traffic into, out of, and within the cardholder data environment (CDE). Under PCI DSS v4.0.1, this is no longer limited to traditional Layer 3/4 firewalls. The PCI Council’s Summary of Changes recognizes NSCs to include cloud security groups (AWS Security Groups, Azure NSGs, GCP firewall rules), virtualization-based controls, software-defined networking policies, and host-based firewalls. Anywhere a rule decides whether traffic touches in-scope systems, it counts.
The terminology shift matters. v3.2.1 was written for a 2010-era network: a hardware firewall at the perimeter, a DMZ, and a flat internal network behind it. The renaming acknowledges that for most modern CDEs, the perimeter is a logical construct enforced by dozens of policy points across hybrid cloud, virtualized, and containerized infrastructure.
Requirement 1: v3.2.1 vs v4.0.1 at a Glance
| Area | PCI DSS v3.2.1 | PCI DSS v4.0.1 |
|---|---|---|
| Title | “Install and Maintain a Firewall Configuration to Protect Cardholder Data” | “Install and Maintain Network Security Controls” |
| In-scope technology | Firewalls and routers | Any NSC: firewalls, cloud SGs/NSGs, virtualized and SDN controls, host firewalls |
| Roles and responsibilities | Description of groups/roles for managing network components (1.1.5) | General roles and responsibilities for Requirement 1, documented, assigned, understood (1.1.2) |
| Configuration review cadence | Every 6 months (1.1.7) | At least every 6 months, intent clarified (1.2.7) |
| Approved services / ports / protocols | Single requirement covering business justification and insecure protocols (1.1.6) | Split into two: approved services with justification (1.2.5) and insecure services with documented mitigations (1.2.6) |
| Devices connecting to both CDE and untrusted networks | Addressed indirectly | Explicit control with intent clarified (1.5.1) |
| Approach | Prescriptive only | Defined Approach plus optional Customized Approach |
The Sub-Requirements That Will Trip You Up
1.1.2 Roles and Responsibilities
“Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.” Your QSA will ask for a named list: who approves rule changes, who implements them, who reviews them semi-annually, who handles emergency changes. “The network team” is not an acceptable answer. Every Requirement (1 through 12) now carries an analogous X.1.2 control, as documented in the official Summary of Changes.
1.2.5 Approved Services, Protocols, and Ports
Every service, protocol, and port permitted on an NSC must be identified, approved, and have a documented business need. If you allow SMB out from the CDE because someone on the storage team needed it three years ago, you need the ticket, the approval, and a current statement of why it remains necessary.
1.2.6 Insecure Services and Protocols
Where insecure services (Telnet, FTP, SMBv1, TLS 1.0/1.1, etc.) are in use, you need documented business justification plus documented additional security features that mitigate the risk. The compensating controls aren’t optional padding. They’re testable.
1.2.7 Configuration Reviews Every Six Months
NSC configurations must be reviewed at least once every six months to confirm they remain relevant and effective. The review needs to produce evidence: who reviewed, when, what they found, and how exceptions were handled. If you have a high change volume, the guidance pushes for more frequent review. Assessors increasingly expect quarterly cadence on dynamic environments.
1.5.1 Devices Connecting to Both the CDE and Untrusted Networks
Any computing device (admin laptops, jump boxes, BYOD endpoints) that can connect to both an untrusted network and the CDE must have specific security controls: configurations defined to prevent threats from being introduced, anti-malware where applicable, and host-level restrictions that aren’t user-modifiable. If your network engineers VPN from their home Wi-Fi into the CDE from the same laptop they use to read email, this control applies.
As of March 31, 2025, every previously future-dated requirement in PCI DSS v4.0.1 is mandatory. There is no longer a “best effort” grace period.
What Changed for Firewall Change Management Specifically
v3.2.1 told you to have a change control process. v4.0.1 tells you what that process must produce, on demand, for every NSC in scope. In practical terms, three things shifted.
- Per-rule traceability is now table stakes. Every active rule needs to be tied back to an approved change request, a named approver, a business justification, and an implementation date. “We inherited it” doesn’t pass.
- The semi-annual review must produce evidence, not assertions. A signed-off review document showing every rule examined, decisions made (keep, modify, retire), and follow-through on retirements. If the same stale rule appears in three consecutive reviews, that’s an audit finding.
- Cloud and virtualized policy enforcement is in scope. AWS Security Groups and Azure NSGs are NSCs. They need the same change discipline as your perimeter Palo Alto or Fortinet: approval, justification, review, and retirement workflow.
A Practical Compliance Checklist
Use this to gap-assess your environment before your next ROC or SAQ-D submission.
- Inventory every NSC in scope: hardware firewalls, cloud security groups, WAFs, SDN policies, host firewalls on jump hosts.
- For each NSC, confirm a current configuration baseline is stored under version control.
- Build a roles and responsibilities matrix mapping each Requirement 1 activity (approval, implementation, review, exception handling) to a named role.
- Audit every active rule against an approved change ticket. Flag rules without traceable approval. These become your remediation backlog.
- For every insecure protocol still in use, document the business need and the compensating controls in one place your QSA can find without asking twice.
- Schedule the semi-annual review on the calendar with named participants and a defined output artifact.
- Identify all devices connecting to both untrusted networks and the CDE. Verify host-level restrictions, anti-malware, and locked-down configurations are in place.
- Confirm that out-of-band/emergency changes follow a documented post-implementation review process, not just a Slack message.
The Customized Approach Trap
v4.0.1’s outcome-based Customized Approach looks attractive on paper. Define your own controls as long as you meet the requirement’s objective. In practice, it’s heavier than the Defined Approach. You need a documented Targeted Risk Analysis, a Controls Matrix, and your QSA has to test that your custom controls actually meet the stated objective. Most organizations are better served treating Defined as the default and reserving Customized for genuinely unusual architectures.
Risk: The most common v4.0.1 audit failure isn’t a missing control. It’s an inability to produce evidence. Your rules might be correct, your reviews might happen, your roles might be clear. If you can’t show it on demand with timestamps and approvers, your assessor has to mark it “Not in Place.”
What to Do Before Your Next Assessment
If your next ROC is more than ninety days out, prioritize in this order:
- Close the roles and responsibilities gap (1.1.2). It’s the cheapest control to implement and one of the first things assessors check.
- Run a complete rule audit against change tickets. Retire orphan rules. Document justifications for everything that stays.
- Stand up an evidence pipeline. Somewhere every rule change, approval, review, and exception lands automatically with timestamps. Spreadsheets work until they don’t. A system of record is far more defensible.
- Bring cloud security groups and NSGs into the same change workflow as your hardware firewalls. If your AWS console allows arbitrary engineers to add 0.0.0.0/0 ingress without a ticket, that’s a finding.
- Address 1.5.1 by tightening admin endpoint posture before the assessor asks about it.
Bottom Line
PCI DSS v4.0.1 didn’t make firewall compliance harder in concept. It made it harder to fake. The standard now expects mature change management as a precondition, not an aspiration: documented owners, justified rules, scheduled reviews, traceable approvals, and the same discipline applied to cloud security groups as to hardware firewalls. The organizations that fail audits in 2026 won’t be the ones with weak rules. They’ll be the ones who can’t produce the paper trail.
How CyberX Helps
Most teams don’t fail PCI DSS Requirement 1 because they have bad firewalls. They fail because their change management lives in tickets, spreadsheets, email threads, and a few engineers’ memory. CyberX is purpose-built for the v4.0.1 evidence problem: every rule change tied to a request, an approver, and a justification; semi-annual reviews scheduled and documented; orphan rules surfaced before your QSA finds them; and the same workflow across hardware firewalls, cloud security groups, and virtualized NSCs. If you’re staring down a 2026 ROC and worried about the audit trail, that’s the gap we close.