03 PCI Scope

Accurate PCI DSS scope is one of the most important foundations of a PCI program.

If scope is wrong, everything that follows can be wrong:

Control Requirements

Evidence Collection

Security Testing

Assessment Coverage

Third-Party Responsibilities

Compliance Status

A strong PCI scoping process answers:

Which systems, people, processes, locations, technologies, and service providers must be considered when applying PCI DSS requirements?

The practical scoping lifecycle looks like:

Payment Channels
      ↓
Cardholder Data Flows
      ↓
CDE
      ↓
Connected Systems
      ↓
Security-Impacting Systems
      ↓
Segmentation Systems
      ↓
People & Processes
      ↓
Third Parties
      ↓
Scope Exclusions
      ↓
Technical Validation
      ↓
PCI Scope Statement

Learning Objectives

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

Explain PCI DSS scope.
Distinguish CDE scope from broader PCI scope.
Classify systems according to PCI relevance.
Identify connected-to systems.
Identify security-impacting systems.
Identify segmentation systems.
Identify administrative systems.
Understand cloud management-plane scope.
Understand CI/CD and software-delivery scope.
Understand third-party dependencies.
Include people and processes in scope.
Determine whether systems can be reasonably excluded.
Understand scope reduction.
Validate segmentation claims.
Identify scope-expansion triggers.
Build a PCI Scope Statement.
Build an In-Scope Asset Register.
Build a Scope Exclusion Register.
Build a Third-Party Responsibility Matrix.
Perform annual PCI scope validation.

1. What Is PCI Scope?

PCI scope defines the environment to which applicable PCI DSS requirements must be considered.

At a high level:

PCI Scope
=
CDE
+
Systems That Can Affect CDE Security
+
Relevant People
+
Relevant Processes
+
Relevant Third Parties

The CDE is central, but it is not always the entire scope.

2. Why Scope Matters

Consider two organizations.

Organization A:

Entire Enterprise Network
Connected to Payment Systems

Organization B:

Dedicated Payment Network
      ↓
Strong Segmentation
      ↓
Limited Admin Access

Organization B may have a much smaller and more manageable PCI scope.

3. Scope Is an Architecture Problem

Weak PCI programs treat scope as:

Compliance Spreadsheet Exercise

Strong programs treat scope as:

Architecture
+
Data Flow
+
Connectivity
+
Access
+
Security Dependencies

4. Start From the CDE

You should already know the main CDE components:

Systems Storing CHD

Systems Processing CHD

Systems Transmitting CHD

These are the starting point.

5. Scope Extends Beyond Direct CHD Systems

Ask:

What Can Connect To the CDE?

What Can Administer the CDE?

What Can Change the CDE?

What Protects the CDE?

What Monitors the CDE?

These questions reveal additional systems.

6. Practical PCI System Categories

For this learning path, use the following classification model:

CDE

Connected-to

Security-Impacting

Segmentation

Third-Party Dependency

Potentially Out of Scope

7. Category 1 — CDE Systems

These directly:

Store

Process

Transmit

applicable cardholder data.

Examples:

Payment Application

Payment Database

Checkout API

Payment Gateway Connector

8. CDE Example

PAY-WEB-01
→ Processes PAN

Classification:

CDE

9. Payment Database Example

PAY-DB-01
→ Stores Encrypted PAN

Classification:

CDE

Encryption does not remove the system from scope.

10. Category 2 — Connected-to Systems

These may not directly process PAN but can connect to CDE systems.

Examples:

Jump Hosts

Admin Networks

Management Servers

Backup Servers

Monitoring Servers

11. Connected-to Example

JUMP-01
      ↓
SSH
      ↓
PAY-APP-01

Classification:

Connected-to

12. Why Connected-to Systems Matter

A compromised connected system may become a path into the CDE.

Example:

Compromised Admin Workstation
      ↓
Jump Host
      ↓
Payment Server

13. Category 3 — Security-Impacting Systems

These provide controls that protect the CDE.

Examples:

Identity Provider

SIEM

EDR Platform

Vulnerability Scanner

Secrets Manager

PKI

NTP

DNS

14. Identity Provider Example

If CDE administrators authenticate through:

Enterprise Identity Provider

then compromise of the identity platform may compromise CDE access.

Classification:

Security-Impacting

15. SIEM Example

If PCI logging requirements depend on:

Central SIEM

then the SIEM is part of the security control chain.

16. Vulnerability Scanner Example

If PCI vulnerability scanning depends on:

Enterprise Vulnerability Scanner

then configuration and access to that platform matter.

17. Secrets Management Example

If payment applications retrieve:

Database Passwords

API Keys

Certificates

from a secrets platform:

Secrets Platform
→ Security-Impacting

18. Category 4 — Segmentation Systems

These enforce boundaries between:

CDE

and:

Non-CDE Environment

Examples:

Firewall

Cloud Security Group

Network ACL

Microsegmentation Platform

ZTNA Policy

19. Segmentation System Example

Corporate Network
      ↓
Firewall
      ↓
CDE

The firewall is a critical PCI-scoping component because the scope-reduction claim depends on it.

20. Why Segmentation Systems Need Attention

If the segmentation control fails:

Out-of-Scope Environment
      ↓
Potentially Becomes In Scope

Therefore segmentation is not just a convenience—it is a scope-control mechanism.

21. Category 5 — Third-Party Dependencies

Third parties may:

Store CHD

Process CHD

Transmit CHD

Provide Security Services

Provide Infrastructure

Examples:

Payment Gateway

Processor

Cloud Provider

Tokenization Provider

Managed Security Provider

22. Provider Scope Example

Merchant Website
      ↓
Payment Gateway
      ↓
Processor

The merchant should document each provider and its responsibility.

23. Category 6 — Potentially Out-of-Scope Systems

A system may be excluded when there is a defensible basis.

Example:

HR SaaS

may be out of scope if it:

Does Not Store CHD

Does Not Connect to CDE

Cannot Affect CDE Security

24. Out-of-Scope Does Not Mean Ignored

You should still document:

Why It Is Out of Scope

because assessors may ask.

25. Build PCI Scope Matrix

Create:

01 PCI Scope Matrix

Use:

System	Classification	CHD Role	Connectivity	Reason

26. Example PCI Scope Matrix

System	Classification	Reason
PAY-WEB-01	CDE	Processes PAN
PAY-DB-01	CDE	Stores PAN
JUMP-01	Connected-to	Admin access to CDE
ENTRA-ID	Security-Impacting	Authenticates CDE admins
FW-CDE-01	Segmentation	Separates CDE
HR-SAAS	Out of Scope	No connectivity or impact

27. Administrative Systems

Administrative access is one of the most important scope paths.

Document:

Administrator
      ↓
Endpoint
      ↓
VPN / ZTNA
      ↓
Jump Host
      ↓
CDE

Every layer should be analyzed.

28. Administrator Endpoint

Ask:

Can this endpoint directly administer CDE systems?

If yes, scope analysis is required.

29. Privileged Access Workstations

Using:

Dedicated Privileged Workstations

can make scope boundaries easier to defend.

Example:

Standard Laptop
      ✗
      ↓
CDE

Privileged Workstation
      ✓
      ↓
CDE

30. VPN Systems

If VPN provides administrative access:

VPN
→ Security-Impacting / Connected-to

depending on architecture.

31. Zero Trust Access Platforms

Likewise:

ZTNA Gateway
      ↓
CDE

may be part of the relevant control environment.

32. Cloud Management Plane

Modern PCI scoping must include cloud-control-plane access.

Example:

AWS Organization
      ↓
Production Account
      ↓
Payment Workloads

Ask:

Who Can Modify IAM?

Who Can Modify Networks?

Who Can Modify Payment Resources?

33. Cloud Root / Management Accounts

A cloud management account may not contain PAN but may be able to:

Create Admin Access

Change Logging

Disable Security Controls

Modify CDE Accounts

This can make it highly security relevant.

34. Cloud IAM

Review:

Federation

Roles

Permission Boundaries

Cross-Account Access

Break-Glass Access

35. Infrastructure as Code

If payment infrastructure is deployed using:

Terraform

CloudFormation

Bicep

then repositories and pipelines may affect CDE security.

36. IaC Pipeline Example

Terraform Repo
      ↓
CI/CD
      ↓
CDE Network

The toolchain can change CDE security controls.

37. CI/CD Scope

Ask:

Can the pipeline deploy to the CDE?

Can it modify infrastructure?

Can it modify payment applications?

If yes, it is security-impacting.

38. Repository Scope

A source repository may be relevant when it controls:

Payment Application Code

Infrastructure Code

Security Configuration

39. Deployment Credentials

If CI/CD uses:

Production Cloud Credentials

then those identities and secret-management processes are highly relevant.

40. Artifact Registries

A container registry can affect CDE security if:

Registry Image
      ↓
Production Payment Workload

41. Kubernetes Environments

If payment workloads run in Kubernetes:

Cluster

Control Plane

Worker Nodes

Ingress

Secrets

RBAC

must be considered.

42. Kubernetes Administration

Users with:

Cluster Admin

can affect payment workloads even if they never access PAN directly.

43. Shared Kubernetes Cluster

Suppose:

Payment Workloads

Non-Payment Workloads

share one cluster.

This may create scope complexity.

Strong isolation needs to be demonstrated rather than assumed.

44. Shared Cloud Account

Likewise:

Payment Resources

Corporate Resources

within one cloud account may expand the relevant environment.

Dedicated accounts can simplify scope.

45. Shared Identity Platform

Many organizations use one enterprise identity service across:

Corporate Systems

CDE Systems

That identity service may be part of PCI security scope even if most applications are non-PCI.

46. Monitoring Platforms

If the same SIEM monitors:

Enterprise

CDE

the SIEM may be relevant, but that does not necessarily mean every monitored system is in PCI scope.

Scope should be reasoned carefully.

47. Backup Scope

If backup contains:

Encrypted PAN

the backup environment is relevant.

Ask:

Where Are Backups Stored?

Who Can Restore Them?

Who Can Access Keys?

Which Region?

48. DR Scope

If payment systems replicate to:

Disaster Recovery Region

the DR environment is part of the payment architecture.

49. Security Operations

People and systems supporting:

Monitoring

Incident Response

Log Review

Vulnerability Management

can be part of the PCI control environment.

50. Service Desk

If the service desk can:

Reset CDE Admin Credentials

or:

Provision CDE Access

its processes may affect CDE security.

51. HR

HR systems may be out of technical PCI scope, but HR processes may support controls such as:

Termination

Background Checks

Security Awareness

PCI scope includes processes, not only systems.

52. People in Scope

Identify:

CDE Users

CDE Administrators

Security Operators

Developers

Support Staff

Third-Party Administrators

53. People Scope Register

Create:

02 PCI In-Scope Role Register

Use:

Role	CHD Access	CDE Admin	Security Impact	Owner

54. Developer Scope

A developer may have:

No Production Login

but can:

Commit Code
      ↓
Payment Application

Their development process can still affect payment security.

55. Support Scope

Support personnel may enter scope if they:

View PAN

Handle Payment Calls

Access CDE Applications

56. Vendor Personnel

Third-party administrators may:

Manage Payment Infrastructure

Support Payment Applications

Their access should be documented.

57. Processes in Scope

Include processes such as:

Payment Processing

Refunds

Access Management

Change Management

Incident Response

Vulnerability Management

Backup

Security Monitoring

Vendor Management

58. Build Process Register

Create:

03 PCI In-Scope Process Register

Use:

Process	PCI Relevance	Owner	Systems

59. Payment Data Flow Scope

For each data flow ask:

Source?

Destination?

Data?

Protocol?

Provider?

Storage?

60. Cross-Border Data Flow

If payment data moves:

Region A
      ↓
Region B

document:

Why

How

Which Provider

Which Systems

61. Scope Reduction

Scope reduction aims to minimize unnecessary exposure.

Common approaches:

Segmentation

Tokenization

Hosted Payment Pages

Data Elimination

Dedicated Systems

Privileged Access Zones

62. Scope Reduction Principle

The best scope reduction strategy is often:

Do Not Handle PAN
Unless Necessary

63. Hosted Payment Provider

Example:

Customer
      ↓
Provider Payment Page
      ↓
Merchant Receives Token

This may significantly reduce merchant exposure.

64. Token-Only Systems

If a system uses tokens:

Token
≠
Automatically Out of Scope

Assess whether the token can be converted back to PAN and whether the system can affect the tokenization process.

65. PAN Elimination

Example:

Support Platform Contains PAN

Remediation:

Remove PAN

Implement Filtering

Train Users

Monitor Future Entries

Potential result:

Reduced Scope

after validation.

66. Segmentation-Based Scope Reduction

Example:

Corporate Network
      ↓
Firewall
      ↓
CDE

For the corporate network to be treated separately, segmentation must be effective.

67. Segmentation Validation

Validate through:

Configuration Review

Firewall Rule Review

Penetration Testing

Connectivity Testing

68. Segmentation Test Example

Attempt:

Corporate Workstation
      ↓
CDE Database

Expected:

No Connectivity

69. Segmentation Failure

Actual:

TCP/1433 Reachable

Result:

Segmentation Failure

Potential consequence:

Scope Expansion

70. Scope Expansion

Scope expands when:

Unexpected Connectivity

Unexpected PAN Storage

New Provider

New Payment Channel

Security Dependency Added

71. Example — New Log Platform

Payment application logs are sent to:

New Analytics Platform

If logs contain PAN:

Analytics Platform
→ Potentially In Scope

72. Example — New AI Provider

Support ticket containing PAN is sent to:

AI Provider

Now review:

Data Flow

Provider PCI Status

Retention

Security

Scope

73. Example — New SaaS Admin Platform

A SaaS identity platform now controls CDE administrator accounts.

It may become:

Security-Impacting

74. Example — New Network Peering

A new VPC peering connection links:

Corporate VPC

to:

CDE VPC

Scope must be reassessed.

75. Significant Change Triggers

Define triggers such as:

New Payment Application

New Provider

New Cloud Account

New Region

New Network Connection

New CI/CD Platform

New Authentication Platform

Acquisition

76. Build Scope Change Trigger Register

Create:

04 PCI Scope Change Trigger Register

Use:

Change	PCI Review Required	Owner

77. Scope Exclusion

An exclusion should be documented rather than assumed.

Create:

05 PCI Scope Exclusion Register

Use:

System	Exclusion Reason	Validation	Owner

78. Strong Exclusion Example

System:

HR-SaaS

Reason:

Does Not Process CHD

No CDE Connectivity

No Security Dependency

Validation:

Architecture Review
+
Connectivity Review

79. Weak Exclusion Example

This system belongs to HR, so it is out of scope.

Business ownership alone does not determine scope.

80. Scope Statement

A formal scope statement explains:

What Is Included

What Is Excluded

Why

Which Locations

Which Providers

Which Payment Channels

81. Build PCI Scope Statement

Create:

06 PCI Scope Statement

Recommended sections:

Organization

Assessment Period

Payment Channels

CDE

Connected Systems

Security-Impacting Systems

Segmentation

Third Parties

People

Processes

Exclusions

Assumptions

82. Example Scope Statement

The PCI DSS scope includes the e-commerce payment environment supporting the production checkout service, associated payment APIs, payment database, administrative jump hosts, identity services supporting CDE authentication, central security logging, vulnerability scanning, backup infrastructure, and network segmentation controls.

83. Scope Statement Exclusion Example

Corporate HR and collaboration SaaS platforms are excluded because they do not store, process, or transmit account data, do not have connectivity to the CDE, and do not provide security services upon which the CDE depends.

84. Network Scope Map

Create:

07 PCI Network Scope Map

Example:

                   Internet
                      │
                      ▼
                WAF / Firewall
                      │
                      ▼
                Payment Web
                      │
              ┌───────┴───────┐
              ▼               ▼
          Payment API      Payment DB
              │
              ▼
        Payment Processor


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

85. In-Scope Asset Register

Create:

08 PCI In-Scope Asset Register

Use:

Asset	Classification	Owner	Environment	Reason

86. Recommended Asset Fields

Include:

Hostname / Resource ID

Cloud Account

Environment

IP / Network

Owner

Data Role

Classification

87. Third-Party Scope Register

Create:

09 PCI Third-Party Scope Register

Use:

Provider	Service	CHD Role	PCI Relevance	Assurance

88. Provider Responsibility Matrix

Create:

10 PCI Third-Party Responsibility Matrix

Use:

Requirement Area	Organization	Provider	Shared

89. Example Responsibility Mapping

Control	Merchant	Cloud Provider
Physical Data Center Security	—	✓
Cloud IAM	✓	—
Network Security Groups	✓	Shared
Hypervisor Security	—	✓

90. Do Not Confuse Provider Compliance With Your Compliance

Cloud provider:

PCI DSS Validated

does not mean:

Customer Workload
=
PCI Compliant

Customer responsibilities remain.

91. Provider AOC Review

For critical providers review:

Provider Name

Service

Assessment Period

Service Scope

Compliance Status

92. Shared Responsibility Documentation

Especially in cloud:

Provider
      +
Customer
      =
Complete Control

Missing either side can create a gap.

93. Scope Validation Interviews

Interview:

Payment Product Owner

Network Team

Cloud Team

Application Team

Security

Finance

Support

Procurement

94. Why Interviews Matter

A diagram may say:

No PAN in Support

while support staff say:

Customers regularly send card numbers in tickets.

That discrepancy must be investigated.

95. Technical Validation

Use technical sources such as:

Network Rules

Cloud Inventories

IAM Policies

Routing Tables

Asset Inventory

Data Discovery

Code Repositories

96. Scope Assumption Validation

For every assumption ask:

What Evidence Supports It?

Example:

Assumption:

Corporate Network Cannot Reach CDE

Evidence:

Firewall Configuration

Segmentation Test

97. Scope Findings

A scope finding should identify:

Condition

Impact

Affected System

Reason

Required Action

98. Finding — Undocumented Database

A secondary reporting database contains truncated and full PAN values but is absent from the PCI asset inventory.

Potential outcome:

PCI Scope Expansion

99. Finding — Identity Dependency

The identity provider authenticating payment administrators is not classified as a PCI security-impacting system.

100. Finding — Developer Pipeline

The deployment pipeline can modify the production payment application but is classified as out of scope.

101. Finding — Segmentation

The corporate network can access CDE management interfaces over SSH.

102. Finding — Third Party

A fraud analytics provider receives full PAN but is not listed in the PCI service-provider inventory.

103. Finding — Backup

Payment database backups containing encrypted PAN are stored in an account omitted from PCI scope.

104. Scope Gap Register

Create:

11 PCI Scope Gap Register

Use:

Gap ID	Issue	Scope Impact	Severity	Owner

105. Root Cause Categories

Common causes:

Architecture Change

Incomplete Discovery

Documentation Gap

Ownership Gap

Third-Party Change

Weak Change Management

106. Root Cause Example

Problem:

Analytics Platform
Unexpectedly Receives PAN

Why?

Application Logs Include PAN

Why?

Logging Standard Does Not Filter Payment Data

Root cause:

Payment-data handling requirements are not integrated into application logging standards.

107. Correction

Stop PAN Logging

108. Corrective Action

Implement PAN Filtering

Update Secure Development Standard

Add Automated Testing

Monitor Logs

109. Annual Scope Validation

PCI scope should not remain static.

Perform formal validation regularly and after significant changes.

A practical annual workflow:

Review Payment Channels
      ↓
Review Data Flows
      ↓
Review CDE
      ↓
Review Connectivity
      ↓
Review Security Dependencies
      ↓
Review People / Processes
      ↓
Review Providers
      ↓
Test Segmentation
      ↓
Confirm Exclusions
      ↓
Approve Scope

110. Build Annual PCI Scope Validation Package

Create:

12 Annual PCI Scope Validation Package

Include:

Scope Statement

Payment Channel Register

Cardholder Data Flow

Network Diagram

CDE Asset Inventory

System Classification Matrix

Role Register

Process Register

Provider Register

Segmentation Results

Scope Exclusions

Management Approval

111. Scope Validation Owner

Recommended accountability:

PCI Program Owner

supported by:

GRC

Security

Network

Cloud

Payments

Engineering

112. Management Approval

The finalized scope should be formally reviewed.

Record:

Scope Version

Approval Date

Approver

Assessment Period

113. PCI Scope Dashboard

Track:

Metric	Target
In-Scope Assets With Owner	100%
Payment Channels Documented	100%
Third Parties Documented	100%
Segmentation Tests Passed	100%
Unapproved CHD Locations	0
Unknown CDE Connections	0
Scope Changes Awaiting Review	0

114. PCI Scope KPI

Example:

Percentage of in-scope PCI assets
with validated classification

Target:

100%

115. PCI Scope KRI

Example:

Number of unknown systems
with CDE connectivity

Target:

116. PCI Scope Change KRI

Example:

Significant infrastructure changes
implemented without PCI scope assessment

117. Segmentation KRI

Example:

Failed segmentation test paths

Target:

118. Provider Scope KRI

Example:

Third parties handling CHD
without current PCI assurance

119. Practical Activity — Classify 20 Systems

Use fictional organization:

CloudShop

Classify:

Payment Web Server

Payment API

Payment Database

Tokenization Service

Corporate Laptop

Privileged Workstation

Jump Host

Identity Provider

SIEM

Vulnerability Scanner

CI/CD

Git Repository

Container Registry

Cloud Management Account

Backup Account

DR Environment

Support Platform

HR SaaS

Payment Gateway

Cloud Provider

Use:

CDE

Connected-to

Security-Impacting

Segmentation

Third-Party

Potentially Out of Scope

120. Practical Activity — Build Scope Statement

Create a formal scope statement for CloudShop covering:

E-Commerce Payments

AWS

External Payment Processor

Central IAM

CI/CD

Security Monitoring

121. Practical Activity — Build Scope Exclusion Register

Add:

HR SaaS

Marketing Platform

Internal Wiki

Corporate Training Platform

For each provide:

Reason

Validation Evidence

122. Practical Activity — Analyze Shared Services

Assess whether these enterprise systems affect CDE security:

Entra ID

SIEM

Vulnerability Scanner

Secrets Manager

DNS

NTP

Document the rationale.

123. Practical Activity — Analyze Segmentation

Architecture:

Corporate VPC
      ↓
Transit Gateway
      ↓
CDE VPC

Rules currently allow:

Corporate Admin Subnet
→ CDE HTTPS

Corporate Developer Subnet
→ CDE SSH

Determine which connection is legitimate and whether the developer subnet threatens scope reduction.

124. Practical Activity — Assess New CI/CD Platform

A new deployment platform can:

Push Containers

Update Kubernetes Deployments

Modify Infrastructure

for the payment service.

Determine:

PCI Classification

Required Controls

Scope Impact

125. Practical Activity — Scope Change Review

A new fraud provider receives:

PAN

Transaction Amount

Customer Identifier

Document:

Data Flow Change

Provider Scope

Responsibility

Assurance Required

Scope Statement Update

126. PCI Scope Validation Checklist

Payment Channels

All channels documented.
owners confirmed.
payment integrations confirmed.
providers confirmed.

Data

PAN flows documented.
CHD storage documented.
SAD handling reviewed.
unexpected CHD searched for.

CDE

storage systems identified.
processing systems identified.
transmission systems identified.
backup and DR included.

Connectivity

connected systems identified.
management paths identified.
remote access paths identified.
cloud connectivity reviewed.

Security Dependencies

IAM reviewed.
SIEM reviewed.
vulnerability scanning reviewed.
secrets management reviewed.
PKI reviewed.
CI/CD reviewed.

Segmentation

segmentation architecture documented.
rules reviewed.
connectivity technically validated.
segmentation testing passed.
failures remediated.

People

CHD users identified.
CDE admins identified.
developers considered.
support personnel considered.
vendor administrators considered.

Processes

payment processing included.
refunds included.
access management included.
change management included.
incident response included.
vendor governance included.

Third Parties

payment providers documented.
cloud providers documented.
outsourced services documented.
responsibilities mapped.
assurance current.

Exclusions

exclusion rationale documented.
connectivity validated.
no CHD confirmed.
security dependency ruled out.

Governance

scope statement current.
scope owner identified.
significant-change triggers defined.
annual validation completed.
management approval recorded.

127. Common PCI Scope Mistakes

Mistake 1 — CDE Equals Full PCI Scope

Connected and security-impacting systems are missed.

Mistake 2 — Department Ownership Determines Scope

Technical relationships matter more.

Mistake 3 — Cloud Provider Compliance Used as Proof of Customer Compliance

Shared responsibility is ignored.

Mistake 4 — CI/CD Ignored

Deployment tools can alter payment applications.

Mistake 5 — IAM Ignored

Identity services can control CDE authentication.

Mistake 6 — Shared Services Automatically Pull Entire Enterprise Into Scope

Scope must be analyzed carefully rather than assumed either way.

Mistake 7 — Segmentation Based on Diagram Only

Actual connectivity is never tested.

Mistake 8 — Scope Exclusions Not Documented

Out-of-scope status becomes difficult to defend.

Mistake 9 — New Providers Added Without PCI Review

Data flows change silently.

Mistake 10 — Scope Updated Only Before Assessment

Continuous architectural changes are missed.

128. Weak PCI Scope Model

Payment Database
      ↓
PCI Scope

129. Strong PCI Scope Model

Payment Channels
      ↓
CHD Flow
      ↓
CDE
      ↓
Connected Systems
      ↓
Security Dependencies
      ↓
Administrative Paths
      ↓
Segmentation Controls
      ↓
People
      ↓
Processes
      ↓
Providers
      ↓
Validated Exclusions
      ↓
Defensible PCI Scope

130. GRC Analyst Responsibilities

A GRC professional supporting PCI scope management may:

Maintain the PCI scope statement.
Coordinate payment-channel inventories.
Maintain CDE asset inventories.
Classify connected systems.
Identify security-impacting services.
Review administrative paths.
Coordinate cloud-control-plane scoping.
Review CI/CD dependencies.
Maintain scope exclusions.
Coordinate segmentation testing.
Review provider PCI assurance.
Maintain responsibility matrices.
Coordinate annual scope validation.
review significant changes.
document scope gaps.
coordinate remediation.
support QSA scope discussions.

GRC connects:

Payments

Security

Network

Cloud

IAM

Engineering

DevOps

Security Operations

Support

Procurement

Third Parties

Assessors

131. PCI Scope Maturity Model

Level 1 — Assumed

Payment Systems
=
Scope

Level 2 — Documented

Assets

Data Flows

Network Diagrams

Level 3 — Validated

Connectivity Testing

Provider Review

Segmentation Testing

Level 4 — Integrated

CMDB

Cloud Inventory

Change Management

Automated Discovery

Level 5 — Continuous Scope Assurance

Continuous Asset Discovery

Continuous Connectivity Analysis

Continuous CHD Discovery

Automated Scope Change Alerts

132. PCI Scope Mindset

For every system ask:

Does it store CHD?

Does it process CHD?

Does it transmit CHD?

Can it connect to CDE systems?

Can it administer CDE systems?

Can it modify CDE applications?

Can it modify CDE infrastructure?

Does the CDE depend on it for authentication?

Does the CDE depend on it for monitoring?

Does it enforce segmentation?

Does it store CDE backups?

Can it access cryptographic keys?

Does a third party operate it?

If we say it is out of scope,
what evidence proves that?

For every change ask:

Could this change expand PCI scope?

If these questions can be answered with evidence, the PCI scope becomes defensible and manageable.

Key Takeaways

PCI scope is broader than systems that directly store PAN.
The CDE remains the starting point for scope analysis.
Connected-to systems can create attack paths into the CDE.
Security-impacting systems may support IAM, monitoring, vulnerability management, secrets, PKI, and other critical controls.
Segmentation systems are central to scope reduction.
Cloud control planes and shared cloud-management services can affect PCI scope.
CI/CD, source repositories, IaC platforms, registries, and Kubernetes management can affect CDE security.
People and processes are part of PCI scope.
Third-party payment and infrastructure providers should be mapped to responsibilities and assurance.
Scope exclusions require evidence and rationale.
Segmentation should be technically validated rather than assumed.
Significant changes should trigger PCI scope review.
A formal scope statement, asset register, provider register, exclusion register, and segmentation evidence create a defensible scope package.
PCI scope validation should operate continuously and be formally reviewed on a recurring basis.
GRC coordinates architecture, payment flows, technical teams, third parties, evidence, and assessors to maintain accurate scope.

Knowledge Check

Before continuing, make sure you can answer:

What is PCI DSS scope?
How is PCI scope broader than the CDE?
What is a connected-to system?
What is a security-impacting system?
What is a segmentation system?
Why can an identity platform affect PCI scope?
Why can CI/CD affect PCI scope?
Why can cloud management accounts affect PCI scope?
How can backup and DR environments affect scope?
How are people included in PCI scope?
How are processes included in PCI scope?
What is scope reduction?
Why does tokenization not automatically eliminate PCI scope?
Why must segmentation be tested?
What happens when segmentation fails?
What is a PCI Scope Statement?
What should a Scope Exclusion Register contain?
Why should third-party responsibilities be documented?
What events should trigger PCI scope reassessment?
What role does GRC play in PCI scope management?

What’s Next?

➡️ Next: 04 — Network Segmentation

In the next lesson, you will focus specifically on using architecture and network-security controls to isolate the Cardholder Data Environment from the rest of the enterprise.

You will work through:

CDE Boundary
      ↓
Network Zones
      ↓
Firewall Policy
      ↓
Allowed Communication
      ↓
Default Deny
      ↓
Administrative Paths
      ↓
Cloud Segmentation
      ↓
Microsegmentation
      ↓
Segmentation Testing
      ↓
Scope Reduction

You will also build practical artifacts including a PCI Network Segmentation Design, CDE Communication Matrix, Firewall Rule Review Register, Segmentation Test Plan, Segmentation Test Evidence Register, Scope Reduction Assessment, and Segmentation Exception Register.