05 Conduct a PCI-DSS Assessment

Welcome to the fifth project in:

Module 11 — Enterprise GRC Transformation Project

In the previous projects, you moved through:

Enterprise Risk Assessment
        ↓
Build an ISMS
        ↓
ISO 27001 Gap Assessment
        ↓
SOC 2 Readiness Review

You have assessed enterprise risk, management systems, and assurance controls.

Now CloudNova introduces another important compliance requirement:

Payment Card
Security

CloudNova accepts payments from customers and management asks:

Does PCI DSS
Apply to Us?

The security team asks:

Which Systems
Are Actually
in Scope?

And the compliance team needs to determine:

Are Our
Payment Processes
PCI DSS Ready?

Your assignment is to conduct a practical:

PCI DSS
Assessment

Project Objective

Your objective is to determine:

How Payments
Enter the Organization
        ↓
Where Account Data
Flows
        ↓
Where It Is
Processed
        ↓
Where It Is
Stored
        ↓
Where It Is
Transmitted
        ↓
Which Systems
Can Affect Security
        ↓
PCI DSS Scope
        ↓
Applicable Requirements
        ↓
Existing Controls
        ↓
Evidence
        ↓
Compliance Gaps
        ↓
Remediation

The central lesson is:

PCI DSS Assessment
Begins With
Scope

If scope is wrong, the rest of the assessment can also be wrong.

Mission Information

Project Type: PCI DSS Compliance Assessment
Difficulty: Intermediate to Advanced
Estimated Time: 5–7 Hours
Primary Role: GRC Analyst / PCI DSS Compliance Analyst
Supporting Roles: Security / Cloud / Network / Application / IAM / Finance / Legal / Procurement / Internal Audit
Framework: PCI DSS
Primary Reference: Current applicable PCI DSS requirements and supporting PCI SSC guidance
Environment: Spreadsheet, diagramming tool, documentation platform, GRC platform, cloud environment
Deliverable: PCI DSS Scope, Gap Assessment & Remediation Pack

Important: PCI DSS requirements and validation obligations can change. Real assessments should use the current official PCI Security Standards Council materials and involve a qualified assessor where required. This project teaches the professional assessment methodology.

Learning Objectives

By completing this project, you will learn how to:

understand the purpose of PCI DSS.
understand PCI DSS applicability.
identify payment channels.
distinguish account-data concepts relevant to PCI DSS.
identify cardholder data.
understand sensitive authentication data.
map payment-data flows.
identify the Cardholder Data Environment.
identify connected-to systems.
identify security-impacting systems.
determine PCI DSS scope.
evaluate segmentation.
understand scope-reduction strategies.
understand merchant and service-provider considerations.
understand SAQ and ROC concepts.
assess PCI DSS requirements.
map enterprise controls to PCI requirements.
identify control owners.
collect compliance evidence.
evaluate technical and procedural controls.
identify compliance gaps.
risk-prioritize remediation.
prepare management reporting.
establish continuous PCI compliance.

Scenario

CloudNova Technologies operates an enterprise SaaS platform.

Customers purchase subscriptions using:

Credit Cards

Debit Cards

Corporate Cards

CloudNova uses a third-party payment provider.

Management initially assumes:

We Outsource
Payments

Therefore PCI DSS
Does Not Apply

The GRC team challenges this assumption.

Even where payment processing is outsourced, CloudNova may still have responsibilities depending on:

Payment Architecture

Website Integration

Data Flows

Service Provider

Contractual Responsibilities

Merchant Environment

Before deciding anything, you need to understand:

How Payments
Actually Work

Your Mission

Perform a structured PCI DSS assessment for CloudNova.

You need to answer:

How Are
Payments Accepted?

Where Does
Account Data Flow?

Does CloudNova
Store Account Data?

Does CloudNova
Process Account Data?

Does CloudNova
Transmit Account Data?

Which Systems
Can Affect Payment Security?

What Is
the CDE?

Is Segmentation
Effective?

Which PCI DSS
Requirements Apply?

What Evidence
Exists?

What Gaps
Exist?

What Must
Be Remediated?

Required Deliverables

Create:

01 PCI DSS Applicability Assessment

02 Payment Channel Inventory

03 Account Data Inventory

04 Cardholder Data Flow Diagram

05 PCI DSS Scope Document

06 CDE Asset Inventory

07 Connected System Inventory

08 Segmentation Assessment

09 PCI DSS Requirement Matrix

10 PCI Control Register

11 Evidence Request List

12 PCI Gap Register

13 Remediation Plan

14 PCI Compliance Dashboard

15 Executive Assessment Report

16 Continuous Compliance Plan

Part 1 — Understand PCI DSS

PCI DSS stands for:

Payment Card Industry
Data Security Standard

It establishes security requirements intended to protect payment account data.

Think:

Payment Data
      ↓
Security Requirements
      ↓
Technical Controls
      +
Process Controls
      +
Governance
      ↓
Compliance Validation

Part 2 — Understand PCI DSS Applicability

Start with:

Does the Organization
Store,
Process,
or Transmit
Account Data?

But do not stop there.

Also understand whether systems can:

Connect To

Impact

Influence

Provide Security For

the payment environment.

Part 3 — Understand Account Data

For assessment purposes, distinguish:

Account Data

into relevant categories including:

Cardholder Data

and:

Sensitive
Authentication Data

Part 4 — Cardholder Data

Cardholder data includes the:

Primary Account Number
(PAN)

and may include other associated cardholder information.

The PAN is fundamental when determining PCI DSS scope.

Part 5 — Sensitive Authentication Data

Sensitive authentication data includes security information used in payment authentication.

Examples include relevant:

Card Verification
Codes / Values

Full Track Data

PIN / PIN Block

PCI DSS places particularly strict restrictions around retention of sensitive authentication data after authorization.

Part 6 — Start With Payment Channels

Identify every way customers can make payments.

For CloudNova:

Website Checkout

Subscription Portal

Customer Support

Manual Finance Process

Mobile Application

API-Based Payment

Do not assume only the main website matters.

Part 7 — Create Payment Channel Inventory

Example:

Channel	Payment Method	Provider	Data Interaction	Owner
Web Checkout	Card	Payment Provider	Redirect/Hosted	Engineering
Subscription Portal	Card	Payment Provider	Tokenized	Billing
Support	Review	Finance	Must Validate	Finance
Mobile	Card	Payment Provider	SDK/API	Engineering

Part 8 — Ask the Most Important Question

For each payment channel:

Where Does
the Card Data
Go?

Trace it.

Do not rely solely on architecture assumptions.

Part 9 — Map Payment Data Flow

Create:

Customer
   ↓
CloudNova Website
   ↓
Payment Interface
   ↓
Payment Provider
   ↓
Payment Network
   ↓
Issuer / Acquirer

Then determine exactly:

Which Components
See the PAN?

Part 10 — Hosted Payment Example

A simplified model might be:

Customer Browser
       ↓
CloudNova
Checkout Page
       ↓
Hosted Payment
Provider
       ↓
Payment Processor

This may reduce CloudNova’s exposure to card data.

But it does not automatically mean:

No PCI
Responsibilities

Part 11 — API Payment Example

Another architecture might be:

Customer
   ↓
CloudNova Application
   ↓
CloudNova Backend
   ↓
Payment API
   ↓
Processor

If card data passes through CloudNova systems, scope may be significantly larger.

Part 12 — Never Guess Payment Architecture

Ask:

Does PAN Touch
Our Browser Code?

Our Web Server?

Our API?

Our Logs?

Our Database?

Our Monitoring?

Our Support Tools?

Our Analytics?

Part 13 — Identify Data Storage

Search for possible account-data storage in:

Databases

Logs

Backups

Support Tickets

Email

Analytics

Monitoring

Debug Logs

Object Storage

Developer Environments

Part 14 — Accidental Storage

A common problem:

We Do Not
Intentionally
Store PAN

does not necessarily mean:

PAN Is
Not Stored

For example:

Application
Receives PAN
      ↓
Error Occurs
      ↓
Request Body
Logged
      ↓
PAN Stored
in Logs

Part 15 — Create Account Data Inventory

Record:

Data Element

System

Storage Location

Purpose

Encryption

Retention

Access

Owner

PCI Relevance

Part 16 — Identify the CDE

CDE means:

Cardholder Data
Environment

Conceptually, it includes systems involved in relevant cardholder-data handling and systems within the applicable environment that require consideration under PCI DSS scoping rules.

Part 17 — CDE Example

Suppose CloudNova directly processes payment data through:

Web Server

Payment API

Payment Database

These may form part of the CDE.

But the scope can extend beyond them.

Part 18 — Identify Connected Systems

Ask:

What Systems
Can Connect
to the CDE?

Examples:

Jump Servers

Administrator Workstations

Identity Platforms

Monitoring Systems

Backup Systems

Management Networks

Security Tools

Part 19 — Identify Security-Impacting Systems

A system may not store card data but may still affect its security.

Example:

Identity Provider
      ↓
Authenticates
CDE Administrators

Compromise of the identity platform could potentially affect CDE security.

Part 20 — Create Scope Categories

Use a practical classification such as:

CDE System

Connected-to System

Security-Impacting System

Out-of-Scope System

Requires Further Review

Final classification should follow current PCI DSS scoping guidance.

Part 21 — Build Scope Inventory

Example:

System	Function	CHD	CDE Connectivity	Security Impact	Scope
Payment API	Processing	Yes	Yes	Yes	CDE
Payment DB	Storage	Yes	Yes	Yes	CDE
IAM	Authentication	No	Yes	Yes	In Scope
SIEM	Monitoring	No	Yes	Yes	In Scope
Marketing Site	Content	No	No	Review	Validate

Part 22 — Document Data Flows

Your diagram should identify:

Data Origin

Entry Point

Processing

Transmission

Storage

Encryption

Tokenization

Third Parties

Administrative Access

Logging

Backup

Part 23 — Example Detailed Flow

Customer
   ↓
Browser
   ↓
TLS
   ↓
Checkout
   ↓
Payment Provider
   ↓
Authorization
   ↓
Token Returned
   ↓
CloudNova Stores
Token

Now determine:

Does CloudNova
Ever Receive PAN?

That answer materially affects scope.

Part 24 — Understand Tokenization

Tokenization may replace:

PAN

with:

Token

This can reduce exposure when properly implemented.

But ask:

Can the Token
Be Reversed?

Who Controls
Tokenization?

Can CloudNova
Retrieve PAN?

What Systems
Interact With
the Tokenization
Service?

Part 25 — Understand Segmentation

Segmentation can help reduce PCI DSS scope by separating relevant systems from other environments.

Conceptually:

Enterprise Network
│
├── Corporate
│
├── Development
│
├── Production
│
└── CDE
     │
     └── Restricted
         Connectivity

Part 26 — Segmentation Is Not a Diagram

Weak:

Firewall
Exists

Better:

Segmentation
Designed
      ↓
Rules Defined
      ↓
Traffic Restricted
      ↓
Access Controlled
      ↓
Configuration Reviewed
      ↓
Effectiveness Tested

Part 27 — Assess Segmentation

Review:

Network Architecture

Firewall Rules

Security Groups

Routing

Access Controls

Administrative Paths

Trust Relationships

Cloud Connectivity

Part 28 — Test Segmentation

Where segmentation is relied upon to reduce scope, validate that out-of-scope systems cannot improperly reach the CDE.

Think:

Expected:
Blocked

Actual:
Test

Result:
Blocked / Reachable

Part 29 — Cloud Segmentation

In cloud environments review:

VPCs / VNets

Subnets

Security Groups

Network ACLs

Routing

Transit Connectivity

IAM

Administrative Access

Cloud Management Plane

Part 30 — Identity Can Affect Scope

Modern environments often rely heavily on:

Central Identity

Ask:

Can This
Identity System
Administer CDE
Resources?

If yes, its relevance must be assessed carefully.

Part 31 — Inventory CDE Assets

Create:

Asset ID

Hostname / Resource

Cloud Account

Network

Operating System

Application

Function

Owner

Data Interaction

Scope Classification

Part 32 — Maintain Scope Continuously

Do not determine PCI scope:

Once Per Year

and assume it remains unchanged.

Scope can change when:

New Application

New Payment Flow

New Vendor

Cloud Migration

Network Change

API Change

Acquisition

occurs.

Part 33 — Understand PCI DSS Requirements

A practical assessment should evaluate the current PCI DSS requirements across the major security areas.

The PCI DSS framework contains twelve principal requirements.

For training, think of them across areas such as:

Network Security

Secure Configuration

Account Data Protection

Encryption

Malware Protection

Secure Development

Access Control

Authentication

Physical Security

Logging & Monitoring

Security Testing

Security Governance

Part 34 — Requirement 1

Assess controls protecting systems and networks from unauthorized network access.

Review:

Network Security Controls

Firewall / Cloud Rules

Traffic Restrictions

Rule Reviews

Network Diagrams

CDE Boundaries

Part 35 — Example Evidence

Network Diagram

Data Flow Diagram

Firewall Rules

Security Groups

Rule Review

Change Tickets

Segmentation Tests

Part 36 — Requirement 2

Assess secure configurations.

Review:

Configuration Standards

Default Accounts

Default Passwords

Unnecessary Services

System Hardening

Cloud Configuration

Configuration Management

Part 37 — Configuration Baselines

Use approved:

Secure Baselines

Examples may be based on:

Vendor Guidance

CIS Benchmarks

Enterprise Standards

where appropriate.

Part 38 — Requirement 3

Assess protection of stored account data.

First ask:

Why Are We
Storing It?

The best scope-reduction strategy may be:

Do Not Store
Account Data
Unless Necessary

Part 39 — Data Retention

Define:

Business Need

Retention Period

Storage Location

Protection

Deletion Process

Verification

Part 40 — PAN Protection

Where PAN is stored, evaluate applicable protections required by the current PCI DSS standard.

Your assessment should determine:

Where PAN Exists

Who Can Access It

How It Is Protected

How Keys Are Managed

How It Is Displayed

How It Is Removed

Part 41 — Requirement 4

Assess protection of cardholder data during transmission over open, public networks.

Review:

Encryption

Protocols

Certificates

Key Strength

Endpoint Validation

Transmission Paths

Part 42 — Map Transmission

For every data flow ask:

Source

Destination

Protocol

Encryption

Trust Boundary

Owner

Part 43 — Requirement 5

Assess protection against malicious software and related threats.

Review:

Endpoint Protection

Malware Detection

Updates

Monitoring

Exceptions

User Protection

Part 44 — Requirement 6

Assess development and maintenance of secure systems and software.

Review:

Vulnerability Management

Patch Management

Secure SDLC

Code Review

Application Security

Change Management

Software Dependencies

Security Testing

Part 45 — Secure Development Flow

Requirement
   ↓
Code
   ↓
Peer Review
   ↓
Security Testing
   ↓
Approval
   ↓
Deployment
   ↓
Monitoring

Part 46 — Vulnerability Remediation

Determine:

How Vulnerabilities
Are Identified

How Risk
Is Assigned

What SLA
Applies

Who Owns
Remediation

How Closure
Is Validated

Part 47 — Requirement 7

Assess restriction of access according to business need.

Think:

Least Privilege

Need-to-Know

Role-Based Access

Privileged Access

Authorization

Part 48 — Access Model

User
 ↓
Business Role
 ↓
Approved Access
 ↓
System Permission
 ↓
Periodic Review

Part 49 — Requirement 8

Assess user identification and authentication.

Review:

Unique IDs

Authentication

MFA

Privileged Accounts

Service Accounts

Password / Authentication Policies

Account Lifecycle

Part 50 — Test Joiners, Movers, and Leavers

Sample:

New Employees

Role Changes

Terminations

Trace:

Request
 ↓
Approval
 ↓
Provisioning
 ↓
Modification
 ↓
Removal

Part 51 — Requirement 9

Assess physical access to cardholder data and relevant systems.

In cloud environments, do not automatically mark physical security:

Not Applicable

Evaluate responsibilities across:

Cloud Provider

Office Locations

Endpoints

Media

Paper Records

Facilities

Part 52 — Requirement 10

Assess logging and monitoring.

Review:

Audit Logs

Authentication Logs

Administrative Activity

Security Events

Time Synchronization

Log Protection

Retention

Daily / Periodic Review

Alerting

Part 53 — Logging Flow

CDE System
    ↓
Logs
    ↓
Central Platform
    ↓
Detection
    ↓
Alert
    ↓
Investigation

Part 54 — Test Logs

Ask:

Are Relevant
Events Logged?

Can Logs
Be Modified?

Who Reviews
Them?

Are Alerts
Generated?

Are Logs
Retained?

Is Time
Synchronized?

Part 55 — Requirement 11

Assess regular testing of security systems and processes.

This may include relevant:

Vulnerability Scanning

Penetration Testing

Segmentation Testing

Wireless Assessment

Change Detection

Intrusion Detection / Prevention

depending on the environment and current requirements.

Part 56 — Vulnerability Scanning

Understand the difference between relevant:

Internal Scanning

and:

External Scanning

and when approved scanning vendors or other specific PCI validation processes apply.

Part 57 — Penetration Testing

A PCI-focused penetration-testing program should consider relevant:

CDE Boundaries

Application Layer

Network Layer

Segmentation

Attack Paths

according to applicable PCI DSS requirements.

Part 58 — Requirement 12

Assess organizational security policies and programs.

Review:

Information Security Policy

Risk Analysis

Roles

Security Awareness

Incident Response

Third-Party Management

Compliance Governance

Part 59 — PCI Is Not Only Technical

A technically secure CDE can still have compliance gaps if:

Policies Missing

Ownership Undefined

Reviews Missing

Evidence Missing

Vendor Governance Weak

Incident Processes Incomplete

Part 60 — Build Requirement Matrix

Create:

Requirement	Control	Owner	Evidence	Status	Gap
Req. 1	NET-001	Network	Firewall Review	Partial	G-001
Req. 2	CFG-001	IT	Baseline	Pass	—
Req. 3	DATA-001	Security	Encryption Evidence	Pass	—
Req. 8	IAM-001	IAM	MFA Report	Partial	G-004

Use the current PCI DSS standard for exact requirement and sub-requirement references.

Part 61 — Build Common Controls

Do not create:

PCI Firewall Control

ISO Firewall Control

SOC Firewall Control

Create:

Enterprise Control
NET-001
      ↓
PCI DSS Mapping
      ↓
ISO Mapping
      ↓
SOC 2 Mapping

Part 62 — Reuse Existing Controls

From previous projects you already have:

IAM Controls

Logging Controls

Vulnerability Controls

Incident Controls

Vendor Controls

BCM Controls

Map these to PCI DSS where applicable.

Part 63 — Build PCI Control Register

Record:

Control ID

Control Name

PCI Requirement

Control Objective

Description

Owner

Operator

Frequency

Evidence

Implementation Status

Effectiveness

Part 64 — Evaluate Control Design

Ask:

If This Control
Operates Exactly
as Designed,

Will It Satisfy
Its Objective?

Part 65 — Evaluate Implementation

Verify:

Is the Control
Actually Deployed?

Use:

Configuration

Observation

Evidence

Interviews

Testing

Part 66 — Evaluate Operating Effectiveness

Example:

Firewall Rule Review
Required Every
Six Months

Evidence:

H1 ✓

H2 Missing

The control exists.

But:

Operation
Is Inconsistent

Part 67 — Create Evidence Request List

Request artifacts such as:

Network Diagram

Cardholder Data Flow

CDE Inventory

Firewall Configuration

Rule Reviews

Secure Baselines

Account Data Inventory

Encryption Configuration

Key Management Records

Access Lists

MFA Reports

Access Reviews

Vulnerability Scans

Penetration Tests

Logging Configuration

Incident Records

Security Training

Vendor Assessments

Part 68 — Evidence Register

Use:

ID	Requirement	Evidence	Owner	Status
E-001	Scope	CDE Diagram	Network	Ready
E-002	Req. 1	Firewall Review	Network	Partial
E-003	Req. 8	MFA Report	IAM	Ready
E-004	Req. 11	Segmentation Test	Security	Missing

Part 69 — Validate Evidence

Do not accept:

Screenshot
Exists

as sufficient by default.

Ask:

What Does
It Prove?

Which Systems
Does It Cover?

What Period?

Who Generated It?

Is It Complete?

Can It Be
Traced to
the Control?

Part 70 — Conduct Interviews

Interview:

PCI Program Owner

Network Team

Cloud Team

Application Team

IAM

SOC

Finance

Security Engineering

Vendor Management

Part 71 — Interview Finance

Ask:

How Are
Payments Accepted?

Are Card Numbers
Ever Received
by Email?

Phone?

Support Ticket?

Manual Process?

Who Can
Access Payment
Information?

Part 72 — Interview Developers

Ask:

Does Application Code
Ever Receive PAN?

Are Payment Requests
Logged?

Are Debug Logs
Enabled?

How Is Payment
Code Reviewed?

How Are Secrets
Managed?

Part 73 — Interview Network / Cloud

Ask:

Where Is
the CDE?

How Is It
Segmented?

What Can
Connect to It?

How Is
Administrative Access
Controlled?

How Is Segmentation
Validated?

Part 74 — Search for Scope Expansion

Look for:

Shared Administrator Accounts

Shared Identity Platforms

Shared Logging

Shared Backup

Shared Networks

Jump Hosts

Monitoring Systems

Management Platforms

These may affect scope.

Part 75 — Search for Unknown Card Data

Look in:

Logs

Tickets

Email

File Shares

Databases

Backups

Cloud Storage

Developer Machines

Part 76 — Never Collect Real PAN for Training

For this project use:

Synthetic
Payment Data

Do not copy or store real cardholder data in your training environment.

Part 77 — Identify Compliance Gaps

Common categories:

Scope Gap

Architecture Gap

Configuration Gap

Access Gap

Encryption Gap

Logging Gap

Vulnerability Gap

Testing Gap

Governance Gap

Evidence Gap

Part 78 — Create Gap Register

Example:

Gap ID	Domain	Gap	Risk	Priority
G-001	Scope	CDE inventory incomplete	High	High
G-002	Network	Segmentation unvalidated	Critical	Critical
G-003	IAM	Privileged MFA incomplete	Critical	Critical
G-004	Logging	Review evidence missing	High	High
G-005	Vendor	Provider review overdue	Medium	Medium

Part 79 — Write Strong Findings

Weak:

MFA Missing

Better:

Three administrative
accounts with access
to in-scope systems
were identified without
the required MFA control.

Part 80 — Finding Structure

Use:

Criteria

Condition

Evidence

Risk

Root Cause

Recommendation

Part 81 — Example Finding

Finding:
PCI-IAM-001

Condition:
Three privileged accounts
capable of administering
in-scope systems were
not protected by MFA.

Evidence:
Identity export reviewed
during assessment.

Risk:
Compromise of credentials
could enable unauthorized
administrative access.

Recommendation:
Enforce MFA for all
applicable administrative
access and establish
continuous monitoring
for exceptions.

Part 82 — Prioritize Scope Problems First

If you do not know:

What Is
In Scope

you cannot reliably determine:

What Must
Be Compliant

Therefore:

Scope Gaps

should be addressed early.

Part 83 — Prioritize Account Data Exposure

Examples:

Unnecessary PAN Storage

Sensitive Authentication
Data Retention

Unencrypted PAN

Unknown Payment Flows

may represent urgent issues requiring immediate escalation and remediation.

Part 84 — Build Remediation Plan

For every gap document:

Gap

Required Action

Owner

Priority

Dependencies

Target Date

Expected Evidence

Validation

Status

Part 85 — Example Remediation

Gap:

CDE Segmentation
Not Validated

Action:

Confirm CDE Boundary
      ↓
Review Firewall Rules
      ↓
Remove Unnecessary Paths
      ↓
Perform Segmentation Test
      ↓
Remediate Findings
      ↓
Retest

Part 86 — Reduce Scope Where Appropriate

One powerful compliance strategy is:

Reduce Account Data
Exposure

Potential strategies include:

Hosted Payment Pages

Tokenization

Outsourced Processing

Network Segmentation

Eliminating PAN Storage

Restricting Administrative Paths

These must be correctly designed and validated.

Part 87 — Scope Reduction Is Not Control Avoidance

The objective is not:

How Can We
Avoid PCI?

It is:

How Can We
Minimize Payment
Data Exposure
While Meeting
Business Requirements?

Part 88 — Understand Merchant Validation

PCI DSS validation obligations can depend on factors such as:

Merchant Role

Service Provider Role

Payment Channels

Transaction Environment

Acquirer Requirements

Payment Brand Requirements

Part 89 — Understand SAQs

SAQ means:

Self-Assessment
Questionnaire

Different SAQ types apply to different payment environments.

Do not select an SAQ simply because:

It Has
Fewer Questions

The payment architecture determines eligibility.

Part 90 — Understand ROC

ROC means:

Report on
Compliance

Certain organizations may require a formal assessment and ROC based on applicable validation requirements.

Part 91 — Understand AOC

AOC means:

Attestation
of Compliance

It communicates the outcome of the applicable PCI DSS assessment.

Part 92 — Do Not Guess Validation Requirements

Confirm requirements with relevant:

Acquirer

Payment Brand

Qualified Security Assessor

Compliance Stakeholder

as appropriate.

Part 93 — Third-Party Service Providers

Create a list of providers that:

Store

Process

Transmit

Secure

Manage

or Can Affect

the relevant payment environment.

Part 94 — Vendor Register

Example:

Provider	Service	PCI Impact	Evidence	Owner
Payment Provider	Processing	High	AOC	Finance
Cloud Provider	Hosting	High	Compliance Evidence	Cloud
Security Provider	Monitoring	Review	Assurance Report	Security

Part 95 — Service Provider Compliance Does Not Transfer Responsibility

Weak assumption:

Vendor Is
PCI Compliant

Therefore
We Are Compliant

Professional approach:

Vendor Controls
        +
CloudNova Controls
        +
Shared Responsibilities
        =
Complete Control
Environment

Part 96 — Define Responsibility Matrix

For every relevant control determine:

CloudNova

Provider

Shared

Part 97 — Example

Physical Data Center
Security
→ Cloud Provider

Cloud IAM
→ CloudNova

Underlying Infrastructure
→ Provider

Application Security
→ CloudNova

Actual responsibility depends on the service model.

Part 98 — Build PCI Compliance Dashboard

Example:

PCI DSS ASSESSMENT

Scope Confirmed             85%

CDE Assets Identified        42

Requirements Assessed        90%

Controls Effective           82%

Critical Gaps                 2

High Gaps                     7

Evidence Ready               78%

Remediation Complete         54%

Values are illustrative.

Part 99 — Avoid a Single Compliance Percentage

Do not tell executives only:

We Are
88% Compliant

They need to know:

Is Card Data
Exposed?

Is Scope
Accurate?

Are Critical
Controls Missing?

What Could
Block Validation?

What Must
Be Fixed First?

Part 100 — Build Risk Heat Map

Example:

Domain	Status
Scope	Medium
Network Security	High
Data Protection	High
IAM	Medium
Vulnerability Management	High
Logging	Medium
Testing	Medium
Governance	High
Third Parties	Medium

Part 101 — Identify Compliance Blockers

Examples may include:

Unknown CDE Scope

Unprotected PAN

Prohibited Data Retention

Critical MFA Gaps

Unvalidated Segmentation

Critical Vulnerabilities

Missing Required Testing

Major Logging Gaps

Part 102 — Establish Continuous Compliance

Do not operate:

Annual Assessment
      ↓
Pass
      ↓
Ignore PCI
for 11 Months

Move toward:

Continuous Scope
Management
      ↓
Control Monitoring
      ↓
Evidence Collection
      ↓
Exception Management
      ↓
Testing
      ↓
Remediation
      ↓
Continuous Compliance

Part 103 — Create PCI Control Calendar

Example:

Activity	Frequency
Scope Review	At least annually and on significant change
Firewall Review	Per applicable requirement
Access Review	Per applicable requirement
Vulnerability Scanning	Per applicable requirement
Penetration Testing	Per applicable requirement
Segmentation Testing	Per applicable requirement
Risk Review	Defined Frequency
Security Training	Defined Frequency

Use the current PCI DSS standard for exact frequencies.

Part 104 — Change Management Integration

Every significant change should ask:

Does This
Change PCI
Scope?

Examples:

New Payment Provider

New API

Cloud Migration

Network Change

New Authentication Platform

New Logging Platform

New Support Workflow

Part 105 — PCI Impact Assessment

Add to change management:

Does Change
Touch CDE?

Does It Create
New Data Flow?

Does It Change
Segmentation?

Does It Introduce
New Provider?

Does It Affect
Existing Controls?

Part 106 — Continuous Scope Monitoring

Maintain:

Payment Channels

CDE Inventory

Connected Systems

Data Flows

Third Parties

Administrative Paths

as living records.

Part 107 — Evidence Automation

Where appropriate:

Cloud APIs

IAM Reports

Configuration Platforms

Vulnerability Scanners

SIEM

Ticketing

GRC Platforms

can support automated evidence collection.

Part 108 — Common Mistake: Assuming Outsourcing Removes PCI

Payment Provider
Handles Cards

does not automatically mean:

No PCI
Responsibilities

Determine the actual payment architecture and validation obligations.

Part 109 — Common Mistake: Starting With Requirements

Weak:

Open PCI DSS
      ↓
Start Requirement 1

Better:

Payment Channels
      ↓
Data Flow
      ↓
CDE
      ↓
Scope
      ↓
Requirements

Part 110 — Common Mistake: Incomplete Scope

Missing:

IAM

Logging

Backup

Jump Hosts

Management Platforms

Cloud Control Plane

can lead to inaccurate assessment conclusions.

Part 111 — Common Mistake: Storing PAN Unnecessarily

Ask:

Why Do We
Need PAN?

If there is no valid business need:

Remove It

rather than building unnecessary infrastructure around it.

Part 112 — Common Mistake: Ignoring Logs

Applications may accidentally log:

Payment Requests

API Payloads

Error Messages

Debug Information

Always evaluate logs during payment-data discovery.

Part 113 — Common Mistake: Segmentation Without Testing

Firewall
Configured

does not prove:

Segmentation
Effective

Validate it.

Part 114 — Common Mistake: Treating PCI as a GRC-Only Project

PCI DSS requires participation from:

Network

Cloud

Application

IAM

SOC

Security Engineering

Finance

Procurement

Legal

Management

Part 115 — Common Mistake: Evidence Scramble

Weak:

Assessment Starts
      ↓
Find Evidence

Better:

Control Operates
      ↓
Evidence Generated
      ↓
Evidence Stored
      ↓
Evidence Reviewed
      ↓
Assessment Ready

Part 116 — PCI Maturity Model

Level 1 — Unknown

Payment Flows
Not Fully Known

Level 2 — Scoped

CDE
Identified

Level 3 — Controlled

PCI Controls
Implemented

Level 4 — Measured

Controls Tested

Evidence Maintained

Level 5 — Continuous

Scope Monitoring

Control Automation

Continuous Evidence

Exception Management

Continuous Assurance

Part 117 — Future-State CloudNova

Move from:

Payment Provider
      ↓
Assume
Low Risk

to:

Payment Architecture
        ↓
Data Flow
        ↓
Scope
        ↓
Risk
        ↓
Controls
        ↓
Evidence
        ↓
Testing
        ↓
Continuous Compliance

Practical Assignment

Perform the PCI DSS assessment for CloudNova.

Task 1 — Identify Payment Channels

Document every method through which customers can provide payment information.

Create at least:

5 Payment
Channels

including hypothetical channels where useful for the exercise.

Task 2 — Map Account Data

Identify:

PAN

Relevant Cardholder Data

Sensitive Authentication Data

Tokens

and where each could exist.

Task 3 — Create Data Flow Diagram

Map:

Customer
      ↓
Entry Point
      ↓
Application
      ↓
Payment Provider
      ↓
Storage / Token
      ↓
Supporting Systems

Task 4 — Determine CDE

Classify systems as:

CDE

Connected

Security Impacting

Out of Scope

Review Required

Task 5 — Build Asset Inventory

Identify at least:

20 Relevant
Systems / Assets

Task 6 — Assess Segmentation

Review:

Networks

Cloud Architecture

Administrative Access

Firewall Rules

Trust Relationships

Task 7 — Build Requirement Matrix

Assess the twelve PCI DSS requirement areas using the current standard.

Task 8 — Map Controls

Reuse enterprise controls from:

ISO 27001

SOC 2

Enterprise ISMS

where appropriate.

Task 9 — Build Evidence Request List

Identify at least:

30 Evidence
Artifacts

Task 10 — Perform Sample Testing

Test representative:

Firewall Changes

Administrator Accounts

Access Reviews

Vulnerabilities

Security Alerts

System Changes

Vendor Reviews

Task 11 — Identify Gaps

Create at least:

15 Realistic
PCI DSS Gaps

Task 12 — Identify Critical Gaps

Highlight issues involving:

Account Data Exposure

Authentication

Segmentation

Critical Vulnerabilities

Logging

Testing

Task 13 — Build Remediation Plan

For each gap define:

Action

Owner

Priority

Target Date

Evidence

Validation

Task 14 — Build PCI Dashboard

Show:

Scope

Controls

Evidence

Gaps

Remediation

Compliance Blockers

Task 15 — Executive Report

Answer:

Does PCI DSS
Apply?

What Is
Our Scope?

Where Is
Account Data?

What Are
the Major Gaps?

What Is
Our Risk?

What Must
Be Fixed?

What Can
Reduce Scope?

What Management
Decisions Are Required?

Final Validation Checklist

Applicability

payment channels identified.
merchant/service-provider role considered.
validation obligations considered.
third-party payment providers identified.
applicable current PCI DSS materials identified.

Data

account data identified.
PAN flows mapped.
sensitive authentication data considered.
storage locations identified.
logs reviewed.
backups reviewed.
retention reviewed.

Scope

CDE identified.
connected systems identified.
security-impacting systems identified.
administrative paths identified.
third parties identified.
scope documented.
exclusions justified.

Segmentation

segmentation architecture documented.
firewall rules reviewed.
cloud controls reviewed.
trust relationships reviewed.
segmentation effectiveness validated.

Controls

applicable requirements assessed.
enterprise controls mapped.
owners assigned.
frequencies defined.
control design evaluated.
implementation validated.
operating effectiveness assessed.

Evidence

evidence request list created.
evidence owners assigned.
evidence collected.
evidence quality reviewed.
evidence traceability maintained.

Testing

representative samples selected.
access tested.
network controls tested.
vulnerabilities reviewed.
logging reviewed.
security testing reviewed.
exceptions documented.

Third Parties

service providers inventoried.
responsibilities defined.
compliance evidence reviewed.
contracts considered.
ongoing monitoring established.

Gaps

gaps documented.
severity assigned.
root causes identified.
critical issues escalated.
remediation owners assigned.
target dates established.

Continuous Compliance

scope-review process established.
change-management integration established.
control calendar established.
evidence process established.
monitoring established.
annual/periodic validation planned.

Expected Project Folder

05 Conduct a PCI-DSS Assessment
│
├── 01 PCI DSS Applicability Assessment
├── 02 Payment Channel Inventory
├── 03 Account Data Inventory
├── 04 Cardholder Data Flow Diagram
├── 05 PCI DSS Scope Document
├── 06 CDE Asset Inventory
├── 07 Connected System Inventory
├── 08 Segmentation Assessment
├── 09 PCI DSS Requirement Matrix
├── 10 PCI Control Register
├── 11 Evidence Request List
├── 12 PCI Gap Register
├── 13 Remediation Plan
├── 14 PCI Compliance Dashboard
├── 15 Executive Assessment Report
└── 16 Continuous Compliance Plan

Success Criteria

You successfully complete this project when you can move from:

Payment
      ↓
Payment Channel
      ↓
Account Data
      ↓
Data Flow
      ↓
CDE
      ↓
Connected Systems
      ↓
PCI Scope
      ↓
Requirements
      ↓
Controls
      ↓
Evidence
      ↓
Testing
      ↓
Gaps
      ↓
Remediation
      ↓
Continuous Compliance

and confidently answer:

How Do
Payments Work?

Where Does
Account Data Flow?

Where Is
PAN Stored?

What Is
the CDE?

Which Systems
Can Affect It?

Is Segmentation
Effective?

Which Requirements
Apply?

Which Controls
Address Them?

Who Owns
Those Controls?

Can We
Produce Evidence?

What Gaps
Exist?

Which Gaps
Are Critical?

Can Scope
Be Reduced?

What Must
Management Do?

Career Connection

This project reflects work performed by:

PCI DSS
Compliance Analysts

GRC Analysts

Security Assessors

PCI Consultants

Security Architects

Cloud Security
Professionals

Compliance Managers

Security Assurance
Professionals

A beginner may approach PCI DSS as:

12 Requirements
       ↓
Checklist
       ↓
Evidence

A professional starts with:

Business
      ↓
Payment Architecture
      ↓
Account Data
      ↓
Data Flow
      ↓
Scope
      ↓
Risk
      ↓
Requirements
      ↓
Controls
      ↓
Validation

The most important question is often not:

Are We
PCI Compliant?

It is:

Do We
Actually Understand
Where Payment Data
Exists and Which
Systems Can Affect
Its Security?

Once that is understood, compliance becomes much more manageable.

What’s Next?

➡️ Next: 06 — Review Cloud Compliance (ISO 27017–27018)

You have now completed:

Enterprise Risk Assessment
        ↓
Build an ISMS
        ↓
ISO 27001 Gap Assessment
        ↓
SOC 2 Readiness Review
        ↓
PCI DSS Assessment

The next project moves the GRC transformation into:

Cloud
Compliance

You will evaluate how traditional information-security governance changes when services operate across:

Cloud Service
Customer
        +
Cloud Service
Provider

You will move through:

Cloud Services
      ↓
Cloud Roles
      ↓
Shared Responsibility
      ↓
Cloud Risk
      ↓
ISO 27017
      ↓
ISO 27018
      ↓
Cloud Controls
      ↓
Privacy Controls
      ↓
Evidence
      ↓
Gap Assessment
      ↓
Cloud Compliance
Roadmap

You will learn how to determine:

Who Is
Responsible
for What?

Which Cloud
Controls Apply?

How Are
Customer and Provider
Responsibilities Divided?

How Is PII
Protected in
Public Cloud?

What Evidence
Demonstrates
Cloud Compliance?

Where Are
the Gaps?

➡️ Next: 06 — Review Cloud Compliance (ISO 27017–27018)