Skip to content
All posts

PCI DSS penetration testing requirements: What to test and when

Many organizations know that PCI DSS requires penetration testing.

Far fewer understand exactly what exactly to test , when it is required, and how penetration testing fits into an overall PCI compliance program.

Misunderstanding PCI DSS penetration testing requirements can lead to failed assessments, delayed compliance efforts, unnecessary remediation costs, and increased risk to cardholder data. Successful PCI pentest should go beyond checking a compliance box once each year. This requires organizations to understand scope, segmentation testing requirements, significant change triggers, and reporting expectations.

This guide explains the key PCI DSS penetration testing requirements and provides a practical guide to prepare organizations for PCI assessments.

Contents

What Does PCI DSS Require?

PCI DSS 4.0 addresses penetration testing requirements under  Requirement 11.4. Organizations must conduct both internal and external penetration testing, validate segmentation controls if  segmentation is used to reduce scope, remediate identified vulnerabilities, and conduct testing after significant changes. PCI DSS also mandates organizations to use a documented penetration testing methodology based on industry accepted approaches. (CyberGuards)

The table below summarizes the core requirements.

Requirement

Frequency

Internal penetration testing

At least annually and after significant changes

External penetration testing

At least annually and after significant changes

Segmentation testing

At least annually when segmentation is used to reduce scope

Segmentation testing for service providers

At least every six months

Retesting after remediation

Required for exploitable findings

Documented testing methodology

Required

PCI DSS also requires penetration testing to be performed by independent qualified personnel Organizations may use internal resources or external testing firmsas long as they meet independent requirements . (WithPCI.com)

What Systems Should You Include in a PCI Pentest?

One of the most common PCI compliance mistakes is incorrectly defining scope.

A PCI pentest must include all systems that are part of the Cardholder Data Environment (CDE) as well as systems that can impact the security of the CDE. PCI guidance emphasizes that testing should cover the entire CDE perimeter and critical systems. (Matproof)

Common in scope assets include:

Cardholder Data Environment (CDE)

Systems that store, process, or transmit cardholder data are always in scope.

Examples include:

  • Payment processing systems
  • Payment databases
  • Point of sale systems
  • Payment gateways
  • Payment application servers

Connected Systems

Systems that connect to or support the CDE may also be in scope.

Examples include:

  • Active Directory infrastructure
  • Authentication systems
  • Logging platforms
  • Security monitoring solutions
  • Jump servers and management systems

Web Applications

Internet facing payment applications are a major focus of PCI DSS penetration testing.

Testing should evaluate:

  • Authentication controls
  • Session management
  • Input validation
  • Business logic flaws
  • Access control weaknesses

APIs

Modern payment ecosystems rely heavily on APIs.

Organizations frequently overlook APIs during PCI penetration testing despite their role in payment processing and data exchange.

Cloud Infrastructure

Cloud environments are increasingly common within PCI scoped environments.

Organizations should evaluate:

  • Cloud networking
  • Identity and access management
  • Storage configurations
  • Containerized workloads
  • Serverless functions
  • Cloud hosted payment applications

Given that scope determines testing coverage, remediation effort, and audit outcomes, proper scoping is a critical step in a PCI pentest engagement.

Internal vs. External PCI Penetration Testing

PCI DSS requires both internal and external penetration testing because each evaluates different attack paths.

Internal Testing

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

The objective is to determine whether an attacker can move through the environment and compromise cardholder data.

Internal testing typically focuses on:

  • Lateral movement
  • Privilege escalation
  • Active Directory attacks
  • Credential abuse
  • Network trust relationships
  • Access to sensitive systems

PCI DSS 4.0 heavily emphasizes on validating movement from non CDE systems into the CDE to demonstrate that internal security controls are effective. (Matproof)

External Testing

External penetration testing simulates attacks originating from the internet.

The goal is to identify vulnerabilities that external attackers could exploit to gain unauthorized access.

External testing commonly covers:

  • Internet-facing applications
  • External APIs
  • VPN gateways
  • Remote access solutions
  • Public cloud assets
  • Network perimeter controls

External testing should assess both network level and application level vulnerabilities. PCI DSS 4.0 specifically requires testing methodologies to include application layer testing and coverage of web facing applications. (Matproof)

PCI Segmentation Testing: The Most Commonly Misunderstood Requirement

Segmentation testing is one of the most misunderstood PCI DSS requirements.

Many organizations assume that because firewalls are configured, segmentation automatically reduces PCI scope. Auditors do not make that assumption.

Segmentation testing verifies that systems outside the CDE cannot access systems inside the CDE through unintended pathways.

In practical terms, segmentation testing attempts to bypass or validate security boundaries that separate PCI scoped from non-scoped assets.

When Is Segmentation Testing Required?

Segmentation testing is required if an organization relies on network segmentation to reduce PCI DSS scope. PCI DSS 4.0 explicitly requires organizations to validate segmentation effectiveness using penetration testing techniques rather than relying solely on firewall rule reviews. (Matproof)

For most merchants, segmentation testing is an annual process.

For service providers, segmentation testing is generally required every six months. (Sherlock Forensics)

Why Auditors Care So Much

If segmentation fails, the PCI scope often expands dramatically.

A failed segmentation test may scope in additional systems, increase assessment costs, remediation requirements, and compliance obligations.

For this reason, QSAs frequently scrutinize segmentation testing reports closely during assessments.

Organizations relying on segmentation should treat validation testing as a critical compliance activity rather than an optional exercise.

What Counts as a Significant Change?

PCI DSS requires penetration testing after significant infrastructure or application changes.

This requirement often leaves organizations struggling to determine what qualifies as significant.

While PCI DSS does not provide an exhaustive definition, common examples include:

  • Deployment of a new payment application
  • Major application upgrades
  • Cloud migrations
  • Network redesigns
  • New data flows involving payment data
  • Changes to the CDE boundary
  • Infrastructure replacements
  • Significant security architecture modifications
  • Changes to supporting services that affect the CDE

PCI specifically highlights additions or major modifications to hardware, software, network infrastructure, and systems supporting the CDE as examples of significant changes.

Major changes to the network trigger an immediate requirement for re-testing, organizations cannot wait for the annual testing cycle. (WithPCI.com)

Organizations should incorporate penetration testing into change management processes so testing occurs as part of major deployments rather than as an afterthought.

Common PCI Penetration Testing Mistakes

Poor Scoping

Many organizations underestimate PCI scope or fail to include systems that support the CDE.

Incomplete scoping can result in audit findings and costly retesting efforts.

Skipping Segmentation Testing

Organizations often assume segmentation controls are effective without formally validating them.

This often results in PCI assessment delays.

Treating Vulnerability Scans as Penetration Tests

Vulnerability scanning and penetration testing are not the same activity.

Automated scans identify known weaknesses.

Whereas penetration testing attempts to exploit vulnerabilities and validate real world attack paths.

PCI DSS requires both.

 

Waiting Until Audit Season

Organizations frequently schedule PCI penetration testing right before an assessment, leaving little time for remediation and retesting

Testing earlier in the compliance cycle provides more flexibility and reduces audit pressure.

Failing to Retest After Significant Changes

Infrastructure upgrades, cloud migrations, and application deployments often occur between annual assessments.

Organizations that fail to retest after significant changes may discover compliance gaps during audits.

PCI DSS Penetration Testing Checklist

Use the following checklist when preparing for your next PCI assessment:

✓ Define PCI scope and identify all in scope systems

✓ Validate network segmentation controls

✓ Perform internal penetration testing

✓ Perform external penetration testing

✓ Test applications and APIs within scope

✓ Document findings and remediation recommendations

✓ Remediate identified vulnerabilities

✓ Retest exploitable findings

✓ Maintain evidence for PCI assessments

✓ Conduct testing after significant changes

Following this checklist can help reduce audit findings and improve overall security posture.

Conclusion

PCI DSS penetration testing plays a critical role in validating the security of cardholder data environments.

Organizations that understand PCI pentest requirements, scope determination, segmentation testing obligations, and significant change triggers are far better positioned to maintain compliance and reduce risk. A well executed PCI compliance pentest not only satisfies Requirement 11.4 but also validates the effectiveness of the security controls.

This is why pen testing should be treated as a security and risk management strategy rather than an annual compliance checklist exercise.

 

Preparing for a PCI DSS Assessment?

Prescient Security helps organizations perform PCI DSS penetration testing, PCI segmentation testing, ASV scanning, and compliance assessments to meet PCI requirements with confidence. Whether you need a comprehensive PCI pentest, segmentation validation, or guidance preparing for an upcoming assessment, our team can help streamline the process and reduce compliance risk.