01 Introduction to PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard designed to protect payment account data and reduce the risk of payment-card compromise.

Organizations that:

Store

Process

Transmit

payment account data may have PCI DSS responsibilities.

PCI DSS is used across industries such as:

Retail

E-Commerce

Financial Services

Hospitality

Healthcare

Transportation

SaaS

Payment Processing

Cloud Services

The core idea is straightforward:

If your organization handles payment-card information, you must understand where that information flows, protect the systems involved, control access, monitor activity, test security, and maintain an ongoing security program.

A simplified PCI compliance lifecycle looks like:

Payment Card Data
      ↓
Identify Data Flow
      ↓
Determine PCI Scope
      ↓
Identify CDE
      ↓
Apply PCI Requirements
      ↓
Collect Evidence
      ↓
Test Controls
      ↓
Remediate Gaps
      ↓
Validate Compliance
      ↓
Maintain Continuous Compliance

Learning Objectives

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

Explain why PCI DSS exists.
Understand the payment-card ecosystem.
Identify organizations that may be subject to PCI DSS.
Understand payment account data.
Distinguish Cardholder Data from Sensitive Authentication Data.
Explain the Cardholder Data Environment.
Understand PCI DSS scope at a high level.
Explain merchant and service-provider responsibilities.
Understand the twelve PCI DSS requirement areas.
Understand PCI DSS v4.x objectives.
Explain the Customized Approach concept.
Understand merchant compliance levels.
Understand common PCI validation methods.
Explain SAQ, ROC, AOC, and ASV concepts.
Understand the roles of QSAs and Internal Security Assessors.
Understand service-provider dependencies.
Understand PCI evidence expectations.
Explain why PCI DSS is continuous rather than annual-only compliance.
Understand the role of GRC professionals in PCI programs.

1. Why PCI DSS Exists

Payment-card information is valuable to attackers.

Compromised payment data can be used for:

Fraud

Unauthorized Purchases

Account Takeover

Card Cloning

Identity-Related Fraud

Large payment-card compromises historically demonstrated that organizations needed consistent minimum security expectations.

PCI DSS was created to establish those expectations.

2. The PCI Security Standards Council

PCI DSS is managed by the:

PCI Security Standards Council

often abbreviated:

PCI SSC

The council was founded by major payment-card brands.

PCI SSC develops and maintains standards and supporting programs for payment security.

3. PCI DSS v4.x

Your learning path is structured as:

PCI DSS v4.0

The current v4.x generation also includes the v4.0.1 maintenance revision, which clarified and corrected parts of v4.0 without fundamentally changing its overall security objectives.

For this learning path, think of the curriculum as covering:

PCI DSS v4.x

with the control architecture introduced by v4.0.

4. PCI DSS Is a Security Standard

PCI DSS defines security requirements for protecting payment account data.

It addresses areas such as:

Network Security

Secure Configuration

Data Protection

Encryption

Vulnerability Management

Access Control

Authentication

Physical Security

Logging

Security Testing

Policies

Governance

5. PCI DSS Is Not Just a Technical Standard

A common mistake is thinking PCI DSS belongs only to:

Network Engineers

Security Engineers

PCI DSS also involves:

Management

GRC

Application Teams

Developers

Infrastructure

IAM

Security Operations

HR

Legal

Procurement

Internal Audit

Third-Party Risk

6. Who May Need PCI DSS?

PCI DSS can be relevant to organizations involved in payment-card processing.

Examples include:

Merchants

Payment Processors

Payment Gateways

Acquirers

Issuers

Service Providers

Hosting Providers

Cloud Providers

The exact validation requirements depend on the organization’s role and payment-brand or acquiring-bank requirements.

7. Merchant

A merchant is generally an organization accepting payment cards for goods or services.

Examples:

Retail Store

E-Commerce Website

Hotel

Airline

Subscription Platform

8. Service Provider

A service provider may store, process, transmit, or otherwise affect the security of payment account data on behalf of another organization.

Examples:

Payment Processor

Managed Service Provider

Hosting Provider

Cloud Service Provider

Payment Gateway

9. Payment Ecosystem

A simplified card-payment transaction may look like:

Cardholder
      ↓
Merchant
      ↓
Payment Gateway
      ↓
Acquirer
      ↓
Card Network
      ↓
Issuer

Each participant has different responsibilities.

10. Cardholder

The cardholder is the individual authorized to use the payment card.

Example:

Customer
      ↓
Uses Card
      ↓
Purchases Product

11. Merchant

The merchant accepts the payment.

Example:

Online Store
      ↓
Checkout
      ↓
Payment Information

12. Payment Gateway

A payment gateway facilitates secure transmission of payment transactions.

Conceptually:

Merchant
      ↓
Gateway
      ↓
Payment Processor

13. Acquirer

The acquiring financial institution supports the merchant’s card-payment processing relationship.

14. Issuer

The issuer provides the payment card or payment account to the customer.

15. Payment Brand

Examples include major card-payment brands and networks.

These organizations establish payment ecosystem rules and compliance programs.

16. Account Data

PCI DSS focuses on protecting account data.

At a high level, account data includes:

Cardholder Data
+
Sensitive Authentication Data

Understanding this distinction is foundational to PCI scoping.

17. Cardholder Data

Cardholder Data is commonly abbreviated:

CHD

The central element is the:

Primary Account Number

or:

PAN

18. Primary Account Number

The PAN is the payment-card account number associated with the card.

Conceptually:

Cardholder
      ↓
Payment Card
      ↓
PAN

The PAN is a critical element for PCI DSS protection.

19. Additional Cardholder Data

When associated with the PAN, cardholder data can also include information such as:

Cardholder Name

Expiration Date

Service Code

20. Sensitive Authentication Data

Sensitive Authentication Data is commonly abbreviated:

SAD

It is information used during authentication or authorization of payment transactions.

Examples include certain:

Full Track Data

Card Verification Values

PIN / PIN Blocks

21. Why SAD Requires Special Protection

Sensitive authentication data presents significant fraud risk.

A critical principle is:

Sensitive Authentication Data
after authorization
→ Must not be stored

even when encrypted, except where specific payment ecosystem requirements allow particular issuer-related handling.

For most merchants:

Do Not Store SAD
After Authorization

22. Card Verification Code

Depending on card brand, the verification value may be known by terms such as:

CVV

CVC

CID

This value is used to help authenticate card-not-present transactions.

It is Sensitive Authentication Data.

23. PCI Data Classification Example

A useful conceptual model:

Data	PCI Classification
PAN	Cardholder Data
Cardholder Name with PAN	Cardholder Data
Expiration Date with PAN	Cardholder Data
Security Code	Sensitive Authentication Data
PIN	Sensitive Authentication Data

24. Masking Is Not the Same as Encryption

A displayed card number may appear as:

**** **** **** 1234

This is:

Masking

It reduces displayed PAN exposure.

Encryption is different.

25. Encryption

Encryption protects data cryptographically.

Conceptually:

PAN
      ↓
Encryption
      ↓
Ciphertext

Authorized systems may decrypt it using protected cryptographic keys.

26. Truncation

Truncation permanently removes part of the PAN representation.

This differs from masking, which controls display.

27. Tokenization

Organizations may replace PAN with a substitute value.

Example:

4111 1111 1111 1111
      ↓
Tokenization
      ↓
TOKEN-8D31A7

Tokenization can reduce risk and potentially help reduce PCI scope when properly implemented.

28. PCI Scope

One of the most important PCI concepts is:

Scope

PCI scope answers:

Which people, processes, technologies, and system components must be considered when applying PCI DSS?

29. Scope Is Not Just the Payment Database

Weak thinking:

Database Has PAN
      ↓
Only Database Is PCI Scope

This is usually incorrect.

Other systems may:

Connect To

Process

Transmit

Secure

Administer

Impact

the payment environment.

30. Cardholder Data Environment

The Cardholder Data Environment is commonly abbreviated:

CDE

At a high level, it contains:

People

Processes

Technologies

that store, process, or transmit cardholder data or sensitive authentication data.

31. Basic CDE Example

Internet
      ↓
Payment Application
      ↓
Payment Database
      ↓
Payment Processor

These components may form part of the CDE.

32. Connected Systems

PCI scope may extend beyond systems directly storing CHD.

Example:

Corporate Network
      ↓
Management Server
      ↓
CDE Server

If the management server can affect CDE security, it may be relevant to scope.

33. Security-Impacting Systems

Examples may include:

Identity Systems

Security Monitoring

Jump Hosts

Vulnerability Scanners

Patch Systems

DNS

Authentication Infrastructure

depending on architecture and connectivity.

34. Why Scope Matters

PCI compliance effort often depends heavily on scope.

Larger scope means:

More Systems

More Controls

More Evidence

More Testing

More Cost

More Risk

35. Scope Reduction

Organizations commonly attempt to reduce PCI scope through secure architectural design.

Possible techniques include:

Network Segmentation

Tokenization

Hosted Payment Pages

Payment Provider Outsourcing

Strong Access Boundaries

36. Outsourcing Payment Processing

Example:

Customer
      ↓
Merchant Website
      ↓
Hosted Payment Provider

This may significantly change the merchant’s PCI environment.

However:

Outsource Processing
≠
Automatically Zero PCI Responsibility

37. Third-Party Providers

If payment processing is outsourced, organizations should still understand:

Which Provider?

Which Service?

Which PCI Responsibility?

Which Controls Remain Ours?

38. Shared Responsibility

A useful model:

Merchant Responsibilities
      +
Service Provider Responsibilities
      =
Complete PCI Control Environment

39. Cloud Does Not Automatically Remove PCI Scope

Example:

Payment Application
      ↓
AWS

The fact that infrastructure is cloud-hosted does not remove organizational responsibility.

You must understand:

Cloud Provider Controls

Customer Configuration

IAM

Network Security

Logging

Encryption

40. PCI DSS Security Objectives

PCI DSS v4.x organizes its twelve requirements under six broad goals.

Conceptually:

Build & Maintain
Secure Networks and Systems

Protect Account Data

Maintain a
Vulnerability Management Program

Implement Strong
Access Control Measures

Regularly Monitor
and Test Networks

Maintain an
Information Security Policy

41. Requirement 1

Install and Maintain Network Security Controls

This includes governance of network traffic and security boundaries.

Examples:

Firewalls

Cloud Security Groups

Network ACLs

Segmentation Controls

42. Requirement 2

Apply Secure Configurations to All System Components

This focuses on secure configuration.

Examples:

Secure Baselines

Default Password Removal

Unnecessary Services Disabled

Configuration Standards

43. Requirement 3

Protect Stored Account Data

This includes:

Data Retention

PAN Protection

Encryption

Key Management

Masking

44. Requirement 4

Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Examples:

TLS

Secure APIs

Encrypted Connections

45. Requirement 5

Protect All Systems and Networks from Malicious Software

This includes malware-related prevention and detection controls.

46. Requirement 6

Develop and Maintain Secure Systems and Software

Areas include:

Vulnerability Remediation

Secure Development

Change Management

Application Security

Software Security

47. Requirement 7

Restrict Access to System Components and Cardholder Data by Business Need to Know

Principles:

Least Privilege

Need to Know

Role-Based Access

48. Requirement 8

Identify Users and Authenticate Access to System Components

Areas include:

Unique IDs

Authentication

MFA

Credential Management

49. Requirement 9

Restrict Physical Access to Cardholder Data

Examples:

Data Center Access

Visitors

Media Protection

Physical Records

50. Requirement 10

Log and Monitor All Access to System Components and Cardholder Data

This addresses:

Audit Logging

Security Monitoring

Log Review

Retention

Time Synchronization

51. Requirement 11

Test Security of Systems and Networks Regularly

Examples include:

Vulnerability Scanning

External Scanning

Penetration Testing

Segmentation Testing

Wireless Testing

52. Requirement 12

Support Information Security with Organizational Policies and Programs

This includes:

Security Policies

Risk Assessments

Roles

Security Awareness

Incident Response

Third-Party Governance

53. Twelve-Requirement Model

The complete structure:

01 Network Security Controls

02 Secure Configurations

03 Stored Account Data

04 Transmission Encryption

05 Malware Protection

06 Secure Systems & Software

07 Access Authorization

08 Authentication

09 Physical Security

10 Logging & Monitoring

11 Security Testing

12 Security Governance

54. PCI DSS v4.x Design Philosophy

The v4.x generation emphasizes:

Security as Continuous Process

Flexible Security Implementation

Improved Validation

Strong Authentication

Modern Technology

Risk-Based Implementation

55. Defined Approach

The traditional method of implementing PCI requirements is commonly called the:

Defined Approach

Organizations implement the control requirements described by PCI DSS.

56. Customized Approach

PCI DSS v4.x also introduced broader support for a:

Customized Approach

for eligible requirements.

The organization defines an alternative control implementation that achieves the intended security objective.

57. Customized Does Not Mean Easier

Weak thinking:

We Don't Like the Requirement
      ↓
Use Customized Approach

Incorrect.

Customized implementations require rigorous:

Control Design

Risk Analysis

Testing

Documentation

Validation

58. Customized Approach Mindset

PCI Security Objective
      ↓
Alternative Control
      ↓
Targeted Risk Analysis
      ↓
Testing Method
      ↓
Evidence
      ↓
Assessor Validation

59. Targeted Risk Analysis

PCI DSS v4.x uses targeted risk analysis in several contexts.

A targeted risk analysis may help determine things such as:

Control Frequency

Risk-Based Decisions

Customized Approach Design

where allowed by the applicable requirement.

60. PCI Compliance Is Not a One-Day Event

Weak model:

Annual PCI Audit
      ↓
Pass
      ↓
Ignore Until Next Year

Strong model:

Continuous Controls
      ↓
Monitoring
      ↓
Evidence
      ↓
Testing
      ↓
Remediation
      ↓
Annual Validation

61. Compliance Validation

Different organizations validate PCI compliance differently.

Common mechanisms include:

Self-Assessment Questionnaire

Report on Compliance

Attestation of Compliance

External Vulnerability Scanning

62. Self-Assessment Questionnaire

Commonly abbreviated:

SAQ

SAQs are structured self-assessment instruments designed for eligible payment environments.

63. Different SAQs Exist

Different payment models may use different SAQ types.

The applicable SAQ depends on factors such as:

Payment Channel

Technology

Outsourcing Model

Card Data Handling

Do not randomly select an SAQ.

64. Report on Compliance

Commonly abbreviated:

ROC

A ROC provides detailed assessment documentation for organizations required to undergo that level of validation.

65. Attestation of Compliance

Commonly abbreviated:

AOC

The AOC formally attests to the compliance status associated with the applicable assessment.

66. Qualified Security Assessor

Commonly abbreviated:

QSA

QSAs are qualified professionals associated with approved assessment organizations who perform PCI DSS assessments where applicable.

67. Internal Security Assessor

Commonly abbreviated:

ISA

Organizations may maintain qualified internal PCI assessment expertise through the ISA program.

68. Approved Scanning Vendor

Commonly abbreviated:

ASV

ASVs perform external vulnerability scanning used for certain PCI DSS validation requirements.

69. External Vulnerability Scanning

PCI environments may require scans of internet-facing systems by an approved scanning vendor.

Conceptually:

Internet-Facing PCI Systems
      ↓
ASV Scan
      ↓
Findings
      ↓
Remediation
      ↓
Passing Scan

70. Penetration Testing

PCI DSS also includes penetration-testing expectations for applicable environments.

Testing may evaluate:

External Attack Surface

Internal Environment

Segmentation

Application Security

depending on scope.

71. Segmentation Testing

If segmentation is being used to reduce PCI scope:

Segmentation
      ↓
Must Be Effective

Testing helps verify that systems outside the CDE cannot improperly access CDE systems.

72. Merchant Levels

Payment brands and acquiring institutions may classify merchants according to transaction volumes and other factors.

These classifications can influence:

Validation Method

Assessment Requirements

Reporting Obligations

73. Merchant Level Is Not the PCI Standard

Important distinction:

PCI DSS
→ Security Requirements

Merchant Level
→ Validation / Program Classification

Exact classification rules can vary by payment brand.

74. Service Provider Compliance

Service providers may have their own PCI validation obligations.

A merchant should understand whether critical payment providers maintain appropriate PCI compliance.

75. Provider Validation

Possible evidence may include:

Attestation of Compliance

PCI Responsibility Matrix

Service Description

Scope Information

76. Responsibility Matrix

For complex outsourced or cloud environments, build:

PCI Responsibility Matrix

Example:

Control Area	Merchant	Provider
Physical Data Center Security	Provider	Provider
Application IAM	Merchant	—
Cloud Network Configuration	Merchant	Shared
Hardware Maintenance	—	Provider

77. PCI Scope Documentation

Organizations should document:

Payment Channels

Card Data Flows

Systems

Networks

People

Providers

Connections

78. Card Data Flow Diagram

A fundamental PCI artifact is the cardholder data flow.

Example:

Customer
      ↓
Web Checkout
      ↓
Payment Gateway
      ↓
Processor
      ↓
Card Network

79. Why Data Flows Matter

A data flow helps answer:

Where Does PAN Enter?

Where Does PAN Travel?

Where Is PAN Stored?

Who Can Access It?

Which Provider Receives It?

80. PCI Asset Inventory

Maintain an inventory of in-scope systems.

Example fields:

Asset	Function	CDE	Connected	Owner

81. People Can Be in PCI Scope

PCI compliance is not only about technology.

Personnel may:

Handle Card Data

Administer CDE Systems

Review Logs

Manage Security Controls

82. Processes Can Be in PCI Scope

Examples:

Customer Payment Handling

Refund Processing

Chargeback Handling

Telephone Payments

Incident Response

83. Paper Records

PCI DSS concerns are not necessarily limited to digital data.

Payment account data could exist in:

Printed Forms

Paper Receipts

Physical Records

Physical security and destruction may therefore be relevant.

84. Telephone Payments

Example:

Customer
      ↓
Call Center
      ↓
Provides Card Number

Potential PCI considerations include:

Agent Access

Call Recording

Workstation Controls

Data Entry

Storage

85. Call Recording Risk

If payment-card data enters call recordings:

Call Recording Platform

may create major scope implications.

Design payment processes carefully.

86. E-Commerce Payments

A typical architecture may include:

Customer Browser
      ↓
Merchant Website
      ↓
Payment Page
      ↓
Payment Processor

Different implementations can produce very different PCI scopes.

87. Redirected Payment Page

Example:

Merchant Website
      ↓
Redirect
      ↓
Provider-Hosted Payment Page

The merchant may handle less card data directly.

88. Embedded Payment Components

Payment forms embedded into merchant pages may create different security and scoping considerations.

Architecture must be assessed carefully.

89. Payment Terminals

Physical merchant environments may include:

POS Terminal

Payment Network

Processor

Controls may involve:

Device Security

Network Segmentation

Physical Inspection

90. PAN Storage

Before storing PAN, ask:

Do We Actually Need It?

Strong PCI architecture begins with:

Minimize Account Data

91. Data Minimization

A powerful principle:

Data You Do Not Store
      ↓
Data You Do Not Need to Protect in Storage

Subject to business and payment requirements.

92. Retention

If cardholder data is stored, define:

Business Need

Retention Period

Deletion Method

Owner

93. Secure Deletion

When retention expires:

Cardholder Data
      ↓
Secure Deletion

The organization should be able to demonstrate that unnecessary data is removed.

94. Cryptographic Keys

When encryption protects PAN:

Encryption Key Security

becomes crucial.

Areas include:

Generation

Storage

Access

Rotation

Retirement

95. Access Control

PCI requires strong control over who can access systems and data.

A useful model:

Business Need
      ↓
Approved Role
      ↓
Minimum Access
      ↓
Authentication
      ↓
Monitoring

96. Unique User Identification

Avoid:

Shared Administrator Account

where individual accountability is required.

Use:

Unique Identity
      ↓
Individual Accountability

97. MFA

Multi-factor authentication is an important part of modern PCI DSS access protection.

Especially consider access into:

CDE

Administrative Interfaces

Remote Access

according to applicable PCI requirements.

98. Vulnerability Management

PCI environments require active management of:

Known Vulnerabilities

Security Patches

Malware

Application Weaknesses

99. Secure Development

Applications involved in payment processing should be developed using secure software practices.

Examples:

Secure SDLC

Code Review

Vulnerability Testing

Change Control

Security Training

100. Logging

PCI systems should produce security-relevant logs.

Examples:

Authentication

Administrative Actions

Access to Cardholder Data

Security Events

101. Log Monitoring

Logs are useful only if important events are:

Collected

Reviewed

Alerted

Investigated

102. Security Testing

PCI requires regular testing of security controls.

Examples:

Vulnerability Scans

Penetration Testing

Segmentation Testing

Wireless Checks

File Integrity / Change Detection

depending on applicable requirements.

103. Security Policies

Policy governance ties together:

People

Processes

Technology

The goal is not merely having a document titled:

PCI Policy

The policies should align with actual operational controls.

104. PCI Evidence

Examples of evidence may include:

Network Diagrams

Data Flow Diagrams

Asset Inventories

Firewall Rules

IAM Reports

MFA Configuration

Vulnerability Scans

Penetration Tests

Log Reviews

Training Records

Vendor AOCs

105. Evidence Should Be Repeatable

Weak:

One Screenshot

Strong:

Control Requirement
      ↓
Authoritative Source
      ↓
Complete Population
      ↓
Evidence
      ↓
Testing

106. PCI Compliance Gap

A gap exists when:

Requirement
      ↓
Expected Control
      ↓
Actual Environment
      ↓
Difference

107. Example Gap — MFA

Requirement:

MFA Required

Observation:

3 Administrators
Without MFA

Result:

PCI Gap

108. Example Gap — Stored SAD

Observation:

Security Codes
Stored After Authorization

This is a serious PCI issue requiring immediate investigation and remediation.

109. Example Gap — Segmentation

Organization claims:

CDE Segmented

Testing shows:

Corporate Workstation
      ↓
Can Reach CDE Database

Result:

Segmentation Failure
+
Potential Scope Expansion

110. Scope Expansion

This is an important PCI concept.

If segmentation fails:

Previously Out-of-Scope Network

may become:

In Scope

until effective segmentation is established.

111. Example Gap — Logging

Requirement:

Security Logs

Actual:

Database Logging Disabled

Potential result:

Monitoring Gap

112. Example Gap — Vulnerability Scan

Required scan:

Quarterly

Actual:

Two Quarters Missing

Result:

Operating Gap

113. Example Gap — Provider

Payment provider handles PAN.

Merchant has:

No Current Provider
PCI Assurance

Result:

Third-Party Assurance Gap

114. PCI Compliance Responsibility

Management cannot simply state:

PCI Belongs to Security

PCI is an organizational responsibility.

A practical operating model:

Executive Sponsor
      ↓
PCI Program Owner
      ↓
GRC
      ↓
Control Owners
      ↓
Evidence Owners

115. GRC Responsibilities

A GRC professional may coordinate:

PCI Scope

Requirement Mapping

Evidence Collection

Gap Assessments

Control Testing

Third-Party Assurance

Remediation

Assessment Coordination

116. Engineering Responsibilities

Engineering may support:

Secure Development

Change Management

Application Security

Remediation

117. IAM Responsibilities

IAM supports:

User Provisioning

MFA

Privileged Access

Access Reviews

Termination

118. Security Operations Responsibilities

Security Operations may support:

Logging

Monitoring

Incident Response

Vulnerability Management

119. Network Responsibilities

Network / Cloud Security may support:

Segmentation

Firewall Rules

Network Diagrams

Traffic Restrictions

120. Third-Party Risk Responsibilities

TPRM may support:

Payment Provider Review

Cloud Provider Assurance

Vendor PCI Status

Responsibility Mapping

121. Internal Audit

Internal Audit may independently evaluate:

Control Design

Control Operation

Governance

Evidence

depending on organizational structure.

122. PCI Assessment Lifecycle

A mature assessment process looks like:

Scope
      ↓
Requirements
      ↓
Controls
      ↓
Evidence
      ↓
Testing
      ↓
Gap
      ↓
Remediation
      ↓
Validation
      ↓
Attestation

123. Annual Scope Confirmation

PCI scope should be reviewed regularly and whenever material changes occur.

Possible triggers:

New Payment Channel

New Cloud Provider

New Application

New Network Connection

New Payment Provider

Acquisition

Architecture Change

124. Change Management and PCI Scope

Before deployment ask:

Does This Change
Affect PCI Scope?

Examples:

New API

New Payment Integration

New Data Store

New SaaS Provider

125. Continuous PCI Monitoring

Useful indicators include:

CDE Assets

Open Critical Vulnerabilities

MFA Coverage

Segmentation Status

Scan Results

Provider Compliance Status

Open PCI Findings

126. Example PCI Dashboard

Metric	Target
CDE Asset Inventory Coverage	100%
Privileged MFA Coverage	100%
Critical Vulnerabilities Past SLA	0
Required PCI Scans Completed	100%
Current Critical Provider Assurance	100%
High PCI Findings	0

127. PCI KPI

Example:

Percentage of PCI DSS controls
operating effectively

128. PCI KRI

Example:

Number of critical CDE systems
with overdue security vulnerabilities

Target:

129. Scope KRI

Example:

Unknown systems connected
to the CDE

Target:

130. Third-Party KRI

Example:

Critical payment service providers
without current PCI assurance

131. PCI Incident Response

If payment account data may have been compromised:

Detect
      ↓
Contain
      ↓
Investigate
      ↓
Preserve Evidence
      ↓
Escalate
      ↓
Follow Applicable
Payment-Brand / Legal Processes

Incident handling should align with organizational and payment ecosystem obligations.

132. PCI Is Not the Same as SOC 2

SOC 2:

Attestation Framework
      ↓
Controls Against
Trust Services Criteria

PCI DSS:

Payment Security Standard
      ↓
Defined Security Requirements

They can overlap heavily, but they serve different purposes.

133. PCI Is Not the Same as ISO 27001

ISO/IEC 27001 focuses on establishing and operating an:

Information Security Management System

PCI DSS focuses specifically on:

Payment Account Data Security

134. Existing Controls Can Be Reused

An enterprise may already have:

IAM

Vulnerability Management

SIEM

Incident Response

Secure SDLC

These controls can potentially support PCI requirements when appropriately scoped and configured.

135. Avoid Building Duplicate Compliance Controls

Weak model:

SOC Access Review

ISO Access Review

PCI Access Review

three separate processes.

Stronger model:

Enterprise Access Review Control
      ↓
SOC
ISO
PCI

where requirements align.

136. One Source of Truth

Maintain one enterprise control library with mappings.

Example:

Enterprise Control	PCI	SOC 2	ISO 27001
Privileged MFA	✓	✓	✓
Vulnerability Mgmt	✓	✓	✓
Incident Response	✓	✓	✓

137. PCI Responsibility Matrix Example

Requirement Area	Control Owner
Network Security	Cloud Security
Secure Configurations	Infrastructure
Data Protection	Security / Engineering
Access Control	IAM
Logging	SOC
Security Testing	Security Testing
Governance	GRC

138. PCI Documentation Set

A mature program may maintain:

PCI Scope Document

Cardholder Data Flow

Network Diagram

CDE Asset Inventory

Responsibility Matrix

PCI Control Matrix

Evidence Catalog

Gap Register

Remediation Tracker

139. Practical Activity — Build PCI Program Register

Create:

01 PCI Program Register

Use:

Item	Owner	Status	Review Date

Include:

PCI Scope

CDE

Data Flow

Asset Inventory

Provider Inventory

Assessment Method

140. Practical Activity — Identify Payment Flow

Use fictional company:

CloudShop

Architecture:

Customer
      ↓
CloudShop Website
      ↓
Payment Gateway
      ↓
Payment Processor

Determine:

Where Does PAN Enter?

Does Merchant Store PAN?

Which Systems Touch Payment Data?

Which Provider Handles Authorization?

141. Practical Activity — Build Account Data Register

Create:

02 Payment Account Data Register

Use:

Data Element	Stored?	Processed?	Transmitted?	Location

Include:

PAN

Cardholder Name

Expiration Date

Security Code

142. Practical Activity — Build High-Level PCI Scope

Create:

03 Preliminary PCI Scope

Classify systems as:

CDE

Connected-to

Security-Impacting

Out of Scope

143. Practical Activity — Build PCI Requirement Map

Create:

04 PCI Requirement Overview

Map the twelve requirements to internal teams.

144. Practical Activity — Build Provider Register

Create:

05 PCI Service Provider Register

Use:

Provider	Service	PCI Impact	Assurance	Owner

145. Practical Activity — Build PCI Evidence Starter Catalog

Create:

06 PCI Evidence Catalog

Include at least 20 examples across:

Network

IAM

Data Protection

Vulnerability

Logging

Testing

Governance

146. Common PCI Mistakes

Mistake 1 — PCI Means Only Credit Card Database

Scope is much broader.

Mistake 2 — Outsourced Payment Means No PCI Responsibility

Merchant responsibilities can remain.

Mistake 3 — Cloud Provider Is PCI Compliant, So We Are PCI Compliant

Customer configuration still matters.

Mistake 4 — Encryption Automatically Removes Scope

Not necessarily.

Mistake 5 — Segmentation Assumed but Not Tested

Scope reduction becomes unreliable.

Mistake 6 — Sensitive Authentication Data Stored

This can create serious compliance and security problems.

Mistake 7 — Inventory Incomplete

Unknown CDE systems remain uncontrolled.

Mistake 8 — Provider Compliance Not Reviewed

Third-party dependencies become unmanaged.

Mistake 9 — Annual Audit Equals Continuous Compliance

Controls fail between assessments.

Mistake 10 — Separate PCI Controls Built for Everything

Enterprise control duplication creates unnecessary overhead.

147. Weak PCI Program

Annual Questionnaire
      ↓
Take Screenshots
      ↓
Submit
      ↓
Forget PCI

148. Strong PCI Program

Payment Architecture
      ↓
Account Data Inventory
      ↓
CDE
      ↓
Accurate Scope
      ↓
Requirements
      ↓
Enterprise Controls
      ↓
Continuous Evidence
      ↓
Security Testing
      ↓
Gap Management
      ↓
Assessment
      ↓
Continuous Compliance

149. PCI Readiness Checklist

Payment Environment

Payment channels identified.
Payment providers identified.
account data identified.
payment flows documented.

Data

PAN locations identified.
SAD handling identified.
storage justified.
retention defined.
disposal defined.

Scope

CDE identified.
connected systems identified.
security-impacting systems identified.
people identified.
processes identified.
providers identified.

Network

network diagrams available.
CDE boundaries identified.
segmentation documented.
segmentation tested where relied upon.

IAM

unique identities used.
least privilege applied.
MFA implemented where required.
privileged access controlled.
access reviews performed.

Data Protection

stored PAN protected.
transmission protected.
keys governed.
SAD storage prohibited after authorization where applicable.

Vulnerability Management

scanning performed.
vulnerabilities remediated.
malware protection maintained.
secure configuration maintained.

Development

secure SDLC defined.
application vulnerabilities addressed.
production changes controlled.

Monitoring

logging enabled.
logs monitored.
retention implemented.
security incidents investigated.

Testing

vulnerability scans completed.
applicable ASV scans completed.
penetration testing performed.
segmentation testing performed where applicable.

Third Parties

providers identified.
PCI responsibility documented.
compliance assurance reviewed.
service scope validated.

Governance

PCI owner identified.
policies established.
roles documented.
security awareness maintained.
incident response established.
evidence retained.

150. GRC Analyst Responsibilities

A GRC professional supporting PCI DSS may:

Coordinate PCI scoping.
Maintain payment-channel inventories.
Maintain account-data inventories.
Maintain CDE documentation.
Coordinate data-flow diagrams.
Coordinate network diagrams.
Map PCI requirements to controls.
Assign control owners.
Build evidence matrices.
Review provider PCI assurance.
Perform gap assessments.
Track remediation.
Coordinate internal testing.
Prepare assessment evidence.
Coordinate QSA requests.
Maintain compliance dashboards.
Monitor continuous PCI readiness.

GRC connects:

Executive Management

Payment Teams

Security

IAM

Cloud

Network

Engineering

Security Operations

Finance

Procurement

Legal

Internal Audit

Assessors

151. PCI DSS Maturity Model

Level 1 — Audit Driven

Assessment Approaches
      ↓
Organization Collects Evidence

Level 2 — Defined

Scope

Policies

Control Matrix

Level 3 — Managed

Evidence

Testing

Remediation

Provider Governance

Level 4 — Integrated

Enterprise Controls

Automated Evidence

Continuous Scope Monitoring

Level 5 — Continuous Payment Security Assurance

Real-Time Asset Discovery

Continuous CDE Monitoring

Automated Control Validation

Dynamic Scope

Continuous Compliance

152. PCI DSS Mindset

For every payment environment ask:

Where does payment-card data enter?

Where does it travel?

Where is it stored?

Do we need to store it?

Is sensitive authentication data present?

Which systems process it?

Which systems connect to those systems?

Which systems can affect their security?

Who administers them?

Which vendors handle card data?

Which controls belong to us?

Which belong to providers?

Is segmentation real?

Has segmentation been tested?

Are all CDE assets known?

Can every PCI control be evidenced?

What changes could expand scope?

Are we compliant today,
or only during assessment month?

When these questions can be answered accurately, PCI becomes a manageable security program instead of an annual compliance exercise.

Key Takeaways

PCI DSS is designed to protect payment account data.
Organizations that store, process, transmit, or can affect the security of payment account data may have PCI responsibilities.
Account data includes Cardholder Data and Sensitive Authentication Data.
PAN is the key Cardholder Data element for PCI scoping.
Sensitive Authentication Data has stringent storage restrictions after authorization.
The CDE includes people, processes, and technologies involved in handling applicable cardholder data and sensitive authentication data.
Connected and security-impacting systems can also affect PCI scope.
PCI scope should be minimized through sound architecture, not assumptions.
Outsourcing payment processing does not automatically remove merchant responsibility.
PCI DSS contains twelve major requirement areas grouped around secure networks, data protection, vulnerability management, access control, monitoring/testing, and security governance.
PCI DSS v4.x supports both defined and, for eligible requirements, customized implementation approaches.
PCI compliance validation may involve SAQs, ROCs, AOCs, ASVs, and qualified assessors depending on organizational requirements.
PCI DSS should operate as a continuous security program rather than an annual audit exercise.
Existing enterprise controls should be reused across PCI, SOC, ISO, and other frameworks where appropriate.
GRC plays a central role in scope, control mapping, evidence, assessment coordination, gap management, and continuous compliance.

Knowledge Check

Before continuing, make sure you can answer:

What is PCI DSS?
Why was PCI DSS created?
What types of organizations may have PCI responsibilities?
What is a merchant?
What is a service provider?
What is Account Data?
What is Cardholder Data?
What is PAN?
What is Sensitive Authentication Data?
Why is SAD treated differently?
What is the CDE?
Why can connected systems enter PCI scope?
Why is accurate scoping critical?
What are the twelve PCI DSS requirement areas?
What is the Defined Approach?
What is the Customized Approach?
What is an SAQ?
What is a ROC?
What is an AOC?
What is the role of a QSA?
What is an ASV?
Why is segmentation important?
Why does outsourcing payment processing not eliminate all PCI responsibility?
Why should service-provider PCI assurance be reviewed?
What role does GRC play in a PCI DSS program?

What’s Next?

➡️ Next: 02 — Cardholder Data Environment (CDE)

In the next lesson, you will move from PCI DSS fundamentals into one of the most important concepts in the entire standard: defining the Cardholder Data Environment.

You will work through:

Payment Channels
      ↓
Account Data
      ↓
Cardholder Data Flows
      ↓
Systems That Store CHD
      ↓
Systems That Process CHD
      ↓
Systems That Transmit CHD
      ↓
Connected Systems
      ↓
Security-Impacting Systems
      ↓
People & Processes
      ↓
CDE Boundary

You will learn how to distinguish:

CDE Systems

Connected-to Systems

Security-Impacting Systems

Segmentation Controls

Potentially Out-of-Scope Systems

and build practical artifacts including a Payment Channel Register, Account Data Inventory, Cardholder Data Flow Diagram, CDE Asset Inventory, PCI System Classification Matrix, CDE Responsibility Matrix, and CDE Validation Checklist.