Bottom Line Up Front
PCI DSS network segmentation isolates the systems that store, process, or transmit cardholder data from everything else on your network. Done well, it shrinks your cardholder data environment (CDE), which means fewer systems to assess, fewer controls to evidence, and a cheaper audit. Segmentation isn’t strictly required by the standard, but without it your entire flat network is in scope.
Plan on six to twelve weeks for a small or mid-sized environment, depending on how tangled your architecture is. A SaaS company on AWS with a clean VPC layout can finish in under a month. A retailer with a decade of flat-network sprawl will need the full stretch.
Before You Start
Prerequisites
You’ll need:
- Network and data flow diagrams, even rough ones. You’ll fix them in Step 1.
- Admin access to firewalls, cloud security groups, routers, switches, and Kubernetes network policies.
- An asset inventory that includes cloud resources, SaaS tools, and third-party connections.
- Working knowledge of your PCI DSS merchant or service provider level and your SAQ type or Report on Compliance (ROC) path.
- A way to test: a vulnerability scanner, Nmap, and either an internal pen tester or an outside firm.
Stakeholders
- Executive sponsor: approves downtime windows and budget, and breaks ties when engineering and security disagree.
- Network/DevOps engineers: build and change the actual controls.
- Security or compliance lead: owns scope decisions and evidence.
- Application owners: tell you what really talks to what.
- Your QSA or ISA: ask them early whether your planned approach will be accepted for scope reduction. Don’t wait for the assessment to find out.
Scope
This guide covers scoping, designing, implementing, testing, and maintaining segmentation. It doesn’t cover the full set of PCI DSS controls inside the CDE, such as encryption, logging, and vulnerability management. Those still apply to everything left in scope.
Frameworks this supports
Segmentation work maps cleanly to other frameworks, so you rarely do it for PCI alone:
| Framework | Related control area |
|---|---|
| PCI DSS | network security controls, scope validation, segmentation penetration testing |
| SOC 2 | Logical access and network boundary protection (Security criteria) |
| ISO 27001 | Network segregation and network security controls in Annex A |
| NIST CSF | Protect function: network integrity and protective technology |
| HIPAA Security Rule | Technical safeguards, access and transmission security |
Step-by-Step Process
Step 1: Map Every Cardholder Data Flow (1–2 weeks)
What to do: Trace card data from the moment it enters your environment to the moment it leaves or is destroyed. Cover e-commerce checkout, POS terminals, call center keying, payment APIs, batch files, backups, logs, and support tickets where customers paste card numbers.
Why it matters: Your scope is defined by where data actually goes, not where you think it goes. Assessors will ask for your data flow diagram first.
What can go wrong: Forgotten flows are the usual culprit. Look for card data in application logs, analytics pipelines, email, and database replicas. Run a data discovery scan to find PANs in places they shouldn’t be.
Step 2: Shrink the Problem Before You Segment It (1 week of decisions)
What to do: Ask whether you need to touch card data at all. Redirect-based or iframe hosted payment pages, tokenization, and validated point-to-point encryption (P2PE) can eliminate entire system groups from scope.
Why it matters: The cheapest system to segment is the one that never sees a PAN. A Series A startup using a hosted payment field from its processor may qualify for a much lighter SAQ than one that posts card data through its own API.
What can go wrong: Teams assume tokenization removes everything. Your page that loads the payment form may still be in scope, and your QSA will want to see that reasoning documented.
Step 3: Classify Your Systems (3–5 days)
What to do: Sort every asset into a scope category.
| Category | Definition | Typical examples |
|---|---|---|
| CDE | Stores, processes, or transmits cardholder data | Payment app servers, card databases, POS terminals |
| Connected-to / can impact | Has connectivity to the CDE or can affect its security | Admin workstations, jump hosts, monitoring |
| Security-providing | Delivers security services to the CDE | Active Directory, DNS, SIEM, MFA, patch servers |
| Out of scope | Isolated, no connectivity, no impact | Marketing site, internal wiki, dev sandboxes with no real data |
Why it matters: This table becomes the backbone of your scope document. Shared services like Active Directory and logging are where most teams get surprised, because those systems pull far more into scope than expected.
What can go wrong: Declaring something “out of scope” because it’s “just internal.” If it can reach the CDE without a control in between, it’s in scope.
Step 4: Design the Segmentation Architecture (1–2 weeks)
What to do: Choose your isolation method and draw the target state.
- Cloud: Separate AWS accounts, Azure subscriptions, or GCP projects for the CDE. Use dedicated VPCs/VNets, with security groups and NACLs enforcing the boundary.
- On-prem: Dedicated VLANs terminating on a firewall (not just a router ACL), ideally with a separate firewall zone for the CDE.
- Kubernetes: Dedicated clusters or at minimum dedicated namespaces with enforced network policies. Namespaces alone aren’t a security boundary.
- Access path: One controlled entry point, typically a hardened jump host or PAM solution with MFA.
Why it matters: Separate cloud accounts give you a strong blast-radius boundary and clean evidence. Logical separation inside one account works, but it requires more rigorous proof.
What can go wrong: Over-engineering. A 40-person company doesn’t need microsegmentation across 200 workloads. A well-defined CDE VPC with a default-deny boundary beats a half-finished zero trust project.
Step 5: Implement Default-Deny Controls (2–4 weeks)
What to do: Build the boundary with a deny-all baseline, then allow only documented, business-justified flows. Every rule needs an owner and a reason.
A simplified Terraform example for a CDE database security group:
“`hcl
resource “aws_security_group” “cde_db” {
name = “cde-db”
vpc_id = aws_vpc.cde.id
ingress {
description = “App tier to DB, TLS only”
from_port = 5432
to_port = 5432
protocol = “tcp”
security_groups = [aws_security_group.cde_app.id]
}
# No egress to the internet; explicit allow to log collector only
egress {
description = “Logs to SIEM”
from_port = 6514
to_port = 6514
protocol = “tcp”
cidr_blocks = [“10.20.5.10/32”]
}
}
“`
Why it matters: Inbound and outbound rules both count. Assessors look for restricted egress from the CDE, which many teams skip.
What can go wrong: “Temporary” any-any rules that become permanent. Tag every rule with a ticket number and review date, and put your rule set under IaC so changes go through pull requests.
Compliance checkpoint: Before moving on, confirm your firewall and security group rulesets have documented business justification for each allowed service, protocol, and port.
Step 6: Lock Down Access Into the CDE (1 week)
What to do: Require MFA for all access into the CDE, not just remote access. Use dedicated admin accounts, enforce least privilege with RBAC, and route administrative sessions through a logged jump host.
Why it matters: Segmentation controls network paths, but humans with standing access bypass it. A flat admin workstation that can reach both the corporate network and the CDE is a bridge across your boundary.
What can go wrong: Shared service accounts and vendor access. Audit third-party remote access and require time-bound, monitored sessions.
Step 7: Test the Segmentation (1–2 weeks)
What to do: Run penetration testing designed to prove isolation. Test from every out-of-scope network segment toward the CDE, testing all ports and protocols, not just common ones. Test from inside the CDE outbound as well.
Why it matters: The standard expects segmentation controls to be verified through penetration testing, at least annually and after significant changes. Service providers face a more frequent cadence. Your tester must be organizationally independent and qualified.
What can go wrong: Scanning only the “expected” ports, or testing from one VLAN and assuming the rest behave the same. Test every segment boundary.
Step 8: Document and Obtain Sign-Off (1 week)
What to do: Finalize your scope document, network diagrams, data flow diagrams, system inventory, and rule justifications. Have your executive sponsor sign off.
Why it matters: Undocumented segmentation looks identical to no segmentation in an audit.
Verification and Evidence
Confirm each step with a specific artifact:
| Step | Verification | Evidence to collect |
|---|---|---|
| Data flows | Walkthrough with app owners | Signed-off data flow diagram |
| Scope reduction | QSA concurrence | Written scope rationale, processor attestation |
| Classification | Inventory reconciles with CMDB/cloud | System inventory with scope tags |
| Architecture | Peer review | Network diagram with trust boundaries |
| Controls | Config export, rule review | Firewall/security group exports, IaC repo |
| Access | Access test, MFA enforcement check | IAM policies, MFA logs, PAM session logs |
| Testing | Independent pen test | Segmentation test report, remediation tickets |
What the auditor will want to see: current diagrams that match reality, firewall rule reviews with justifications, a segmentation pen test report with retest evidence for any findings, and proof that out-of-scope systems cannot initiate connections into the CDE. Expect them to pick a few rules at random and ask who approved them.
A quick sanity test you can run yourself is a scan from a corporate workstation:
“`bash
nmap -Pn -p- –open 10.20.0.0/24
“`
If anything responds from outside your approved paths, you have a finding before your assessor does.
Common Mistakes
1. Treating VLANs as security boundaries. VLANs separate broadcast domains. Without a firewall enforcing rules between them, traffic often routes freely. Fix: Enforce policy at a firewall or equivalent. This is a quick fix if hardware exists, an architectural one if it doesn’t.
2. Forgetting shared services. Active Directory, DNS, and logging servers connect to everything, which drags those systems into scope. Fix: Deploy dedicated CDE instances of these services, or accept that the shared ones are in scope and secure them accordingly.
3. Testing once and never again. Teams pass a pen test, then change the network six times. Fix: Tie segmentation retesting to your change management process.
4. Ignoring egress. Open outbound access lets malware exfiltrate data and makes the CDE reachable from the internet through callbacks. Fix: Default-deny egress with explicit allowlists. Usually a quick fix.
5. Poor documentation of “why.” Rules exist, but nobody remembers the reason. Fix: Require justification fields in every change ticket and review them quarterly. It happens because engineers focus on making things work, not on audit trails.
Maintaining What You Built
Review cadence
| Activity | Frequency |
|---|---|
| Firewall and security group rule review | At least every six months |
| Segmentation penetration test | Annually, more often for service providers |
| Scope and data flow review | Annually |
| Access review for CDE | Quarterly is a practical target |
| Diagram and inventory update | On every change that affects the CDE |
Change management triggers
Retest or re-evaluate scope whenever you:
- Add a new payment channel or processor
- Migrate to a new cloud account, region, or provider
- Change firewalls, routing, or network architecture
- Merge with or acquire another company
- Introduce new shared services or vendor connectivity
- Deploy new Kubernetes clusters or shared CI/CD runners that touch the CDE
Annual reassessment
Each year, rerun Steps 1 through 3 as if from scratch. Compare the result against your documented scope. Differences are your drift. Then run the segmentation test and update all documentation before your assessment begins.
Automate where you can. CSPM tools can alert on security group changes, and IaC scanning in your CI/CD pipeline can block risky rules before they merge.
FAQ
Is PCI DSS network segmentation required?
No, the standard doesn’t mandate it. But without it, your whole network is treated as in scope, which dramatically expands cost and effort. Almost every organization with more than a handful of systems benefits from it.
Can I use VLANs alone for segmentation?
Only if something enforces access rules between them, such as a firewall or properly configured layer 3 ACLs. Assessors will want evidence that traffic is actually blocked, which a segmentation penetration test provides.
Does cloud segmentation count the same as physical segmentation?
Yes, if the controls are properly configured and tested. Separate accounts or subscriptions with security groups, NACLs, and network policies are accepted. Remember that your cloud provider’s responsibility covers only the underlying infrastructure.
How often do I need to test segmentation?
At least annually and after any significant change to segmentation controls or network architecture. Service providers have more frequent requirements, so confirm the exact cadence with your QSA.
Does tokenization remove me from PCI scope entirely?
Rarely. It can substantially reduce scope, but systems that handle the payment page, redirects, or token exchange can still be in scope. Document what remains and validate it with your assessor.
Conclusion
Good PCI DSS network segmentation comes down to five habits: know where card data flows, reduce what touches it, enforce a default-deny boundary, prove isolation through independent testing, and keep documentation current as your environment changes. None of it requires an enterprise-sized team. It requires discipline and a clear order of operations.
SecureSystems.com provides practical, results-focused compliance and security services for startups, SMBs, and agile teams across SaaS, fintech, healthcare, e-commerce, and the public sector. We specialize in making compliance achievable for organizations that don’t have a 20-person security team, with clear timelines, transparent pricing, and hands-on implementation support. Whether you need PCI scoping help, SOC 2 readiness, ISO 27001 implementation, HIPAA compliance, penetration testing, or ongoing security program management, our security analysts, compliance officers, and ethical hackers get you audit-ready faster. Book a free compliance assessment to find out exactly where you stand.