The short answer
PCI compliance penetration testing is required by PCI DSS Requirement 11.4: an internal and an external PCI pen test at least once every 12 months and after any significant change, including application-layer testing. If segmentation reduces your scope, it must be tested every 12 months, or every 6 months for service providers. Exploitable findings must be fixed and retested.
On this page
- What are the PCI DSS penetration testing requirements?
- What is PCI testing? Scans, pen tests and segmentation tests
- What does a PCI penetration test cover?
- What is PCI segmentation testing?
- Which SAQ types need a penetration test?
- How often is PCI DSS penetration testing required?
- What should a PCI penetration test report include?
- Black box, grey box or white box: which does a PCI pen test need?
- How does PCI penetration testing fit your QSA assessment?
- How much does a PCI pen test cost?
- Why Sovereign Secure for PCI DSS penetration testing
- Get a PCI DSS penetration testing quote
PCI DSS penetration testing, also called PCI pen testing or PCI compliance penetration testing, is the manual testing Requirement 11.4 of PCI DSS v4.0.1 demands: internal and external tests of your cardholder data environment (CDE) at least every 12 months and after any significant change, application-layer testing, and proof that any segmentation you rely on isolates the CDE. Exploitable findings must be fixed and retested.
Sovereign Secure is a PCI SSC-approved Qualified Security Assessor (QSA) company. We scope each test against the sub-requirement your assessor will check, and report so the evidence drops straight into your SAQ or Report on Compliance (ROC). It is part of our PCI DSS compliance services.
What are the PCI DSS penetration testing requirements?
Requirement 11.4 has seven parts (11.4.1 to 11.4.7). In plain English:
| Sub-requirement | What it asks for | Applies to | Frequency |
|---|---|---|---|
| 11.4.1 Methodology | A documented, industry-accepted approach covering the CDE perimeter and critical systems, inside and outside, at application and network layers; results kept for 12 months | Everyone validating 11.4 | Kept current |
| 11.4.2 Internal test | Testing from inside your network towards the CDE | Merchants and service providers | Every 12 months and after significant change |
| 11.4.3 External test | Testing of the internet-facing perimeter and exposed services | Merchants and service providers | Every 12 months and after significant change |
| 11.4.4 Fix and retest | Exploitable vulnerabilities corrected according to your risk ranking (Req. 6.3.1), then retested | Everyone | After every test |
| 11.4.5 Segmentation | Proof that segmentation controls isolate the CDE from all out-of-scope systems | Anyone using segmentation to reduce scope | Every 12 months and after segmentation changes |
| 11.4.6 Segmentation (service providers) | As 11.4.5, but more often | Service providers | Every 6 months and after segmentation changes |
| 11.4.7 Multi-tenant support | Help customers carry out their own external testing | Multi-tenant service providers | Mandatory since 31 March 2025 |
Three details catch people out. The tester must be qualified and organisationally independent, but need not be a QSA or Approved Scanning Vendor (ASV). Application testing must cover at least the attack types in Requirement 6.2.4, such as injection, access control and business logic. And the methodology must consider threats from the last 12 months. The PCI SSC’s Penetration Testing Guidance information supplement sets out what assessors expect.
What is PCI testing? Scans, pen tests and segmentation tests
PCI testing is the regular security testing PCI DSS Requirement 11 asks for: vulnerability scans, penetration tests, segmentation tests and wireless checks, each producing evidence for your SAQ or Report on Compliance. The four parts are:
- Vulnerability scans (11.3). Internal scans at least every three months by a qualified internal or external resource (11.3.1), and external scans at least every three months by a PCI SSC Approved Scanning Vendor (11.3.2). We run internal vulnerability scanning and deliver ASV scans through our PCI SSC Approved Scanning Vendor partner.
- Penetration tests (11.4.1 to 11.4.4). Manual internal, external and application-layer testing every 12 months and after significant change, with exploitable findings fixed and retested. This is the focus of this page.
- Segmentation tests (11.4.5 and 11.4.6). Proof that out-of-scope networks cannot reach the CDE, every 12 months for merchants and every 6 months for service providers.
- Wireless checks (11.2). Testing for authorised and unauthorised wireless access points at least every three months, whether or not you use wireless in the CDE. Our wireless penetration testing service includes these rogue access point checks, and our wireless security audit checklist covers what to review in between.
Requirement 11 also covers intrusion and change detection (11.5) and payment page tamper detection (11.6). Scans and tests are planned together, so dates and scope line up. A penetration test is also a practical check on your logging: compare the testers’ timeline with your alerts to see whether your PCI DSS Requirement 10 logging and monitoring caught them.
Testing is not the same as validating compliance. It produces evidence for your SAQ or Report on Compliance; validation comes from the SAQ itself or from a PCI compliance audit. For a quick view of how ready you are before you book anything, try our free PCI compliance test.
What does a PCI penetration test cover?
The routes an attacker would take to card data, each mapped to its sub-requirement:
| Area | What we look at | Maps to |
|---|---|---|
| External perimeter | Internet-facing IPs, firewalls, VPN and remote access, web servers in or connected to the CDE | 11.4.3 |
| Internal network | Starting from a corporate foothold: Active Directory, lateral movement and paths into CDE systems and databases | 11.4.2 |
| Segmentation controls | Firewall rules, VLAN access lists and cloud security groups, tested from every out-of-scope segment | 11.4.5 / 11.4.6 |
| Payment applications and APIs | Manual testing following the OWASP Web Security Testing Guide, including authentication, authorisation and business logic | 11.4.1, 6.2.4 |
| E-commerce pages | The servers and code that deliver or redirect to your payment form | 11.4.3 |
| Card-present estates | Store and POS networks; POS and PIN device testing where needed | 11.4.2 / 11.4.5 |
Network work follows our infrastructure penetration testing method and application work our web application penetration testing service, in one engagement. Where customers pay through your own iOS or Android app, our mobile app penetration testing covers the app and the APIs behind it.
What is PCI segmentation testing?
Segmentation testing proves that systems outside your CDE cannot reach it. Without effective segmentation, your whole network is in PCI DSS scope.
From each out-of-scope network, we scan TCP and UDP ports towards the CDE ranges and compare the results with your approved, documented flows. Any unexpected route is a failure to fix and retest. Merchants repeat this every 12 months and service providers every 6 months, plus after any change to the controls; our guide to PCI DSS for service providers covers the other requirements that apply only to them. Our PCI DSS scoping guide explains how to draw the boundary first, and our guide to PCI network segmentation shows how to design it.
Which SAQ types need a penetration test?
It depends on which SAQ you complete, or whether you need a ROC:
| Validation | Typical PCI penetration testing scope | Segmentation test |
|---|---|---|
| SAQ A (full redirect or iframe) | No penetration testing in the SAQ. If your site builds the payment form (direct post or JavaScript), you are likely SAQ A-EP | Not in SAQ |
| SAQ A-EP | External test and application testing of the web servers and site that deliver or affect the payment page | If segmentation limits scope |
| SAQ B-IP or SAQ C | No internal or external penetration test in the SAQ | Every 12 months, if segmentation reduces scope (11.4.5) |
| SAQ D merchant or ROC merchant | Internal and external tests of the CDE and connected systems, plus payment applications and APIs | Every 12 months, if segmentation reduces scope |
| Service provider (SAQ D or ROC) | As above, across the whole service environment, including customer-facing APIs; multi-tenant providers also need an 11.4.7 process | Every 6 months, if segmentation reduces scope |
How often is PCI DSS penetration testing required?
At least every 12 months and after any significant change. Scanning runs on its own cycle:
| Activity | Requirement | Minimum frequency | Performed by |
|---|---|---|---|
| Internal and external penetration test | 11.4.2, 11.4.3 | 12 months and after significant change | Qualified, independent tester |
| Segmentation test | 11.4.5 / 11.4.6 | 12 months (merchants) or 6 months (service providers) | Qualified, independent tester |
| Internal vulnerability scan | 11.3.1 | Every 3 months and after significant change | Qualified internal or external resource |
| External vulnerability scan | 11.3.2, 11.3.2.1 | Every 3 months (ASV), and after significant change | A PCI SSC Approved Scanning Vendor for the quarterly scans |
PCI DSS guidance gives examples of significant change: new or replaced CDE systems, changes to how account data flows or is stored, a new CDE boundary, and changes to supporting infrastructure or service providers. An ASV scan is not a penetration test; we deliver quarterly ASV scans through our PCI SSC Approved Scanning Vendor partner.
What should a PCI penetration test report include?
- Executive summary for management: overall risk and status per sub-requirement.
- Technical findings with CVSS scores, reproduction steps and remediation advice, ready for your 6.3.1 risk ranking.
- Segmentation results: every segment tested, ports and protocols checked, pass or fail.
- Methodology and independence statement covering the 11.4.1 methodology and the tester independence that 11.4.2, 11.4.3 and 11.4.5 require.
- Retest of remediated findings, with a letter confirming exploitable issues are closed (11.4.4).
Every report includes an evidence map, laid out like this:
| PCI DSS sub-requirement | Where the evidence sits |
|---|---|
| 11.4.1 Methodology | Methodology section: approach, standards, threats considered |
| 11.4.2 / 11.4.3 Internal and external | Findings sections: scope, dates, results |
| 11.4.4 Remediation | Retest section and retest letter |
| 11.4.5 / 11.4.6 Segmentation | Segmentation section: results per segment |
Black box, grey box or white box: which does a PCI pen test need?
Grey box or white box, in practice. PCI DSS v4.0.1 does not name an approach, but Requirement 11.4.1 expects the test to cover the entire CDE perimeter and critical systems, from inside and outside the network, and 11.4.5 expects every segmentation control to be checked. A tester can only do that if they know where the CDE is.
| Approach | What the tester is given | Where it fits in a PCI pen test |
|---|---|---|
| Black box | Little or nothing beyond target addresses or URLs | Shows what an outsider can find on your perimeter, but on its own can miss in-scope systems, which an assessor comparing scope with your CDE diagram will notice |
| Grey box | CDE IP ranges, network and data-flow diagrams, and accounts for each application role | The usual choice: internal, external, application and segmentation testing aimed at the documented scope |
| White box | Full documentation and configurations, and often source code | The deepest option for bespoke payment applications, often combined with source code review |
The PCI SSC’s Penetration Testing Guidance supplement describes all three approaches. Our guide to black box vs white box penetration testing compares coverage, realism and cost in more detail.
How does PCI penetration testing fit your QSA assessment?
Test early enough to fix and retest before your assessment. Your assessor will compare the test scope with your network and data-flow diagrams, read the methodology and ask for retest evidence.
Common reasons assessors reject pen test evidence:
- the scope misses systems shown on the CDE diagram;
- segmentation was tested from only some out-of-scope networks;
- there is no retest evidence for exploitable findings;
- the test is more than 12 months old;
- the tester was not independent, for example the administrator who manages the firewall.
If we also carry out your PCI DSS audit, we plan both together so dates and scope line up.
How much does a PCI pen test cost?
Cost follows scope, so we quote a fixed price after scoping. The main drivers:
| Cost driver | Why it changes the effort |
|---|---|
| External IP addresses and exposed services | Each live host and service must be tested |
| Internal CDE hosts and network segments | More segments mean more segmentation paths to prove |
| Web applications, APIs and user roles | Application testing is manual and scales with functionality |
| Segmentation frequency | Service providers test segmentation twice a year |
| Card-present estate | Store networks and POS or PIN devices add test time |
A published UK pricing guide we reviewed in September 2026 put typical penetration tester day rates at about £1,000 to £1,500. Treat that as a market indication, not our price. For whole-programme budgets, see PCI compliance cost.
Why Sovereign Secure for PCI DSS penetration testing
- An assessor company that also tests. We are a PCI SSC-approved QSA, Qualified PIN Assessor (QPA), Card Production Security Assessor (CPSA), P2PE Assessor and 3DS Assessor company, and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.
- Every layer in one team. Network, web, API, cloud, mobile, wireless and hardware testing, including POS and PIN devices.
- Certified ourselves. ISO 27001 certified, and an IASME-licensed Cyber Essentials certification body.
- UK head office, international reach. Based in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka. Clients include Fiserv, Cashplus, Ticketmaster and Ahli United Bank.
Get a PCI DSS penetration testing quote
Send your CDE diagram, the number of external IPs, internal segments and applications, and your SAQ type or ROC date, and we will reply with a fixed scope and price. Use our penetration testing quote form or call +44 161 523 5276.
Last reviewed October 2026 by the Sovereign Secure assessment team.
