04 Network Segmentation

Network segmentation is one of the most important architectural techniques used to isolate the Cardholder Data Environment (CDE) from the rest of the enterprise.

The objective is not simply:

Put the CDE
on a different VLAN

The objective is to establish and prove that:

Only Authorized Traffic
      ↓
Can Enter or Leave
      ↓
The CDE

A strong PCI segmentation model looks like:

Enterprise Network
      ↓
Segmentation Boundary
      ↓
Controlled Access Zone
      ↓
CDE

The core security question is:

Can systems outside the CDE access, influence, administer, or bypass the CDE through unauthorized network paths?

If the answer is yes, the segmentation model may not support the intended PCI scope reduction.

Learning Objectives

By the end of this lesson, you will be able to:

Explain network segmentation in PCI DSS.
Understand why segmentation can reduce PCI scope.
Define a CDE network boundary.
Build network security zones.
Apply default-deny principles.
Define allowed communication paths.
Understand firewall and cloud network controls.
Identify administrative access paths.
Understand jump-host architecture.
Understand cloud segmentation.
Understand microsegmentation.
Understand segmentation in Kubernetes.
Review firewall rules.
Identify overly broad network access.
Develop a segmentation test plan.
Understand segmentation penetration testing.
Document segmentation evidence.
Assess segmentation failures.
Build segmentation exceptions.
Maintain continuous segmentation assurance.

1. What Is Network Segmentation?

Network segmentation separates systems into controlled security zones.

Example:

Corporate Network
      ↓
Firewall
      ↓
CDE Network

The firewall restricts communication between the two environments.

2. Why Segmentation Matters for PCI DSS

Without effective segmentation:

Corporate Systems
      ↔
Payment Systems

large parts of the enterprise may become relevant to PCI scope.

With effective segmentation:

Corporate Systems
      ✗
      ↓
Security Boundary
      ↓
CDE

the organization may be able to reduce the number of systems requiring PCI controls.

3. Segmentation Is Not Mandatory in Every Architecture

An organization may choose to operate:

Flat Environment

and apply PCI requirements broadly.

However, this typically increases:

Systems

Controls

Evidence

Testing

Operational Cost

Segmentation is therefore often used as a scope-reduction strategy.

4. Scope Reduction Depends on Effective Segmentation

A crucial principle is:

Segmentation Exists
      ≠
Segmentation Effective

The boundary must be:

Designed

Implemented

Configured

Tested

Monitored

5. Basic PCI Segmentation Architecture

Example:

Internet
   │
   ▼
WAF / Edge Firewall
   │
   ▼
Payment Web Tier
   │
   ▼
Application Tier
   │
   ▼
Payment Database


Corporate Network
   │
   ✗
   │
Segmentation Firewall
   │
   ▼
Admin Zone
   │
   ▼
CDE

6. Define Security Zones

A mature architecture may use several zones.

Example:

Internet Zone

DMZ

Application Zone

Database Zone

Management Zone

Corporate Zone

Security Services Zone

7. CDE Zone

The CDE zone contains systems that:

Store CHD

Process CHD

Transmit CHD

Access should be highly restricted.

8. Corporate Zone

The corporate zone may contain:

Employee Workstations

Corporate Applications

Printers

Collaboration Tools

These should not normally have unrestricted access to CDE systems.

9. Management Zone

A dedicated management zone may contain:

Jump Hosts

Privileged Workstations

Administrative Tools

This creates a controlled administrative path into the CDE.

10. Security Services Zone

May contain:

SIEM

Vulnerability Scanner

NTP

DNS

PKI

Communication should be explicitly defined.

11. DMZ

For internet-facing payment systems:

Internet
      ↓
DMZ
      ↓
Internal CDE

can provide layered isolation.

12. Build PCI Network Segmentation Design

Create:

01 PCI Network Segmentation Design

Document:

Zones

CDE Boundary

Firewall Locations

Administrative Paths

External Connections

Security Services

13. Communication Matrix

For every zone pair define:

Source

Destination

Port

Protocol

Purpose

Owner

Create:

02 CDE Communication Matrix

Use:

Source	Destination	Port	Protocol	Purpose

14. Example — Web to Application

Payment Web
      ↓
Payment API

Allowed:

TCP 443

Business purpose:

Payment Request Processing

15. Example — Application to Database

Payment Application
      ↓
Payment Database

Allowed only on required database ports.

16. Example — Corporate to Database

Corporate Laptop
      ↓
Payment Database

Expected:

Blocked

17. Default Deny

Strong segmentation follows:

Deny Everything
      ↓
Allow Explicitly Required Traffic

rather than:

Allow Everything
      ↓
Block Known Bad Traffic

18. Why Default Deny Matters

A default-allow environment can expose the CDE whenever:

New System

New Route

New Application

is introduced.

Default deny reduces this risk.

19. Firewall Rule Example

Good:

Source:
PAY-WEB

Destination:
PAY-API

Port:
443

Purpose:
Payment API

Weak:

Source:
10.0.0.0/8

Destination:
CDE

Port:
ANY

20. Broad Rules

Rules such as:

ANY
      →
ANY

or:

Entire Corporate Network
      →
CDE

should receive strong scrutiny.

21. Build Firewall Rule Review Register

Create:

03 Firewall Rule Review Register

Use:

Rule	Source	Destination	Service	Justification	Status

22. Firewall Rule Review Questions

For every rule ask:

Is It Required?

Is Source Too Broad?

Is Destination Too Broad?

Are Ports Too Broad?

Is It Still Used?

Who Owns It?

When Was It Last Reviewed?

23. Administrative Access

Administrative traffic is one of the highest-risk segmentation paths.

Example:

Administrator
      ↓
MFA
      ↓
Privileged Workstation
      ↓
Jump Host
      ↓
CDE

24. Avoid Direct Administration

Weak model:

Corporate Laptop
      ↓
Direct SSH
      ↓
Payment Server

Stronger model:

Corporate Laptop
      ✗

Privileged Workstation
      ↓
Jump Host
      ↓
Payment Server

25. Jump Host

A jump host creates a controlled administrative boundary.

It may enforce:

MFA

Logging

Source Restrictions

Session Monitoring

Privileged Access

26. Jump Host Security

Because it can access the CDE, protect it with:

Hardening

Patch Management

EDR

Restricted Access

Logging

MFA

27. Privileged Workstation

A dedicated privileged workstation helps reduce attack paths from normal corporate activity.

Avoid using the same endpoint for:

Email

Browsing

Administration

where strong isolation is required.

28. Remote Administrative Access

Remote access may use:

VPN

ZTNA

Privileged Access Gateway

Review:

Authentication

MFA

Device Trust

Source Restrictions

Session Logging

29. Third-Party Remote Access

Example:

Vendor Engineer
      ↓
Remote Access
      ↓
CDE

Controls should include:

Authorization

Time-Limited Access

MFA

Monitoring

Disable When Not Needed

30. CDE Inbound Traffic

Inbound connections should be limited to required services.

Example:

Internet
      ↓
WAF
      ↓
Payment Web

Do not expose:

Database

Management Port

SSH

RDP

directly to the internet unless specifically justified and securely controlled.

31. CDE Outbound Traffic

Outbound communication also requires control.

Examples:

Payment Processor

Security Updates

Logging Platform

Time Synchronization

Avoid unrestricted:

CDE
      →
Internet ANY

32. Egress Filtering

Egress controls can reduce:

Data Exfiltration

Malware Command & Control

Unexpected Connections

33. DNS

If CDE systems depend on enterprise DNS:

CDE
      ↓
DNS

this path should be documented.

34. NTP

Likewise:

CDE
      ↓
NTP

supports accurate logging timestamps.

35. Logging Traffic

Example:

CDE Systems
      ↓
SIEM

Allow only the required logging communication.

36. Vulnerability Scanning Traffic

Example:

Scanner
      ↓
CDE

This may be a deliberate security-services path.

37. Backup Traffic

Example:

CDE Database
      ↓
Backup Platform

The network and storage relationship should be part of segmentation design.

38. Cloud Segmentation

Cloud segmentation may rely on:

VPC / VNet

Subnets

Security Groups

NACLs

Route Tables

Transit Gateways

Private Endpoints

39. Cloud CDE Example

Corporate VPC
      │
      ✗
      │
Transit Firewall
      │
      ▼
Payment VPC
      │
 ┌────┴────┐
 ▼         ▼
App      Database

40. Separate Cloud Accounts

A stronger architecture may use:

Corporate Account

Security Account

Payment Account

instead of placing everything in one account.

41. Account Separation Benefits

It can improve:

IAM Boundaries

Network Boundaries

Logging

Ownership

Scope Management

42. Cloud Security Groups

Treat security groups as firewall-like controls.

Review:

Inbound

Outbound

Source

Destination

Port

Purpose

43. Cloud Rule Example

Weak:

0.0.0.0/0
      →
Database 3306

Strong:

Payment-App-SG
      →
Payment-DB-SG
Port 3306

44. Security Group References

Using:

Security Group
      →
Security Group

can provide tighter control than broad IP ranges.

45. Route Tables

Even if security groups are restrictive, review:

Routing

because unexpected network paths can undermine intended segmentation.

46. VPC Peering

Example:

Corporate VPC
      ↔
CDE VPC

Review:

Routes

Security Groups

DNS

Transitive Access

47. Transit Gateways

Transit architecture can accidentally create broad connectivity.

Example:

Many VPCs
      ↓
Transit Gateway
      ↓
CDE VPC

Use route isolation and explicit controls.

48. Private Endpoints

Private service endpoints can reduce internet exposure.

However, they still represent:

Network Connectivity

and must be included in the architecture.

49. Cloud Management Plane

Network segmentation does not protect the CDE if:

Cloud Administrator
      ↓
Can Modify All Security Groups

Identity and management-plane controls remain essential.

50. Microsegmentation

Microsegmentation creates finer-grained boundaries between workloads.

Example:

Web
      ↓
Only App

App
      ↓
Only Database

rather than broad subnet-level trust.

51. Microsegmentation Technologies

Examples include:

Host Firewalls

Cloud Security Groups

Service Mesh Policies

Software-Defined Networking

Workload Identity Policies

52. East-West Traffic

Traditional perimeter controls focus on:

North-South Traffic

Microsegmentation also controls:

East-West Traffic

between internal workloads.

53. Why East-West Control Matters

If an attacker compromises one application server:

Compromised App
      ↓
Should Not Access
All CDE Systems

54. Kubernetes Segmentation

For Kubernetes CDE workloads, consider:

Namespaces

Network Policies

Ingress

Egress

Service Accounts

Cluster Boundaries

55. Namespace Alone Is Not Strong Segmentation

Weak assumption:

Different Namespace
      =
Network Isolation

Not necessarily.

Use:

NetworkPolicy

or equivalent enforcement.

56. Kubernetes Network Policy

Example:

Payment Frontend
      ↓
Payment API

allowed.

Unrelated Workload
      ↓
Payment Database

blocked.

57. Shared Cluster Risk

If:

Payment Workloads

Development Workloads

share the same cluster, review whether isolation is sufficient.

A dedicated cluster may simplify PCI scope.

58. Container Host Risk

If multiple workloads share:

Worker Nodes

host-level compromise can affect segmentation assumptions.

59. Service Mesh

A service mesh can enforce:

Service-to-Service Identity

Encrypted Traffic

Authorization Policies

but must be correctly configured and tested.

60. Segmentation Documentation

Maintain:

Network Diagram

Zone Description

Communication Matrix

Firewall Rules

Cloud Network Controls

Administrative Paths

Segmentation Test Results

61. Segmentation Testing

Do not rely only on configuration review.

Validate actual isolation.

A practical process:

Identify Out-of-Scope Sources
      ↓
Identify CDE Targets
      ↓
Attempt Connectivity
      ↓
Verify Block
      ↓
Document Result

62. Build Segmentation Test Plan

Create:

04 Segmentation Test Plan

Use:

Source Zone	Target	Port / Protocol	Expected Result	Test Method

63. Test Sources

Test from representative locations such as:

Corporate Workstation

Developer Network

Guest Network

Non-CDE Server

Third-Party Network

64. Test Targets

Targets may include:

Payment Web

Payment API

Database

Admin Interface

Jump Host

65. Positive Test

Sometimes expected communication should succeed.

Example:

Payment Web
      →
Payment API
443

Expected:

Allowed

66. Negative Test

Example:

Corporate Workstation
      →
Payment Database
3306

Expected:

Blocked

67. Administrative Negative Test

Example:

Developer Laptop
      →
Payment Server
SSH

Expected:

Blocked

68. Segmentation Test Evidence

Create:

05 Segmentation Test Evidence Register

Use:

Test ID	Source	Destination	Expected	Actual	Status

69. Evidence Examples

Evidence may include:

Test Output

Firewall Logs

Packet Capture

Cloud Flow Logs

Screenshot

Tool Output

70. Segmentation Penetration Testing

Segmentation testing may be included within PCI penetration-testing requirements where segmentation is relied upon to reduce scope.

The goal is to determine whether:

Out-of-Scope Systems
      ↓
Can Reach
      ↓
CDE

71. Internal vs External Segmentation Testing

Most segmentation validation focuses on internal isolation.

However, external exposure and remote-access paths should also be assessed.

72. Test Frequency

Segmentation testing frequency should follow applicable PCI DSS requirements and the organization’s environment.

Also test after:

Significant Network Change

Firewall Replacement

Cloud Architecture Change

New Peering

New Payment Channel

73. Segmentation Failure Example

Expected:

Developer Network
      ✗
      ↓
CDE SSH

Actual:

Developer Network
      →
CDE SSH
Allowed

Result:

Segmentation Failure

74. Scope Consequence

A segmentation failure may mean:

Developer Network

can no longer be confidently treated as outside PCI scope.

75. Immediate Response to Segmentation Failure

Use:

Identify Path
      ↓
Restrict Connectivity
      ↓
Assess Exposure
      ↓
Re-Test
      ↓
Reassess Scope

76. Segmentation Finding Example

The development subnet can establish SSH sessions to production payment application servers despite being classified as out of scope.

Risk:

Compromise of Development Environment
      ↓
Unauthorized CDE Access

77. Root Cause Example

Problem:

Developer Subnet Reaches CDE

Why?

Firewall Rule Allows
Corporate RFC1918 Range

Why?

Temporary Migration Rule
Never Removed

Root cause:

Firewall-rule lifecycle controls do not ensure temporary CDE access rules expire and are removed.

78. Correction

Remove Broad Firewall Rule

79. Corrective Action

Require Expiry Date

Owner

Approval

Periodic Review

for temporary CDE rules.

80. Segmentation Exception

Sometimes temporary connectivity may be required.

Example:

Migration System
      ↓
Temporary CDE Access

Create:

06 Segmentation Exception Register

Use:

Exception	Source	Destination	Reason	Expiry	Approver

81. Exception Requirements

Include:

Business Need

Risk

Compensating Controls

Owner

Approver

Expiry

Review

82. Avoid Permanent Temporary Rules

Weak:

Temporary Firewall Rule
      ↓
No Expiry
      ↓
3 Years Later
Still Active

83. Firewall Rule Lifecycle

A strong lifecycle:

Request
      ↓
Risk Review
      ↓
Approval
      ↓
Implementation
      ↓
Validation
      ↓
Periodic Review
      ↓
Removal

84. Periodic Firewall Review

Review whether rules remain:

Required

Accurate

Least Privilege

Owned

85. Orphaned Rules

Examples:

Old Application

Decommissioned Server

Former Vendor

Expired Project

Remove unused connectivity.

86. Shadow Connectivity

Potential hidden paths include:

VPN

Peering

Remote Support

Wireless

Direct Connect

Private Link

Transit Gateway

87. Wireless Networks

If wireless exists near CDE systems, evaluate:

Connectivity

Segmentation

Unauthorized Access Points

88. Guest Network

Guest wireless should not have connectivity to the CDE.

Example:

Guest Wi-Fi
      ✗
      ↓
CDE

89. Remote Support Tools

Tools such as remote desktop or support agents can create hidden administrative paths.

Review:

Who Can Activate?

Which Systems?

MFA?

Logging?

Approval?

90. Vendor Connectivity

Third-party connectivity should normally be:

Explicit

Restricted

Monitored

Time-Bound

91. Network Device Management

Firewalls and routers protecting the CDE require secure administration.

Controls include:

Unique IDs

MFA

Restricted Management Networks

Logging

Configuration Backups

92. Configuration Changes

Network changes affecting segmentation should undergo:

Change Request

Risk Review

Approval

Testing

93. Segmentation and Change Management

Every relevant network change should ask:

Could this change alter PCI scope or CDE isolation?

94. New Peering Example

New:

Analytics VPC
      ↔
Payment VPC

should trigger:

PCI Scope Review

Firewall Review

Segmentation Testing

95. New SaaS Connector

A connector running inside the CDE may create:

New Outbound Path

Review:

Destination

Data

Authentication

Business Need

96. Load Balancers

Load balancers may sit at CDE boundaries.

Review:

Listeners

TLS

Backend Targets

Management Access

97. Web Application Firewall

A WAF may protect internet-facing payment applications.

It complements but does not replace internal segmentation.

98. Network IDS / IPS

If used:

CDE Traffic
      ↓
IDS / IPS

ensure monitoring coverage aligns with architecture.

99. Flow Logs

Cloud flow logs can support segmentation monitoring.

Example:

Unexpected Source
      →
CDE

can generate an alert.

100. Continuous Segmentation Monitoring

A mature program may monitor:

New Routes

New Firewall Rules

New Security Groups

New Peerings

Unexpected Connections

101. Configuration Drift

Defined architecture:

Corporate
      ✗
      ↓
CDE

drift:

New Rule Added
      ↓
Corporate
      →
CDE

Automation can detect this.

102. Infrastructure as Code

Manage cloud network controls using:

Terraform

CloudFormation

Bicep

to improve repeatability.

103. Policy-as-Code

Use policies to detect:

0.0.0.0/0 Admin Ports

ANY-to-CDE Rules

Unapproved Peering

Public Databases

104. Scope Reduction Assessment

Create:

07 Scope Reduction Assessment

Document:

Original Scope

Segmentation Architecture

Controls

Testing

Residual Connectivity

Result

105. Example Scope Reduction Assessment

Before:

Corporate Network
+
CDE

After:

Corporate Network
      ✗
      ↓
Segmentation Boundary
      ↓
CDE

Validation:

Segmentation Test Passed

Potential result:

Corporate Environment
Can Be Treated Separately

subject to complete PCI scoping analysis.

106. Segmentation Dashboard

Track:

Metric	Target
Segmentation Tests Passed	100%
Unauthorized CDE Paths	0
Firewall Rules With Owner	100%
Expired Temporary Rules	0
Broad ANY Rules	0
Unreviewed CDE Rules	0

107. Segmentation KPI

Example:

Percentage of CDE firewall rules
reviewed within required cycle

108. Segmentation KRI

Example:

Unauthorized network paths
into the CDE

Target:

109. Broad Rule KRI

Example:

CDE rules using ANY source,
destination, or service
without approved justification

110. Temporary Rule KRI

Example:

Expired temporary firewall rules
still active

111. Segmentation Failure KRI

Example:

Failed PCI segmentation tests

112. Practical Activity — Design CDE Segmentation

Use fictional company:

CloudShop

Create zones:

Internet

DMZ

Payment Application

Payment Database

Admin Zone

Corporate Network

Security Services

Define allowed communication between each.

113. Practical Activity — Build Communication Matrix

Include at least:

Internet → Payment Web

Payment Web → Payment API

Payment API → Payment DB

CDE → SIEM

Scanner → CDE

Admin Zone → CDE

Corporate → CDE

Determine:

Allowed

Blocked

114. Practical Activity — Review Firewall Rules

Assess:

Rule 1
Corporate 10.0.0.0/8
→ CDE
ANY

Rule 2
PAY-WEB-SG
→ PAY-API-SG
443

Rule 3
JUMP-HOST
→ PAY-DB
22

Rule 4
Developer Network
→ Payment API
443

Determine:

Required?

Overly Broad?

Incorrect Port?

Scope Impact?

115. Practical Activity — Build Segmentation Test Plan

Test from:

Corporate

Developer

Guest

Admin

Security Scanner

to:

Web

API

Database

Jump Host

116. Practical Activity — Analyze Failed Test

Test:

Developer Network
      →
Payment Database
5432

Expected:

Blocked

Actual:

Allowed

Document:

Finding

Scope Impact

Root Cause

Correction

Corrective Action

Retest

117. Practical Activity — Cloud Segmentation

Architecture:

Corporate VPC
      ↓
Transit Gateway
      ↓
Payment VPC

Review:

Routes

Security Groups

Firewall Policies

DNS

Private Endpoints

Determine whether corporate workloads can access payment systems.

118. Practical Activity — Kubernetes Segmentation

Payment workloads run in:

Namespace:
payments

Development workloads run in:

Namespace:
dev

There are:

No Network Policies

Question:

Is namespace separation sufficient?

Answer:

No

Design network policies to restrict traffic.

119. Practical Activity — Vendor Access

Vendor requires monthly maintenance access.

Design:

Vendor
      ↓
MFA
      ↓
VPN / ZTNA
      ↓
Jump Host
      ↓
Specific CDE Server

Access should be:

Approved

Time-Bound

Logged

Removed After Use

120. PCI Segmentation Checklist

Architecture

CDE boundary defined.
security zones defined.
network diagram current.
cloud architecture documented.
administrative paths documented.

Communication

communication matrix exists.
every path has business justification.
inbound traffic restricted.
outbound traffic restricted.
security-service traffic documented.

Firewall Controls

default deny implemented.
source restrictions applied.
destination restrictions applied.
port restrictions applied.
broad rules justified.
temporary rules expire.

Administration

direct corporate-to-CDE administration restricted.
privileged access path defined.
jump hosts secured.
MFA enabled.
administrative sessions logged.

Cloud

VPC/VNet boundaries documented.
route tables reviewed.
security groups reviewed.
NACLs reviewed where applicable.
peerings reviewed.
transit routing reviewed.
management plane controlled.

Kubernetes

cluster architecture reviewed.
network policies implemented.
ingress controlled.
egress controlled.
administrative access restricted.

Testing

segmentation test plan documented.
representative source networks tested.
CDE targets tested.
allowed paths validated.
blocked paths validated.
failures recorded.
retesting completed.

Governance

firewall rule owners assigned.
periodic rule review performed.
segmentation exceptions tracked.
network changes trigger PCI review.
scope reduction claims documented.

121. Common Network Segmentation Mistakes

Mistake 1 — Different VLAN Means Segmented

VLANs alone do not guarantee isolation.

Mistake 2 — Firewall Exists, So Segmentation Works

Rules may still allow broad connectivity.

Mistake 3 — Only Inbound Traffic Reviewed

CDE egress is ignored.

Mistake 4 — Administrative Paths Ignored

Corporate endpoints can directly manage CDE systems.

Mistake 5 — Cloud Route Tables Ignored

Unexpected routes bypass intended boundaries.

Mistake 6 — Shared Cloud Account Assumed Safe

IAM or network permissions allow cross-environment access.

Mistake 7 — Kubernetes Namespaces Used as Network Boundary

No NetworkPolicy exists.

Mistake 8 — Temporary Rules Never Removed

Scope increases over time.

Mistake 9 — Segmentation Not Tested

Scope reduction exists only on paper.

Mistake 10 — Changes Do Not Trigger Revalidation

New peering silently breaks segmentation.

122. Weak Segmentation Model

CDE VLAN
      ↓
Declared Segmented

123. Strong Segmentation Model

CDE Boundary
      ↓
Security Zones
      ↓
Default Deny
      ↓
Explicit Communication
      ↓
Controlled Administration
      ↓
Cloud / Network Enforcement
      ↓
Microsegmentation
      ↓
Testing
      ↓
Monitoring
      ↓
Validated Scope Reduction

124. GRC Analyst Responsibilities

A GRC professional supporting PCI network segmentation may:

Maintain segmentation architecture documentation.
Maintain network diagrams.
Maintain CDE communication matrices.
Coordinate firewall rule reviews.
Review rule ownership.
Track temporary network exceptions.
Coordinate segmentation testing.
Review cloud segmentation.
Review administrative access paths.
Review third-party connectivity.
Track segmentation failures.
Coordinate root-cause analysis.
Track remediation and retesting.
Maintain scope-reduction evidence.
Support QSA segmentation reviews.

GRC connects:

Network Engineering

Cloud Security

Security Architecture

IAM

DevOps

Kubernetes Teams

Security Operations

Penetration Testers

Third Parties

Assessors

125. Segmentation Maturity Model

Level 1 — Basic Separation

VLANs

Basic Firewall

Level 2 — Controlled

Zones

Firewall Rules

Communication Matrix

Level 3 — Validated

Segmentation Testing

Rule Reviews

Admin Boundaries

Level 4 — Automated

IaC

Policy-as-Code

Configuration Monitoring

Flow Analysis

Level 5 — Continuous Segmentation Assurance

Continuous Connectivity Testing

Dynamic Policy Enforcement

Automated Drift Detection

Real-Time Scope Alerts

126. Network Segmentation Mindset

For every CDE connection ask:

Why does this path exist?

Who owns it?

Which systems can initiate it?

Which ports are allowed?

Is traffic encrypted?

Could the source be compromised?

Does the source really need CDE access?

Can access be narrower?

Is the rule temporary?

Is the path monitored?

Has the path been tested?

For every out-of-scope network ask:

Can it reach the CDE
in any way?

For every change ask:

Could this route,
rule,
peering,
security group,
or policy
break PCI segmentation?

If these questions can be answered with evidence, the organization can defend its segmentation architecture and associated scope-reduction claims.

Key Takeaways

Network segmentation isolates the CDE from other environments.
Segmentation is often used to reduce PCI DSS scope.
Segmentation must be effective, not merely documented.
Security zones should have clear boundaries and ownership.
Default deny is a strong foundation for CDE network policy.
Communication into and out of the CDE should be explicitly authorized.
Administrative access should use controlled privileged paths.
Jump hosts and privileged workstations can reduce direct exposure.
Cloud segmentation requires review of VPCs, routes, security groups, peerings, and management-plane access.
Microsegmentation can restrict east-west traffic between workloads.
Kubernetes namespaces alone do not provide network isolation.
Segmentation testing is essential when segmentation is relied upon for PCI scope reduction.
Failed segmentation can expand PCI scope.
Firewall-rule lifecycle management is as important as initial rule design.
Temporary exceptions should have owners, approvals, compensating controls, and expiry dates.
Network changes should trigger PCI scope and segmentation review.
Continuous monitoring can identify segmentation drift before assessment time.
GRC coordinates architecture evidence, rule reviews, testing, exceptions, remediation, and assessor discussions.

Knowledge Check

Before continuing, make sure you can answer:

What is network segmentation?
Why is segmentation useful in PCI DSS?
Is segmentation mandatory?
What does default deny mean?
What is a CDE communication matrix?
Why are broad firewall rules risky?
Why should outbound CDE traffic be controlled?
What is a jump host?
Why can privileged workstations help?
How should third-party administrative access be controlled?
What cloud components affect segmentation?
Why can VPC peering create PCI scope risk?
What is microsegmentation?
What is east-west traffic?
Why are Kubernetes namespaces insufficient by themselves?
What is segmentation testing?
Why are negative connectivity tests important?
What happens when a segmentation test fails?
What should a segmentation exception contain?
What role does GRC play in network segmentation assurance?

What’s Next?

➡️ Next: 05 — Access Control

In the next lesson, you will move from network boundaries into controlling who can access the CDE and what they are allowed to do.

You will work through:

Identity
      ↓
Business Need
      ↓
Role
      ↓
Least Privilege
      ↓
Authentication
      ↓
MFA
      ↓
Privileged Access
      ↓
Provisioning
      ↓
Access Review
      ↓
Termination
      ↓
Monitoring

You will also build practical artifacts including a PCI Access Control Matrix, CDE Role Register, Privileged Access Register, User Provisioning Checklist, Termination SLA Tracker, Access Review Register, Service Account Register, MFA Coverage Register, and PCI Access Control Testing Checklist.