If your organisation stores, processes, or transmits payment card data, PCI DSS almost certainly applies to you. The Payment Card Industry Data Security Standard is a global framework designed to protect cardholder data (CHD) and sensitive authentication data (SAD). It covers controls ranging from access management and encryption to logging and testing, and penetration testing sits firmly within its requirements.

Yet PCI DSS penetration testing is one of the areas where UK organisations most often stumble. Scoping is misunderstood. Segmentation is assumed rather than validated. The difference between a vulnerability scan and a penetration test remains blurry for many buyers. This guide explains where penetration testing fits within PCI DSS, how to think about scope, what to expect from providers, and how to avoid the most common mistakes. It's written as practical guidance rather than compliance advice. For specific interpretations of the standard, always confirm requirements with a Qualified Security Assessor (QSA) or your acquirer.

What PCI DSS Is and Where Penetration Testing Fits

PCI DSS is maintained by the PCI Security Standards Council and applies to any organisation involved in handling payment card data. The standard is organised into requirements spanning network security, access controls, monitoring, and testing. Penetration testing falls under Requirement 11 (in v4.0, this is Requirement 11.4), which addresses regular testing of security systems and processes.

Penetration testing and vulnerability scanning are distinct activities under PCI DSS, even though they're sometimes conflated.

Vulnerability scanning (Requirement 11.3 in v4.0) uses automated tools to identify known weaknesses across systems. Internal scans are typically run quarterly, and external scans must be performed by an Approved Scanning Vendor (ASV).

Penetration testing goes further: a tester actively attempts to exploit vulnerabilities to determine whether an attacker could gain unauthorised access to cardholder data or the broader environment. It requires skilled human analysis, not just automated tooling.

Both are required. A clean vulnerability scan does not remove the need for a penetration test, and vice versa. For a more detailed comparison, see our guide on vulnerability assessment vs penetration testing.

PCI DSS requires penetration testing at least annually and after any significant change to the environment, such as a major infrastructure upgrade, a new application deployment, or changes to network segmentation controls.

Understanding the Cardholder Data Environment and Scope

Scoping is arguably the most consequential step in PCI DSS penetration testing, and it's where many organisations get it wrong. The standard defines the Cardholder Data Environment (CDE) as the people, processes, and technology that store, process, or transmit CHD or SAD. Everything within the CDE is in scope for PCI DSS and, by extension, for penetration testing.

PCI DSS assumes that everything is in scope until proven otherwise. This includes not just systems that directly handle card data, but also any "connected-to" or "security-impacting" systems. These don't touch cardholder data themselves but could provide an attack path into the CDE if compromised.

Connected-to and Security-Impacting Systems

Common examples include:

• Active Directory or authentication servers the CDE relies on
• Logging and monitoring infrastructure collecting data from CDE systems
• Jump hosts or bastion servers used to administer CDE components
• Backup systems that may hold copies of cardholder data
• DNS, NTP, or other shared network services

If these systems are reachable from or provide services to the CDE, they're typically in scope. Omitting them from a penetration test creates a gap that an assessor, or an attacker, will find.

Segmentation and Scope Reduction

Many organisations use network segmentation to reduce PCI DSS scope. The idea is straightforward: if you can isolate the CDE from the rest of the corporate network using firewalls, VLANs, or other controls, then only the segmented environment and its connected systems need to be assessed.

But segmentation is only effective if it's rigorously validated. PCI DSS specifically requires that segmentation controls be tested as part of the penetration test. The tester must confirm that systems outside the defined CDE genuinely cannot reach systems inside it. If segmentation fails during testing, the entire network may fall back into scope.

This is one of the most common and most costly scoping errors. Segmentation that looks correct on a diagram but isn't enforced in practice provides no scope reduction at all.

What Providers Need Before Testing Starts

A well-scoped PCI DSS penetration test requires preparation from both sides. Before testing begins, most providers will ask for:

• Network and data flow diagrams showing where cardholder data enters, moves through, and exits the environment.
• An asset inventory of in-scope systems, including servers, databases, applications, network devices, and endpoints within the CDE and connected-to systems.
• Details of exposed services: externally facing IP addresses, URLs, APIs, and remote access points.
• Segmentation documentation such as firewall rules, VLAN configurations, and controls defining the CDE boundary.
• Rules of engagement covering agreed testing windows, any off-limits systems, escalation contacts, and how critical findings will be handled during testing.
• Third-party information about managed services, hosted payment pages, or cloud environments that form part of the CDE or connect to it.

Clear, accurate documentation speeds up scoping and reduces the risk of testing the wrong things. If your diagrams are out of date, a good provider will flag this, but expect delays.

Third-Party Considerations

Modern payment environments often involve third parties: payment service providers, hosted checkout pages, cloud platforms, or managed service providers handling aspects of cardholder data processing. Under PCI DSS, responsibility for securing cardholder data doesn't transfer simply because a third party is involved. You remain accountable for ensuring that third-party components within your scope are appropriately secured and tested.

In practice, this means third-party management portals or admin interfaces connecting to your CDE may need to be included in scope. If a payment service provider hosts your checkout page, you should understand which PCI DSS requirements they cover and which remain yours, typically documented in a responsibility matrix. Cloud-hosted CDE components (virtual machines, containers, or managed databases on AWS, Azure, or GCP) are in scope too. The penetration test should cover the configuration and security of your environment within the cloud, even if the underlying infrastructure is the provider's responsibility.

Failing to account for third parties is a frequent scoping mistake and one that assessors will identify.

Internal and External Testing

PCI DSS requires both internal and external penetration testing. They serve different purposes.

External testing targets internet-facing systems within the CDE: web applications, APIs, VPN endpoints, firewalls, and other publicly accessible components. The goal is to determine whether an external attacker can breach the perimeter and access cardholder data.

Internal testing simulates a threat actor who already has a foothold inside the network, whether through a compromised workstation, a malicious insider, or lateral movement from a connected system. It assesses whether someone inside the network can reach the CDE, escalate privileges, or exfiltrate data.

Both perspectives are necessary. A test that only covers the external perimeter leaves a significant blind spot, given that threats also come from compromised insiders and supply chain risks.

What Reporting and Evidence to Expect

A PCI DSS penetration test report serves two audiences: the technical team responsible for remediation and the QSA who will review it for compliance purposes. Buyers should expect:

• Executive summary giving a high-level overview of scope, approach, key findings, and overall risk posture for non-technical stakeholders.
• Scope confirmation clearly stating which systems, networks, and applications were tested and why.
• Methodology describing the testing approach, tools used, and standards followed. Many UK providers align to CREST, OWASP, or PTES methodologies.
• Segmentation test results with specific evidence that segmentation controls were validated, including which tests were performed and their outcomes.
• Detailed findings where each vulnerability is described with its severity, evidence of exploitation (or attempted exploitation), affected systems, and remediation guidance. Findings should be reproducible.
• Remediation priorities breaking down which issues to fix first, based on risk severity and exploitability.

The report is a key deliverable for your PCI DSS assessment. If it lacks detail on methodology, scope, or segmentation validation, your QSA may not accept it as sufficient evidence.

Retesting: Verifying Remediation

PCI DSS doesn't just require that vulnerabilities be found. It requires that exploitable vulnerabilities be fixed and verified. Retesting is mandatory.

After the initial test, the organisation remediates the identified vulnerabilities. The testing provider then retests those specific findings to confirm they've been resolved. This should be documented in an updated or supplementary report for the QSA.

Clarify retesting terms before the engagement begins. How many rounds are included? Is retesting bundled in the price or charged separately? What's the timeframe after remediation? Will the retest report be standalone or an addendum?

For guidance on typical pricing structures, including retesting, see our overview of how much a pen test should cost.

Common Scoping Mistakes

Several scoping errors come up repeatedly in PCI DSS penetration testing engagements:

Assuming segmentation works without testing it. Network diagrams may show a segmented CDE, but if firewall rules are misconfigured or have drifted over time, segmentation may not hold. The penetration test must validate this.

Omitting shared services. Active Directory, DNS, NTP, backup infrastructure, and SIEM platforms often serve both the CDE and the wider network. If they connect to the CDE, they're typically in scope.

Ignoring third-party portals and services. Management interfaces for hosted services, cloud consoles, and payment provider dashboards can all provide an attack path into cardholder data.

Scoping only for external testing. PCI DSS explicitly requires both internal and external testing. Skipping the internal perspective leaves a major gap.

Using outdated documentation. If network diagrams and asset inventories don't reflect the current environment, the test may miss in-scope systems or waste time on systems that aren't.

Treating the test as a tick-box exercise. A minimal-effort test may look fine on paper but is unlikely to satisfy a thorough QSA review, and it certainly won't identify real risks.

Choosing a Provider in the UK

Selecting a penetration testing provider for PCI DSS work requires more scrutiny than a general-purpose security test.

Accreditation and independence. CREST accreditation is widely recognised in the UK and provides assurance of technical competence. The provider should also be organisationally independent from the team managing the environment being tested, as PCI DSS requires this.

PCI DSS experience. Ask how many PCI DSS tests they've delivered and whether their testers understand the specific scoping and segmentation requirements. Generic penetration testing experience is valuable but not sufficient on its own.

Methodology and reporting. Request a redacted sample report to assess quality. It should meet the evidence requirements outlined above and be structured for QSA review.

Segmentation testing capability. Confirm they have experience validating segmentation controls and can clearly document the results.

Retesting and support. Understand what retesting is included, how remediation support works, and whether the provider will liaise with your QSA if questions arise.

Scoping support. A good provider will help you define and validate scope before testing begins, rather than simply accepting whatever you provide.

Commercial transparency. Pricing should be clear and based on the agreed scope. Be cautious of providers who quote without understanding your environment. That often leads to either an inadequate test or unexpected costs.

A Note on Costs

The cost of PCI DSS penetration testing varies with the size and complexity of the CDE, the number of applications and external services, and whether segmentation testing is required. For context, IBM's 2024 Cost of a Data Breach Report put the average global breach cost at USD 4.88 million. That figure is a reminder that security testing matters beyond compliance.

That said, cost shouldn't be the primary selection criterion. A cheap test that fails to meet PCI DSS requirements, or that misses critical vulnerabilities, may cost far more through failed assessments, remediation delays, or actual incidents.

Final Thoughts

PCI DSS penetration testing is a specific, structured activity with clear requirements around scope, methodology, segmentation validation, and retesting. Getting it right takes careful preparation, honest scoping, and a technically capable provider who understands the standard.

If you're preparing for a PCI DSS assessment, start by reviewing your data flow diagrams, validating your segmentation assumptions, and engaging a provider early enough to allow for remediation and retesting before your deadline. Where specific compliance questions arise, consult your QSA. They're the authoritative voice on how the standard applies to your environment.