09 Penetration Testing

Penetration testing is a controlled security assessment designed to determine whether weaknesses in the Cardholder Data Environment (CDE) can actually be exploited.

Vulnerability scanning asks:

What weaknesses may exist?

Penetration testing goes further:

Can those weaknesses
actually be exploited?
      ↓
Can an attacker gain access?
      ↓
Can privileges be escalated?
      ↓
Can the attacker move laterally?
      ↓
Can payment systems or data
be compromised?

This distinction is extremely important.

A vulnerability scanner may identify hundreds of potential weaknesses, but a penetration test evaluates whether those weaknesses can be combined into meaningful attack paths.

A practical PCI penetration testing lifecycle looks like:

PCI Scope
      ↓
Test Objectives
      ↓
Rules of Engagement
      ↓
Target Identification
      ↓
Reconnaissance
      ↓
Vulnerability Analysis
      ↓
Exploitation
      ↓
Post-Exploitation
      ↓
Segmentation Validation
      ↓
Risk Analysis
      ↓
Report
      ↓
Remediation
      ↓
Retesting

The central question is:

Could a realistic attacker exploit weaknesses in the environment and gain unauthorized access to CDE systems or cardholder data?

Learning Objectives

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

Explain penetration testing in PCI DSS.
Distinguish penetration testing from vulnerability scanning.
Understand network-layer penetration testing.
Understand application-layer penetration testing.
Understand internal and external penetration testing.
Define penetration-test scope.
Understand segmentation testing.
Develop Rules of Engagement.
Understand tester qualifications and independence.
Understand reconnaissance and vulnerability analysis.
Understand controlled exploitation.
Understand privilege escalation.
Understand lateral movement.
Understand cloud and Kubernetes penetration testing considerations.
Assess penetration-test findings.
Coordinate remediation.
Perform retesting.
Build penetration-test evidence.
Support PCI assessors during penetration-test review.

1. What Is Penetration Testing?

Penetration testing is an authorized attempt to identify and exploit vulnerabilities within a defined environment.

The objective is not:

Cause Damage

The objective is:

Find Security Weakness
      ↓
Attempt Controlled Exploitation
      ↓
Measure Impact
      ↓
Improve Security

2. Vulnerability Scanning vs Penetration Testing

These activities are related but different.

Vulnerability Scanning

Typically identifies:

Known CVEs

Missing Patches

Weak Services

Configuration Problems

It answers:

What may be vulnerable?

Penetration Testing

Attempts to:

Exploit

Chain Weaknesses

Escalate Privileges

Move Laterally

Reach Sensitive Assets

It answers:

What could an attacker actually achieve?

3. Comparison

Area	Vulnerability Scan	Penetration Test
Primary Goal	Find weaknesses	Validate exploitability
Automation	High	Mix of manual + tools
Exploitation	Usually No	Yes, controlled
Attack Paths	Limited	Major focus
Human Analysis	Moderate	High
Output	Findings	Findings + attack impact

4. Why Penetration Testing Matters

A system may appear compliant because:

Firewall Exists

MFA Exists

Segmentation Exists

Patches Applied

but penetration testing asks whether those protections can be bypassed.

Example:

Corporate Network
      ↓
Expected:
Cannot Reach CDE

Penetration testing discovers:

Legacy Jump Host
      ↓
Weak Password
      ↓
CDE Access

That is a real attack path.

5. PCI Penetration Testing Objective

A PCI penetration test should help determine whether attackers could compromise:

CDE Systems

Payment Applications

Authentication Controls

Network Boundaries

Segmentation Controls

Security Services

6. Penetration Testing Scope

The most important first step is defining the test scope.

Create:

01 PCI Penetration Test Scope

Include:

CDE Systems

Connected-to Systems

Security-Impacting Systems

Network Boundaries

Payment Applications

External Interfaces

Segmentation Controls

7. Scope Sources

Use:

PCI Scope Statement

CDE Asset Inventory

Network Diagram

Data Flow Diagram

Application Inventory

Third-Party Connections

8. Scope Reconciliation

Before testing:

PCI Asset Inventory
      ↓
Pen Test Scope
      ↓
Compare

Ask:

Are all relevant CDE assets included?

Are new applications included?

Are cloud resources included?

Are new network connections included?

Are segmentation boundaries included?

9. Scope Gap Example

PCI inventory:

55 CDE Systems

Penetration-test scope:

47 Systems

Difference:

8 Systems

This should be investigated before testing begins.

10. Internal Penetration Testing

Internal penetration testing simulates an attacker who already has some access to the internal environment.

Potential starting points:

Compromised Workstation

Malicious Insider

Compromised Contractor

Internal Server

11. Internal Attack Path

Example:

Corporate Workstation
      ↓
Weak Service Credential
      ↓
Jump Host
      ↓
CDE Server

This can reveal weaknesses that external testing cannot.

12. External Penetration Testing

External penetration testing evaluates externally reachable systems.

Examples:

Payment Website

Payment API

VPN

Remote Access Gateway

Public Cloud Endpoint

13. External Attack Example

Internet
      ↓
Payment API
      ↓
Authentication Weakness
      ↓
Unauthorized Administrative Function

14. Network-Layer Penetration Testing

Network-layer testing may evaluate:

Firewalls

Routers

Servers

Operating Systems

Network Services

Segmentation

15. Application-Layer Penetration Testing

Application testing may examine:

Authentication

Authorization

Session Management

Input Validation

Business Logic

Payment Workflows

APIs

16. Payment Application Risks

High-value areas include:

Checkout

Refunds

Recurring Payments

Administrative Portal

Payment APIs

Customer Payment Records

17. Authorization Testing

Example:

User A should access:

Customer A Transaction

but changes:

transaction_id=1001

to:

transaction_id=1002

and sees Customer B data.

This is:

Authorization Failure

18. Business Logic Testing

Automated tools often miss business logic weaknesses.

Example:

Refund Request
      ↓
Normal Limit:
₹10,000

but attacker manipulates request to refund:

₹100,000

Manual testing may reveal this issue.

19. API Testing

Modern payment environments rely heavily on APIs.

Test:

Authentication

Authorization

Rate Limits

Input Validation

Sensitive Data Exposure

Administrative Endpoints

20. Test Methodology

A structured penetration test commonly follows:

Planning
      ↓
Reconnaissance
      ↓
Enumeration
      ↓
Vulnerability Analysis
      ↓
Exploitation
      ↓
Post-Exploitation
      ↓
Reporting

21. Planning

Define:

Objective

Scope

Test Window

Rules

Contacts

Success Criteria

22. Reconnaissance

The tester gathers information about:

Hosts

Services

Applications

Domains

Technology

Network Architecture

23. Enumeration

Testers identify:

Open Ports

Services

Users

Applications

APIs

Authentication Methods

24. Vulnerability Analysis

Potential weaknesses are analyzed for:

Exploitability

Impact

Attack Path Potential

25. Exploitation

The tester may safely attempt:

Authentication Bypass

Remote Code Execution

Privilege Escalation

Injection

Weak Credential Exploitation

within the approved Rules of Engagement.

26. Controlled Exploitation

The objective is:

Demonstrate Impact

without unnecessary:

Data Loss

Service Outage

Payment Disruption

27. Proof of Exploitation

Example:

Instead of downloading:

1 Million Card Records

the tester may demonstrate access to:

Controlled Test Record

or minimal evidence sufficient to establish impact.

28. Post-Exploitation

Once access is gained, testers may evaluate:

Privilege Escalation

Credential Access

Lateral Movement

Sensitive Data Access

Security-Control Bypass

29. Privilege Escalation

Example:

Standard Application User
      ↓
Local Vulnerability
      ↓
Administrator

This significantly increases risk.

30. Lateral Movement

Example:

Web Server
      ↓
Application Server
      ↓
Database

Testing determines whether compromise of one system allows movement deeper into the CDE.

31. Attack Chaining

Individual findings may appear small.

Example:

Weak Developer Credential
      ↓
Access to CI/CD
      ↓
Modify Payment Application
      ↓
Production Deployment
      ↓
Cardholder Data Access

Together they form:

Critical Attack Path

32. Segmentation Testing

Segmentation is especially important when used to reduce PCI scope.

The test asks:

Can systems classified outside the CDE reach CDE systems through unauthorized paths?

33. Segmentation Test Example

Expected:

Developer Network
      ✗
Payment Database

Actual:

Developer Network
      →
Payment Database
5432

Result:

Segmentation Failure

34. Scope Impact

If segmentation fails:

Out-of-Scope Network
      ↓
Potentially In Scope

This can dramatically change PCI scope.

35. Build Segmentation Test Matrix

Create:

02 PCI Segmentation Test Matrix

Use:

Source	Destination	Port	Expected	Actual

36. Representative Sources

Test from:

Corporate Network

Developer Network

Guest Network

Non-CDE Server

Third-Party Network

37. Representative CDE Targets

Examples:

Payment Web

Payment API

Payment Database

Jump Host

Administrative Interface

38. Positive Tests

Some communication should succeed.

Example:

Payment API
      →
Payment Database

Expected:

Allowed

39. Negative Tests

Other traffic should fail.

Example:

Guest Wi-Fi
      →
Payment Database

Expected:

Blocked

40. Penetration Testing Frequency

PCI DSS penetration testing should follow applicable requirements and should also consider significant changes.

A typical program includes recurring testing and additional testing after changes that materially affect security.

41. Significant Change Examples

New Payment Application

Major Infrastructure Upgrade

New CDE Network

Firewall Redesign

Cloud Migration

New Authentication Architecture

New Payment Provider

42. New CDE Application

If a new payment API is deployed:

New Payment API
      ↓
PCI Scope Change
      ↓
Pen Test Scope Update

43. Tester Qualifications

Penetration testing should be performed by personnel with appropriate:

Knowledge

Technical Skill

Experience

Methodology

44. Tester Independence

The tester should have sufficient organizational independence from the implementation being tested.

Weak:

Engineer Builds Control
      ↓
Same Engineer
Approves Own Pen Test

Stronger:

Independent Security Tester
      ↓
Validates Control

45. Internal Testers

Internal security teams may perform testing when they meet applicable requirements for:

Competence

Independence

Objectivity

46. External Penetration Testing Provider

External testers can provide:

Independent Perspective

Specialized Expertise

Advanced Testing Skills

47. Rules of Engagement

Before testing begins, define:

03 Penetration Testing Rules of Engagement

48. Rules of Engagement Should Include

Objectives

Scope

Testing Window

Authorized Techniques

Prohibited Activities

Emergency Contacts

Data Handling

Incident Escalation

Reporting

49. Testing Window

Example:

Saturday

22:00–04:00

if production testing may create operational risk.

50. Out-of-Scope Systems

Clearly define:

Systems That Must Not Be Tested

Examples may include systems not owned by the organization unless specific authorization exists.

51. Testing Authorization

Penetration testing must be explicitly authorized.

Maintain:

Written Approval

before testing.

52. Emergency Stop Procedure

Define:

Unexpected Outage
      ↓
Stop Testing
      ↓
Contact Operations

53. Data Handling

If the tester encounters CHD:

Minimize Access

Do Not Unnecessarily Copy

Secure Evidence

Follow Approved Data Handling

54. Test Accounts

Where practical, use:

Synthetic Payment Data

Test Customers

Test Accounts

rather than live customer data.

55. Cloud Penetration Testing

Cloud environments require additional considerations.

Evaluate:

Cloud IAM

Security Groups

Storage

Metadata Services

Network Paths

Workload Identity

56. Cloud Responsibility

Understand what testing is permitted by the cloud provider.

The organization should follow:

Provider Penetration Testing Policies

where applicable.

57. Cloud Attack Path Example

Application Workload
      ↓
Over-Permissive IAM Role
      ↓
Cloud Secrets
      ↓
Payment Database

58. Kubernetes Penetration Testing

For CDE Kubernetes environments, assess areas such as:

RBAC

Service Accounts

Secrets

NetworkPolicy

Container Privileges

API Server Exposure

59. Kubernetes Attack Path Example

Compromised Payment Pod
      ↓
Overprivileged ServiceAccount
      ↓
Kubernetes API
      ↓
Secret Access
      ↓
Database Credential

60. CI/CD Penetration Testing

If deployment systems can change the CDE, test security around:

Pipeline Permissions

Repository Access

Secrets

Production Approvals

61. CI/CD Attack Path

Developer Account
      ↓
Repository Write
      ↓
Pipeline
      ↓
Production
      ↓
Payment Application

If controls are weak, code changes could become a CDE compromise path.

62. Identity Testing

Assess:

MFA

Password Controls

Privileged Access

Account Lockout

Session Controls

Local Accounts

63. Password Attacks

Testing may include controlled assessment of:

Weak Passwords

Default Credentials

Credential Reuse

according to approved Rules of Engagement.

64. MFA Testing

Test whether MFA can be bypassed through:

Legacy Authentication

Local Accounts

Alternative Access Paths

65. Break-Glass Accounts

Evaluate whether emergency accounts:

Exist

Are Protected

Are Monitored

66. Third-Party Connectivity

Test relevant authorized paths from:

Managed Service Providers

Payment Vendors

Support Vendors

where included in scope and authorization.

67. Wireless Considerations

If wireless exists within or near the CDE, testing may assess:

Unauthorized Access Points

Weak Wireless Security

Unexpected Connectivity

68. Penetration-Test Findings

Every validated issue should be documented.

Create:

04 Penetration Test Findings Register

Use:

ID	Finding	Severity	Impact	Owner	Status

69. Finding Structure

A strong finding should contain:

Affected System

Technical Description

Evidence

Attack Path

Business Impact

Severity

Recommendation

70. Example Finding — Public Administration

Finding:

SSH access to a production payment server is accessible directly from the internet.

Attack path:

Internet
      ↓
SSH
      ↓
Payment Server

Severity:

High / Critical

depending on authentication and exposure.

71. Example Finding — Authorization Bypass

A user can manipulate an API identifier to retrieve another customer’s payment transaction metadata.

Risk:

Unauthorized Data Access

72. Example Finding — Segmentation Failure

A developer subnet classified outside the PCI scope can establish direct database connectivity to the payment database.

Impact:

PCI Scope Expansion

CDE Attack Path

73. Example Finding — Weak Cloud IAM

A CI/CD role can assume an unrestricted administrative role in the production payment account.

Impact:

Production CDE Control

74. Severity Assessment

Consider:

Exploitability

Privileges Required

Attack Complexity

CDE Exposure

Data Impact

Business Impact

75. Critical Finding

Example:

Unauthenticated Remote Code Execution
      ↓
Internet-Facing Payment Application

76. High Finding

Example:

Corporate Network
      ↓
Unauthorized CDE Admin Access

77. Medium Finding

Example:

Information Disclosure

with limited direct security impact.

78. Finding Validation

Before accepting a reported issue:

Reproduce

Confirm Scope

Review Evidence

Understand Impact

79. False Positive

Not every suspected issue is exploitable.

Document validation rather than silently removing findings.

80. Finding Remediation

A strong workflow:

Finding
      ↓
Assign Owner
      ↓
Correction
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Retest

81. Example — Firewall Finding

Correction:

Remove Unauthorized Rule

Corrective action:

Implement Firewall Rule Expiry

Automated Drift Detection

82. Example — Application Finding

Correction:

Fix Authorization Check

Corrective action:

Secure Coding Standard

Automated Authorization Tests

83. Retesting

Penetration-test findings should not be closed simply because:

Developer Says Fixed

Perform:

Independent Retest

84. Build Retest Register

Create:

05 Penetration Test Retest Register

Use:

Finding	Fix Date	Retest	Result	Tester

85. Retest Result

Use:

Passed

Partially Remediated

Failed

86. Failed Retest

If:

Failed

then:

Finding Remains Open

87. Partial Remediation

Example:

Original:

5 CDE Hosts Exposed

Retest:

4 Fixed

1 Still Exposed

Conclusion:

Open

88. Attack Path Retesting

Do not test only the individual control.

If the original attack path was:

Developer
      ↓
CI/CD
      ↓
Production

confirm the complete path is no longer exploitable.

89. Penetration Test Evidence Package

Create:

06 PCI Penetration Test Evidence Package

Include:

Approved Scope

Rules of Engagement

Test Methodology

Tester Qualifications

Test Dates

Test Results

Findings

Remediation

Retest Results

Final Closure

90. Tester Qualification Evidence

Potential evidence:

Professional Experience

Security Certifications

Methodology Documentation

Company Qualifications

depending on engagement requirements.

91. Penetration Test Report

The final report should contain:

Executive Summary

Scope

Methodology

Attack Paths

Findings

Risk Ratings

Recommendations

92. Executive Summary

Executives need:

What Was Tested?

What Was Compromised?

What Is the Business Risk?

What Must Be Fixed?

not only raw technical detail.

93. Technical Report

Technical teams need:

Affected Host

Evidence

Steps

Root Cause

Recommended Fix

94. Evidence Protection

Penetration-test reports may reveal:

Passwords

Network Paths

Vulnerabilities

Architecture

Attack Techniques

Store them securely.

95. Distribution

Limit access to:

Security

GRC

System Owners

Management

Assessors

according to business need.

96. Penetration Testing Calendar

Create:

07 PCI Penetration Testing Calendar

Track:

Test	Scope	Last Completed	Next Due	Owner

97. Calendar Events

Include:

Annual Pen Test

Segmentation Test

Post-Significant-Change Test

Retesting

as applicable.

98. Missed Penetration Test

Expected:

Annual

Actual:

Last Test:
18 Months Ago

Result:

Testing Operating Gap

99. Change Trigger Register

Create:

08 Penetration Test Change Trigger Register

Use:

Change	Pen Test Review	Test Required	Status

100. Examples of Change Triggers

New Payment API

Major Cloud Migration

Network Redesign

New CDE Segment

New Payment Application

Major Authentication Change

101. Penetration Testing Metrics

Recommended dashboard:

Metric	Target
Required Pen Tests Completed	100%
Critical Findings Open	0
High Findings Past SLA	0
Segmentation Tests Passed	100%
Findings Retested	100%
Failed Retests	0

102. Penetration Testing KPI

Example:

Percentage of required
PCI penetration tests
completed on schedule

Target:

100%

103. Finding KRI

Example:

Critical penetration-test findings
not remediated within SLA

Target:

104. Segmentation KRI

Example:

Unauthorized CDE connectivity
identified during testing

105. Retest KRI

Example:

Findings that fail retesting

106. Practical Activity — Build Test Scope

Use fictional organization:

CloudShop

Include:

Payment Website

Payment API

Payment Database

Jump Host

Cloud Payment Account

Identity Provider

CI/CD

CDE Firewall

107. Practical Activity — Define Rules of Engagement

Create:

Objective

Test Window

Scope

Allowed Techniques

Prohibited Activities

Emergency Contacts

Data Handling Rules

108. Practical Activity — Network Penetration Test

Scenario:

Corporate Network
      ↓
Jump Host
      ↓
CDE

Tester discovers:

Weak Jump Host Credential

and gains:

CDE Access

Document:

Finding

Attack Path

Severity

Correction

Corrective Action

109. Practical Activity — Application Test

Payment API allows:

Customer A
      ↓
Change Object ID
      ↓
Customer B Payment Record

Classify and remediate.

110. Practical Activity — Segmentation Testing

Test:

Developer Network
      →
Payment Database

Expected:

Blocked

Actual:

Allowed

Document:

Scope Impact

Root Cause

Correction

Retest

111. Practical Activity — Cloud Attack Path

Tester obtains:

Application IAM Role

then discovers permission:

sts:AssumeRole

into:

PaymentAdminRole

Analyze:

Impact

Least Privilege Failure

Corrective Action

112. Practical Activity — Kubernetes Attack Path

Compromised pod has:

Service Account
      ↓
Can Read Secrets

Secret contains:

Payment Database Credential

Document the attack chain and remediation.

113. Practical Activity — Retest

Original:

Public SSH
to Payment Server

Fix:

Restricted Security Group

Retest:

Internet
      →
SSH

Expected:

Blocked

114. PCI Penetration Testing Checklist

Planning

Current PCI scope reviewed.
test objectives defined.
systems identified.
applications identified.
segmentation boundaries identified.
testing window approved.

Rules of Engagement

written authorization obtained.
allowed testing documented.
prohibited testing documented.
emergency contacts identified.
stop conditions defined.
data handling defined.

Tester

tester qualified.
independence assessed.
methodology documented.
responsibilities defined.

Network Testing

external testing performed.
internal testing performed.
CDE hosts covered.
connected systems considered.
administrative paths tested.

Application Testing

payment applications covered.
authentication tested.
authorization tested.
session controls tested.
input validation tested.
business logic tested.
APIs tested.

Segmentation

out-of-scope sources tested.
CDE targets tested.
unauthorized paths tested.
expected permitted paths validated.
failures assessed for scope impact.

Cloud / Modern Infrastructure

cloud IAM tested.
cloud networking tested.
Kubernetes reviewed where applicable.
CI/CD attack paths considered.
workload identities considered.

Findings

affected asset identified.
evidence retained.
attack path documented.
severity assigned.
owner assigned.
remediation date defined.

Retesting

critical findings retested.
high findings retested.
failed retests reopened.
complete attack path validated.

Evidence

scope retained.
ROE retained.
tester qualifications retained.
test report retained.
remediation evidence retained.
retest report retained.

115. Common PCI Penetration Testing Mistakes

Mistake 1 — Vulnerability Scan Called a Penetration Test

No exploitation or attack-path analysis occurs.

Mistake 2 — Scope Does Not Match the CDE

Important payment systems remain untested.

Mistake 3 — Only External Testing Performed

Internal attack paths are missed.

Mistake 4 — Only Network Testing Performed

Payment application vulnerabilities remain unknown.

Mistake 5 — Segmentation Not Tested

Scope reduction is assumed rather than proven.

Mistake 6 — Tester Lacks Independence

Control implementation and assessment are not sufficiently separated.

Mistake 7 — New Architecture Not Retested

Significant changes introduce unvalidated risks.

Mistake 8 — Findings Closed Without Retest

Remediation may be incomplete.

Mistake 9 — Only Individual Findings Tested

Complete attack chains remain exploitable.

Mistake 10 — Pen-Test Reports Shared Too Broadly

Sensitive attack information is exposed.

116. Weak Penetration Testing Model

Annual Scanner
      ↓
Report
      ↓
Audit Folder

117. Strong Penetration Testing Model

Current PCI Scope
      ↓
Approved Test Plan
      ↓
Qualified Tester
      ↓
Network Testing
      ↓
Application Testing
      ↓
Segmentation Testing
      ↓
Controlled Exploitation
      ↓
Attack Path Analysis
      ↓
Findings
      ↓
Root Cause
      ↓
Remediation
      ↓
Retesting
      ↓
Continuous Improvement

118. GRC Analyst Responsibilities

A GRC professional supporting PCI penetration testing may:

Maintain penetration-testing requirements.
Coordinate test scope.
Reconcile test scope against PCI scope.
coordinate tester selection.
review independence.
maintain Rules of Engagement.
coordinate business approvals.
track significant-change testing.
maintain findings registers.
monitor remediation.
coordinate retesting.
maintain evidence.
review segregation-test results.
prepare testing dashboards.
support QSA review.

GRC connects:

Security Testing

Application Security

Network Security

Cloud Security

Infrastructure

DevOps

Payment Engineering

Penetration Testers

Management

Assessors

119. Penetration Testing Maturity Model

Level 1 — Annual Testing

External Pen Test

Static Report

Level 2 — Defined Program

Scope

ROE

Network + Application Testing

Findings Tracking

Level 3 — Risk-Based

Attack Paths

Segmentation Testing

Change Triggers

Independent Retesting

Level 4 — Integrated

Cloud Testing

CI/CD Testing

Automated Validation

Continuous Exposure Analysis

Level 5 — Continuous Security Validation

Breach Simulation

Attack Path Monitoring

Continuous Segmentation Validation

Automated Control Testing

120. PCI Penetration Testing Mindset

For every PCI penetration test ask:

Does the scope match
the current CDE?

Are internal and external
attack paths included?

Are payment applications tested?

Can segmentation actually be bypassed?

Can an attacker escalate privileges?

Can one compromised system
reach another?

Can cloud IAM be abused?

Can CI/CD modify production?

Can workload identities
access sensitive systems?

What happens after initial compromise?

Could attackers reach cardholder data?

Was remediation retested?

Can we prove the original attack path
is no longer possible?

The strongest penetration test does not simply produce a list of vulnerabilities.

It demonstrates:

Entry Point
      ↓
Exploit
      ↓
Privilege
      ↓
Movement
      ↓
Business Impact

and helps the organization eliminate the complete path.

Key Takeaways

Penetration testing validates whether vulnerabilities can actually be exploited.
Vulnerability scanning and penetration testing serve different purposes.
PCI penetration testing should align with the current PCI scope.
Both network-layer and application-layer testing are important.
Internal testing identifies risks that external testing may miss.
Rules of Engagement should clearly define scope, authorization, techniques, safety requirements, and data handling.
Testers should have sufficient technical skill and independence.
Exploitation should be controlled and limited to what is necessary to demonstrate risk.
Post-exploitation testing can identify privilege escalation and lateral movement.
Attack chaining can reveal critical paths that individual findings do not show.
Segmentation should be tested when relied upon for PCI scope reduction.
Failed segmentation can expand PCI scope.
Cloud, Kubernetes, CI/CD, and workload identities create modern attack paths that should be considered.
Penetration-test findings should be assigned owners and remediation targets.
Material findings should be independently retested before closure.
Penetration-test evidence should demonstrate scope, methodology, findings, remediation, and retesting.
GRC coordinates scope, testing governance, findings, remediation, evidence, and assessor interactions.

Knowledge Check

Before continuing, make sure you can answer:

What is penetration testing?
How is penetration testing different from vulnerability scanning?
What is internal penetration testing?
What is external penetration testing?
What is network-layer penetration testing?
What is application-layer penetration testing?
What is controlled exploitation?
What is post-exploitation?
What is privilege escalation?
What is lateral movement?
What is an attack path?
Why is segmentation testing important?
What happens when segmentation fails?
What are Rules of Engagement?
Why is written authorization required?
Why does tester independence matter?
Why should significant changes trigger testing?
Why should findings be retested?
What should a PCI penetration-test evidence package contain?
What role does GRC play in PCI penetration testing?

What’s Next?

➡️ Next: 10 — PCI Assessment

In the next lesson, you will move from individual PCI security controls into the complete PCI DSS assessment lifecycle.

You will learn how to bring together:

PCI Scope
      ↓
Applicable Requirements
      ↓
Control Owners
      ↓
Evidence
      ↓
Interviews
      ↓
Observation
      ↓
Technical Testing
      ↓
Findings
      ↓
Remediation
      ↓
Assessment Validation

You will also build practical artifacts including a PCI Assessment Plan, Requirement Applicability Matrix, Evidence Request List, Control Testing Workbook, Assessment Finding Register, Remediation Tracker, Assessment Status Dashboard, and PCI Assessment Readiness Checklist.