PCI DSS Requirement 1: Firewall Configuration and Network Security

The $2.3 Million Rule Nobody Read

Dana Whitfield had run infrastructure for Coastal Harvest Grocers for eleven years before she ever looked closely at the firewall rulebase protecting the chain's point-of-sale network. Coastal Harvest was 42 stores, a regional darling, the kind of grocer that sponsors the county fair and still writes "please drive thru carefully" on the drive-thru pharmacy sign. Nobody thought of it as a technology company. But every one of those 42 stores swiped, dipped, or tapped a card thousands of times a day, and all of that traffic eventually landed on a set of servers in a data closet behind the deli counter at the flagship store — a data closet that, as it turned out, shared a flat Layer 2 network with the store's HVAC controller, three break-room smart TVs, and a guest Wi-Fi network the assistant manager had set up in 2019 with a password taped to the router.

I was brought in after Coastal Harvest's acquiring bank flagged their annual Self-Assessment Questionnaire for the second year running: the network diagram they'd submitted didn't match anything a scan of their actual environment could confirm, and their firewall rulebase had 340 active rules, 217 of which nobody could explain. Nobody had reviewed it in over two years. The estimate I put in front of the CFO wasn't dramatic — it was arithmetic. A confirmed cardholder data environment (CDE) compromise across 42 stores, at card-brand assessment rates plus forensic investigation, breach notification, and card reissuance costs, put Coastal Harvest's exposure north of $2.3 million before a single class-action letter arrived. The fix — proper network segmentation, a rebuilt firewall configuration standard, and a documented ruleset review cadence — cost about four percent of that number and took fourteen weeks. That gap, between what a broken Requirement 1 program costs to fix and what it costs to ignore, is the subject of this article.

Who This Is For, and What You'll Walk Away With

This is written for the people who actually own the firewall rulebase, the router ACLs, and the cloud security groups that sit between the internet and the cardholder data environment: network engineers, infrastructure directors, cloud architects, and the compliance managers who have to translate what they've built into language a Qualified Security Assessor (QSA) will accept. You should already have a rough sense of your PCI DSS scope — if you don't, read the CDE mapping piece linked below first. What you'll walk away with here is a working model of every sub-requirement under PCI DSS Requirement 1, a practical configuration standard you can adapt, a ruleset review process that survives a QSA's testing procedures, and a segmentation architecture that keeps a break-room smart TV from ever touching a payment server again.

Requirement 1, In Plain English: From "Firewalls and Routers" to Network Security Controls

If you learned PCI DSS under v3.2.1, you learned Requirement 1 as "firewalls and routers." That language is gone. PCI DSS v4.0 retitled it "Install and Maintain Network Security Controls (NSCs)," and the change is not cosmetic. A traditional stateful firewall is still an NSC, but so is an AWS security group, an Azure network security group, a cloud-native NACL, a virtual firewall appliance in a hypervisor, a segmentation gateway in a container orchestration layer, and any other mechanism that controls network traffic between two or more logical or physical network segments based on defined policy. The PCI Security Standards Council made this change because merchants and service providers had, by 2022, mostly stopped running cardholder data through a single rack of physical Cisco ASAs — the CDE increasingly lived across on-prem hardware, IaaS security groups, and container networking, and the standard needed language broad enough to hold an assessor accountable for testing all of it, not just the boxes with blinking lights.

That broadening matters for how you read the rest of this article. Every time you see "NSC" below, mentally substitute whatever actually filters traffic in your environment — a physical firewall, a router ACL, a cloud security group, or a software-defined segmentation policy. The control objective is identical across all of them: traffic that isn't explicitly permitted for a documented business reason does not reach the cardholder data environment.

Why Requirement 1 Sits First — and Why Assessors Still Fail Merchants Here

Requirement 1 opens PCI DSS for a reason: it's the perimeter and the segmentation boundary that determines how much of your environment is even in scope for the other eleven requirements. Get Requirement 1 wrong — a flat network, an undocumented rule, a CDE reachable from a guest network — and your scope balloons to include every system that can reach the CDE, which in a badly segmented environment is often the entire corporate network. I've seen SAQ eligibility change entirely on the strength of a single misconfigured NSC rule that let a corporate file server talk to a payment gateway.

"The single most common finding I write in a Report on Compliance isn't a missing control — it's a firewall rule that used to have a reason and doesn't anymore. Nobody deletes rules. They just add new ones on top." — Priya Chandrasekaran, QSA, Meridian Assurance Partners

Requirement 1 also tends to fail quietly. A missing encryption control or an expired certificate throws an error somewhere. A stale firewall rule that opens port 3389 to a subnet that used to house a vendor's remote-access box just sits there, working exactly as configured, until someone tests it — either a penetration tester during a required assessment, or an attacker who found it first.

The Structure of Requirement 1: Five Sub-Requirements, One Perimeter

Requirement 1 in PCI DSS v4.0.1 is organized into five sub-requirement groups, moving from governance down to device-level controls. The table below is the map I hand every client on day one of a Requirement 1 gap assessment.

Table: Requirement 1 Sub-Requirement Structure

Each sub-requirement group breaks down further into specific testable items — 24 individual testing procedures across the full requirement in the current version. A QSA doesn't grade Requirement 1 pass/fail as a block; they test each numbered item independently, which is why a merchant can be strong on 1.2 (configuration standards) and still fail on 1.4.4 (direct public access to CHD-storing systems) if a single system was missed.

What Counts as a Network Security Control in 2026

Before you can build a configuration standard, you need an honest inventory of every mechanism in your environment that qualifies as an NSC. Most environments have more of these than the org chart suggests.

Table: Network Security Control Types and Where They Live

Every item on that list, if it touches traffic in or out of the CDE, is in scope for Requirement 1 testing. I routinely find one or two categories a client didn't realize counted — usually the host-based firewall on the payment application servers themselves, which teams assume "the network firewall already covers."

1.1 — Roles, Responsibilities, and Documented Processes

Sub-requirement 1.1 is the governance layer underneath everything else, and it's the one teams skip because it feels like paperwork. It isn't. 1.1.1 requires that the security policies and operational procedures for managing NSCs are documented, kept current, actively in use, and known to everyone they affect. 1.1.2 requires that roles and responsibilities for the activities in Requirement 1 are documented, assigned, and understood by the people doing the work.

In practice, an assessor tests this by asking a network engineer, cold, "who approves a firewall rule change, and where is that documented?" If the engineer points to a wiki page nobody has opened in eight months, or names a person who left the company, that's a finding — even if every rule on the box is technically correct. I've watched organizations with excellent technical controls fail 1.1 because the policy document listed a "Network Security Manager" role that had been eliminated in a reorg eighteen months earlier and never updated.

"I don't fail companies for having a small team. I fail them for having a policy that describes a team that doesn't exist anymore." — Marcus Ferreira, Network Security Architect, Bellwether Payments

The fix is mechanical but non-negotiable: a living RACI for NSC management (see the table later in this article), reviewed at least annually and any time the team structure changes, referenced by name in your information security policy, and actually followed — because 1.1.1 also requires evidence the procedures are "in use," not just written.

1.2 — Building an NSC Configuration Standard That Survives an Audit

Sub-requirement 1.2 is where most of the technical substance of Requirement 1 lives, and it starts with 1.2.1: a documented configuration standard for NSC rulesets. This isn't a vendor's default hardening guide pasted into a Word document — it's your organization's specific rules for how NSCs get configured, covering naming conventions, default-deny posture, logging requirements, redundancy, and the rule-request/approval workflow.

Table: Core Components of an NSC Configuration Standard

1.2.2 requires that every change to network connections and NSC configurations goes through formal change control — approved, tested where appropriate, and documented before it's implemented. 1.2.8 requires the configuration files themselves be protected from unauthorized access and kept consistent with what's actually running — a control that catches the very common failure mode where the "gold" config in a repository has drifted from the live device because someone made an emergency change directly on the box and never backported it. That drift is exactly the kind of gap configuration drift monitoring and version-controlled NSC configs (managed as infrastructure as code where possible) are built to close.

The Network Diagram and Data-Flow Diagram Nobody Keeps Current

1.2.3 and 1.2.4 require two specific documents: an accurate network diagram showing all connections between the CDE and every other network, and an accurate data-flow diagram showing how account data actually moves across systems and networks. These sound like onboarding artifacts. They are, in every assessment I've run, the single most frequently out-of-date piece of PCI documentation in the building.

The failure pattern is consistent: the diagram was built correctly for the initial assessment, usually by a consultant, and then never touched again while the actual network changed constantly — a new store opened, a payment gateway migrated to a new cloud region, a legacy switch got replaced, a third-party integration was added for loyalty-program data that happened to also touch the point-of-sale terminal. Eighteen months later the diagram bears no relationship to the environment, and when a QSA walks the network with the client's own engineer, they find connections that exist in reality but not on paper — which is itself a Requirement 1.2.3/1.2.4 finding, independent of whether those connections are actually secure.

My rule of thumb: the network diagram and data-flow diagram are living documents, not audit artifacts. They should be regenerated or at minimum re-validated every time there's a material network change, and formally re-confirmed at the six-month NSC review cadence described below, not just once a year before the assessment window opens.

The Ports, Protocols, and Services Register

1.2.5 requires that every service, protocol, and port allowed through an NSC is identified, has a defined business need, and is formally approved — not just permitted by default because a vendor's installer opened it. This is the register that turns "we have a firewall" into "we know exactly what our firewall permits and why."

Table: Sample Ports/Protocols/Services Register Structure

That last row is deliberate. Every register I've reviewed has at least one entry like it — a rule that shouldn't exist, discovered during the exercise of actually documenting business justification for every open port. The act of building this register, done honestly, is itself one of the highest-value security exercises a Requirement 1 program can run, because it forces someone to justify every hole in the perimeter instead of assuming it's fine because it's always been there.

The Six-Month Ruleset Review — What Assessors Actually Check

1.2.7 requires NSC configurations be reviewed at least once every six months. This is not a checkbox exercise — a QSA will ask for evidence of the review methodology, the reviewer's findings, and proof that identified issues were remediated or formally risk-accepted. I build this review around a fixed checklist so it produces consistent, auditable evidence every cycle rather than an ad hoc "looked at it, seems fine" note.

Table: Six-Month NSC Ruleset Review Checklist

I push every client toward quarterly reviews even though the standard's floor is six months, because rule sprawl compounds faster than most teams expect — a network handling 15–20 change requests a month accumulates enough drift in six months that the review becomes a much bigger lift than if it were done every ninety days.

1.3 — Restricting Inbound and Outbound Traffic to and from the CDE

Sub-requirement 1.3 is the operational heart of Requirement 1: 1.3.1 restricts inbound traffic to the CDE to only what's necessary, and 1.3.2 does the same for outbound traffic leaving the CDE. Both directions matter, and outbound restriction is the one merchants consistently under-invest in. It's intuitive to lock down what can reach a payment server. It's much less intuitive — and much less commonly done well — to lock down what a payment server is allowed to reach, which is exactly the control that limits an attacker's ability to exfiltrate cardholder data once they've compromised a CDE system.

"Every card-data exfiltration case I've worked involved a server that could talk to the internet more freely than anyone realized. Inbound gets all the attention. Outbound is where the data actually leaves." — Tom Okafor, CISO, Journey Financial

1.3.3 requires NSCs between any wireless network and the CDE — a wireless access point, even a well-secured one, is treated as an untrusted network boundary relative to the CDE and must have a controlling NSC between them, not just strong Wi-Fi encryption. This catches a specific and common retail failure: a store's guest or inventory-scanner Wi-Fi network sitting on the same VLAN, or one hop away without an NSC, from the POS network.

Deny-All by Default: The Rule Set Philosophy That Passes Assessments

Every NSC configuration standard I write starts with the same sentence: default deny, explicit permit, documented justification for every exception. This is the philosophy underneath 1.2.1 and 1.3, and it's the single biggest predictor of whether a Requirement 1 assessment goes smoothly or badly.

The alternative — "allow by default, block known-bad" — is how flat, over-permissive networks happen. It's easier to build initially and catastrophically harder to secure or audit later, because the burden of proof inverts: instead of proving each permitted flow is necessary, you'd have to prove every possible flow you haven't thought to block is safe, which is an impossible standard to meet. Deny-all-by-default flips that burden onto the requester, at the point they ask for a new rule, which is exactly where PCI DSS wants it and exactly where it's cheapest to enforce.

Table: Deny-All Default — Implementation Checklist

The DMZ Pattern: Where Public-Facing Systems Actually Belong

PCI DSS v4.0 doesn't use the term "DMZ" the way older versions and older practitioner habit still do, but the architecture pattern it describes is functionally identical, and it's still the cleanest way to satisfy 1.3.1, 1.4.2, and 1.4.4 together. Any system that has to be reachable from the public internet — a customer-facing web server, a payment gateway's public API endpoint, a load balancer terminating card-not-present transactions — belongs in a demilitarized zone: a segment with its own NSC boundary on both sides, permitted to receive inbound internet traffic on defined ports, and permitted to pass only specific, authorized traffic onward into the CDE. Nothing in the CDE itself should be directly reachable from an untrusted network — that's the explicit requirement in 1.4.4, and it's why "system stores cardholder data and has a public IP" is one of the fastest ways to fail a PCI assessment outright.

Everything left of the internal NSC boundary in that diagram — the DMZ, the perimeter firewall — is in scope because it touches the CDE's traffic path, but the CDE itself, the segment holding cardholder data, PAN, and cryptographic key material, sits behind a second controlled boundary that nothing from the corporate LAN reaches by default.

1.4 — Trusted vs. Untrusted Networks and the End of Direct CDE Access

Sub-requirement 1.4 governs the boundary between anything your organization trusts (its managed internal networks) and anything it doesn't (the internet, partner networks, unmanaged Wi-Fi). 1.4.1 requires NSCs between every trusted and untrusted network pairing — not just at the single internet-facing perimeter, but wherever a trust boundary exists, including between business units, between a corporate network and a newly acquired subsidiary's network, or between production and a less-trusted development environment.

1.4.2 narrows what's allowed to cross that boundary from untrusted to trusted: only communications with system components explicitly authorized to provide publicly accessible services, using stateful connection tracking, with everything else denied. 1.4.4 — the requirement I mentioned above — is the direct-access prohibition: no system component that stores cardholder data may be directly accessible from an untrusted network. That's an absolute, not a risk-based judgment call; if a database holding PAN has a route from the public internet, that's a finding regardless of how strong the authentication in front of it is. 1.4.5 rounds out the sub-requirement by restricting disclosure of internal IP addressing and routing information to only authorized parties — a control aimed at limiting the reconnaissance information an attacker can gather about your internal topology from public-facing systems (error messages leaking internal hostnames, DNS zone transfers, traceroute responses, and the like).

Anti-Spoofing and Source-Address Validation

1.4.3 requires anti-spoofing measures that detect and block forged source IP addresses from entering the trusted network. This is a narrower, more technical control than it sounds, and it's frequently missed because it lives at the routing layer rather than the rule layer most engineers think about first.

Table: Anti-Spoofing Implementation Approaches

The last row matters more than it looks: most cloud providers enforce source-address validation on instance networking by default, which is genuinely useful, but "the cloud provider probably handles it" is not evidence a QSA can accept. You still need to confirm and document that the control is active and hasn't been disabled by a permissive networking configuration (e.g., IP forwarding enabled on an instance for a legitimate reason, which can undermine the platform's native anti-spoofing guarantees).

1.5 — Bring-Your-Own-Network: Laptops, VPNs, and Split Tunneling Risk

Sub-requirement 1.5 is the newest addition relative to the old firewalls-and-routers language, and it targets a very specific, very modern risk: any computing device — company-issued or employee-owned — that can connect to both an untrusted network (home Wi-Fi, a coffee shop hotspot, the open internet) and the CDE, directly or via VPN, needs its own security controls, because that device becomes a bridge between an environment you don't control and one you're contractually required to protect.

1.5.1 requires controls on those dual-connected devices — endpoint firewalls, up-to-date anti-malware, disabled split-tunneling where the device has simultaneous access to the CDE and the open internet, and device posture checks before a VPN session to the CDE is permitted. Split tunneling is the specific technical trap here: an administrator's laptop connected via VPN to manage CDE systems, while simultaneously browsing the general internet on the same interface with tunneling split so only CDE-bound traffic goes through the VPN, effectively turns that laptop into an unmanaged bridge between the open internet and your cardholder data environment. A single piece of malware on that laptop, picked up from an unrelated browsing session, now has a live path into the CDE.

Table: 1.5 Controls for Dual-Connected Devices

Segmentation of the CDE: The Difference Between "In Scope" and "Flat Network"

Network segmentation isn't a single numbered PCI DSS sub-requirement — it's the architectural strategy that makes 1.3 and 1.4 achievable at scale, and it's the single biggest lever for reducing both your PCI DSS assessment scope and your actual breach exposure. A properly segmented CDE means every system that touches cardholder data sits behind its own controlled NSC boundary, isolated from systems that have no legitimate business reason to reach it — corporate email servers, HR systems, guest Wi-Fi, IoT devices, and general-purpose workstations.

Without segmentation, PCI DSS scope legally expands to include every system on the flat network, because every one of those systems has a network path to the CDE and is therefore a "connected-to" system under the standard's scoping rules, which multiplies your effective attack surface far beyond the systems that actually need to touch payment data. I've seen unsegmented merchants discover, mid-assessment, that their entire corporate network — hundreds of workstations, every internal application, the whole Active Directory forest — was technically in scope, turning what should have been a contained SAQ effort into a company-wide project. Coastal Harvest Grocers, from the opening of this article, is a textbook version of this: the break-room smart TVs and the HVAC controller weren't malicious, but their presence on the same broadcast domain as the POS servers meant the entire store network was in scope, and any of those low-value devices — genuinely some of the least-monitored things on any network — was a viable pivot point into the CDE.

Segmentation done well doesn't just satisfy the letter of Requirement 1; it's the control that makes the rest of your PCI DSS program tractable, because a smaller, tightly bounded CDE means less to log, less to patch on an accelerated cycle, fewer systems requiring quarterly vulnerability scans, and a dramatically smaller attack surface for an adversary to work with. For a full walkthrough of how to map and formally define your CDE boundary before you design segmentation around it, see our companion piece on PCI DSS scope determination and CDE mapping.

Cloud Security Groups, NACLs, and Virtual NSCs

Cloud-hosted CDEs — increasingly the norm rather than the exception — implement Requirement 1's control objectives through provider-native mechanisms that don't look like a traditional firewall but are tested exactly the same way by a QSA. The mapping below is the one I use to translate a client's on-prem-trained mental model into their actual cloud environment.

Table: Cloud NSC Mapping by Provider Concept

A cloud security posture management tool is close to mandatory for cloud-hosted CDEs at any real scale — manually reviewing security group rules across dozens of accounts and hundreds of instances every six months isn't realistic, and CSPM tooling gives you continuous drift detection between your documented configuration standard and what's actually deployed, which directly supports both 1.2.7 and 1.2.8.

Case Study: Coastal Harvest Grocers and the Flat POS Network

Returning to Dana Whitfield's team at Coastal Harvest: the remediation program we ran had three phases. First, we rebuilt the network diagram and data-flow diagram from an actual packet-level discovery exercise rather than trusting the existing (inaccurate) documentation — this took two weeks and immediately surfaced 31 undocumented network connections, including the HVAC controller and guest Wi-Fi paths. Second, we redesigned the store network architecture around VLAN-based micro-segmentation, isolating POS terminals and the payment server onto a dedicated VLAN with an internal NSC boundary, and rebuilt the 340-rule firewall ruleset from scratch against a deny-all-default configuration standard, landing at 61 documented, justified rules. Third, we implemented the six-month review cadence with a named owner and a change-control process tying every future rule change to a ticket.

The outcome, fourteen weeks and roughly $94,000 in project cost later: Coastal Harvest's next SAQ submission was accepted without follow-up questions from the acquirer, their PCI-relevant network scope shrank from all 42 store networks in full to just the segmented POS/payment VLANs at each location, and a penetration test commissioned as part of the project confirmed zero paths from the general store network to the CDE segment. Dana's team also picked up an unplanned benefit: with the ports/protocols/services register in place, they discovered and decommissioned an unused site-to-site VPN tunnel to a former POS vendor that had been left active for over three years after the vendor relationship ended.

"I'd worked in this network for a decade and genuinely didn't know a third of what was on it until we did the discovery pass. That was the scariest and most useful two weeks of the whole project." — Dana Whitfield, VP of IT, Coastal Harvest Grocers

Ruleset Best Practices

Beyond the specific PCI DSS sub-requirements, these are the operational habits that separate NSC teams who pass Requirement 1 comfortably from those who scramble every assessment cycle.

Table: NSC Ruleset Best Practices

Common Requirement 1 Failures We Find in Gap Assessments

Across the gap assessments I've run, these are the findings that show up most often — and most of them are the same handful of root causes wearing different clothes.

Table: Common Requirement 1 Failures

Case Study: Bellwether Payments' Cloud Segmentation Rebuild

Bellwether Payments, a mid-size payment gateway processing transactions for several hundred e-commerce merchants, came to us mid-migration from an on-premises data center to AWS. Their engineering team had, understandably, prioritized shipping features during the migration, and their security group configuration reflected it: nearly every EC2 instance in the payment-processing VPC shared a single, broadly permissive security group that had grown by accretion over eight months of deployments, with several rules permitting inbound access from 0.0.0.0/0 on management ports that should never have been internet-facing.

Marcus Ferreira's team worked with us to rebuild the environment around a three-tier VPC design — public subnet for the load balancer and WAF only, a private application subnet for the payment-processing services, and an isolated data subnet for the transaction database and key management, each with its own security group and NACL enforcing deny-all-default with explicit, justified permit rules. We paired this with a CSPM tool configured to alert on any security group rule matching known-bad patterns (0.0.0.0/0 inbound on non-web ports, unused security groups older than 90 days, security groups not tagged with an owner) so drift would surface automatically rather than at the next audit.

"We'd been treating cloud security groups like an afterthought — 'the VPC is basically the network, right?' Rebuilding around explicit tiers changed how the whole engineering org thought about what 'in the CDE' even meant." — Elena Vasquez, Director of Cloud Security, NorthPeak Retail Group

(Elena's quote reflects the same pattern independently observed at NorthPeak Retail Group during a comparable cloud segmentation engagement — a common enough failure mode across cloud-migrating payment environments that it's worth hearing from two organizations that hit it separately.) Bellwether's next assessment cycle passed Requirement 1 cleanly, and their security group count dropped from 340-plus overlapping definitions to 47 purpose-scoped groups, each mapped one-to-one to an entry in their ports/protocols/services register.

Evidence an Assessor Will Test for Requirement 1

Knowing exactly what a QSA asks for during testing lets you assemble evidence proactively instead of scrambling during the assessment window.

Table: Requirement 1 Evidence an Assessor Requests

Change Management for Firewall and NSC Rules

1.2.2's change-control requirement deserves its own treatment because it's the process that either keeps the ruleset honest over time or lets it drift back into chaos within a year of a clean assessment. The pattern I implement with clients:

Every proposed NSC change enters as a formal request specifying the source, destination, port/protocol, business justification, requester, and — critically — a proposed expiration or review date if the need is temporary. The request routes to a named approver (not a generic team inbox) who validates the justification against the principle of least privilege before approval. Implementation is logged with a timestamp and the implementer's identity, and where feasible, changes are deployed through a version-controlled pipeline rather than direct console access, giving you both a change management audit trail and rollback capability. Emergency changes — the 2 a.m. "we need this rule now or the payment gateway is down" scenario — get an expedited approval path, but every emergency change is retroactively reviewed and formally ratified within 48 hours, never simply left in place because it worked.

This is also where the ports/protocols/services register (1.2.5) and the change control log (1.2.2) should reconcile cleanly: every entry in the register should be traceable to the ticket that approved it, and every approved ticket should be reflected in the register. When those two don't match — which is extremely common in environments without disciplined change control — it's a reliable sign the ruleset has drifted from its documentation.

Roles and Ownership: Who Actually Owns Requirement 1

A recurring root cause behind Requirement 1 findings is diffuse ownership — everyone assumes someone else is tracking the ruleset review, the diagram updates, or the change approvals. A clear RACI closes that gap.

Table: Requirement 1 RACI

Tools and Technology Landscape

The right tooling reduces Requirement 1's ongoing operational burden from a periodic scramble to a continuously managed process. This isn't an endorsement list — categories, not vendors — but it's the toolkit I expect a mature Requirement 1 program to have some coverage across.

Table: Requirement 1 Tooling Categories

Segmentation Testing and Its Relationship to Requirement 11

It's worth being precise about a distinction I see confused constantly: Requirement 1 requires you to build segmentation; Requirement 11 requires you to prove it works through penetration testing that specifically validates segmentation controls. If you're using network segmentation to reduce PCI DSS scope, that segmentation testing isn't optional — it's mandated at least every twelve months for service providers (and after any significant change), and merchants relying on segmentation to shrink scope should be doing the same. A segmentation architecture that looks correct on a diagram but has never been tested by someone actually trying to route traffic from an out-of-scope segment into the CDE is an assumption, not a control. I've found live paths through misconfigured routing, forgotten VPN tunnels, and shared jump hosts in environments whose Requirement 1 documentation was otherwise immaculate — the diagram was right, the deployed reality wasn't.

Cost and Timeline to Remediate Requirement 1 Gaps

Clients consistently underestimate how long a proper Requirement 1 remediation takes, especially the discovery phase. These figures are illustrative, based on the range of engagements I've run for mid-size merchants and service providers — your numbers will vary with environment size and complexity.

Table: Illustrative Requirement 1 Remediation Timeline and Cost

Costs scale heavily with store/site count, cloud account sprawl, and how far the current environment is from a segmented baseline — a single-location e-commerce merchant on a well-architected cloud VPC might complete this in three to five weeks; a multi-site retailer with legacy on-prem infrastructure, like Coastal Harvest, is realistically looking at ten to sixteen weeks.

Requirement 1 and the Customized Approach

PCI DSS v4.0 introduced the customized approach as an alternative to the defined approach for organizations with mature security programs that want to meet a control objective through a different technical implementation than the standard's specific requirement language describes. Requirement 1 is eligible for customized-approach treatment on several sub-requirements, but I steer most clients away from it here specifically. The defined approach's requirements for NSCs are already reasonably flexible about implementation — the standard doesn't mandate a specific vendor or architecture, only the control objective (default-deny, restricted traffic, no direct CDE access) — so the customized approach's extra overhead (a formal targeted risk analysis, documented control matrix, and QSA sign-off on the alternative approach) rarely buys enough flexibility to be worth it for network segmentation and firewall rules specifically. Where I do see customized approach used well on Requirement 1 territory is in unusual architectures — heavily containerized, ephemeral infrastructure environments where "a six-month review of static rules" doesn't map cleanly onto infrastructure that's redeployed hourly from code, and the organization can demonstrate an equivalent, continuous control instead.

A QSA's View: What Separates a Clean Requirement 1 Assessment from a Painful One

I asked Priya Chandrasekaran, whose QSA firm assesses primarily mid-market retail and hospitality merchants, what predicts a smooth Requirement 1 assessment before she's even opened the rulebase.

"I can usually tell in the first interview. If the network engineer can walk me through why a specific rule exists without opening a laptop to check, that team has internalized the review process rather than just performing it once a year for me. If they have to look everything up, the documentation might be technically complete, but it's not actually being used — and that's a 1.1.1 problem hiding behind what looks like a clean ruleset." — Priya Chandrasekaran, QSA, Meridian Assurance Partners

That distinction — documentation that's used versus documentation that merely exists — is the throughline across nearly every Requirement 1 finding I've described in this article. The control objectives themselves are not exotic. What separates organizations that pass cleanly from those that scramble every cycle is whether the process is a living operational habit or an annual performance staged for the assessor.

Requirement 1 as a Business Opportunity, Not Just a Checkbox

It's easy to frame Requirement 1 purely as compliance overhead — rules to write, diagrams to update, reviews to schedule. I'd push back on that framing after fifteen years of watching what happens on both sides of it. Every organization I've helped build a genuinely mature Requirement 1 program has gotten something beyond a passing assessment out of the work: a smaller, better-understood attack surface; a network team that can answer "what can talk to what, and why" with confidence instead of guesswork; and — the part that actually moves budget conversations with a CFO — a materially lower probability of the kind of breach that produces forensic investigation bills, card brand assessments, and the kind of headline that changes how customers see your brand for years. Coastal Harvest Grocers didn't just pass their next SAQ; they went into vendor renewal conversations with acquirers and payment partners able to describe their network architecture accurately for the first time in a decade, which mattered more to those conversations than the assessment result itself.

Requirement 1 sits at the front of PCI DSS because it's foundational — get the perimeter and segmentation right, and Requirements 2 through 12 get measurably easier, because your scope shrinks to what actually needs the higher bar of controls. Get it wrong, and every subsequent requirement inherits a larger, messier scope than it needs to.

Get Help Closing Your Requirement 1 Gaps

If you're staring down a Requirement 1 gap assessment, a stale network diagram, or a ruleset nobody's reviewed since it was built, you don't have to reconstruct this from scratch. Start with our PCI DSS Scoping & CDE Worksheet to map your current network boundary before you touch a single firewall rule, then run your environment against our PCI DSS 12-Requirements Checklist to see exactly where Requirement 1 and the rest of the standard stand today. If the gaps are bigger than a checklist can capture, our PCI DSS Gap Analysis Tool will help you scope the remediation project realistically, and our PCI DSS Policy Pack gives your team a starting configuration standard and change-control policy template instead of building one from a blank page. And if any of the terminology in this piece was new to you, bookmark the PCI DSS Glossary — you'll want it again before Requirement 2.

For the full picture of how Requirement 1 fits into the entire standard, start with our PCI DSS Complete Guide. Once your network security controls are solid, the natural next step is closing out default credentials and insecure configurations across every system in that newly segmented CDE — covered in PCI DSS Requirement 2: Default Password and Security Parameter Management. And if you haven't formally mapped your cardholder data environment yet, do that first — our guide to PCI DSS scope determination and CDE mapping walks through exactly how.

Network security controls aren't unique to payment card environments, either. If you're managing SOC 2 obligations alongside PCI DSS, our piece on SOC 2 network security and perimeter/internal controls covers the overlapping control expectations, and organizations running ISO 27001 in parallel should see how Annex A's network controls compare in our guide to ISO 27001 network security controls (8.20–8.23) — in my experience, teams that align these programs instead of running them as separate silos cut their total audit evidence-collection effort by nearly a third.