PCI DSS Penetration Testing Requirements

PCI DSS Requirement 11.3 (and its v4.0 replacement, Requirement 11.4) mandates that every entity that stores, processes, or transmits cardholder data must conduct penetration testing on external systems, internal systems, segmentation controls, and applications at least annually, and after any significant change to the environment. This applies regardless of transaction volume, so a small merchant using a hosted payment page and a large service provider processing millions of card transactions both fall within scope, though the depth of testing required will differ.

Requirement 11 sits within the "Regularly Test Security Systems and Processes" pillar of the 12-requirement PCI DSS framework. Where Requirements 1 to 10 focus on building and maintaining secure systems (firewalls, encryption, access control, logging), Requirement 11 exists to verify those controls actually work in practice. Penetration testing is the mechanism that proves this, rather than simply asserting it.

PCI DSS penetration testing is not optional for any entity that falls within scope. A QSA cannot sign off a Report on Compliance (RoC) or a Self-Assessment Questionnaire (SAQ) that requires 11.3/11.4 evidence without a valid, dated penetration test report covering the required scope.

The security intent between the two versions is unchanged: annual, independent, scope-appropriate penetration testing. What changed is the internal structure and numbering of the sub-requirements, which is why organisations mid-transition between versions often see references to both 11.3 and 11.4 in different documents from the same assessor.

PCI DSS is not the only framework that expects security testing, though it is the most prescriptive about frequency and scope. Frameworks such as NIST SP 800-53 recommend penetration testing as part of a broader control assessment, and SOC 2 examinations often request testing evidence to satisfy the security trust principle, but neither dictates the annual cycle, the segmentation-specific testing, or the sub-requirement structure that PCI DSS enforces. Organisations managing multiple compliance programmes can often use one well-scoped penetration test to satisfy several frameworks at once, provided the test scope and reporting are broad enough to cover each framework's specific evidentiary requirements.

The Sub-Requirements of 11.3: External, Internal, Segmentation, and Application-Layer Testing

Requirement 11.3/11.4 is not a single test; it is four distinct testing obligations, each with its own scope and trigger conditions. A business that runs one annual external scan and calls it "PCI penetration testing" is very likely non-compliant, because internal, segmentation, and application-layer coverage are each assessed separately.

Read across all four sub-requirements together, not in isolation, when auditing your own coverage. A common gap is having a strong external testing history but no documented segmentation test, which is one of the most frequently cited findings in failed PCI assessments.

Frequency Requirements: Annual, Six-Monthly, and After Significant Change

PCI DSS sets a minimum testing frequency of once every 12 months for external, internal, and standard segmentation testing, with one accelerated cycle for service providers. The 12-month clock resets from the date of the last completed test, not the calendar year, so a report dated March one year needs a follow-up test by March the next.

"Significant change" is the trigger most organisations misjudge. A change is significant if it materially alters the attack surface or the architecture of the CDE; examples include adding a new network segment, launching a major application release that touches payment functionality, changing core firewall or routing rules, onboarding a new third-party integration with access to cardholder data, or migrating part of the CDE to a new cloud environment. Routine patching, minor UI updates, or configuration changes that do not alter the architecture or data flow generally do not trigger a retest, though this judgement should be documented rather than assumed, since a QSA will ask how the "no retest needed" decision was reached.

Defining Test Scope: The Cardholder Data Environment and Connected Systems

Scope, in PCI DSS terms, is every system that stores, processes, or transmits cardholder data plus every system connected to or capable of impacting the security of that environment. This includes the obvious systems, payment gateways, POS terminals, card-data databases, and the less obvious ones that still qualify: authentication servers, jump boxes, logging infrastructure, backup systems, and any third-party or cloud service with a network path into the CDE.

Scope confusion is the single most common reason organisations fail this requirement at assessment. A test that only covers the payment application but ignores the supporting authentication and network infrastructure will not satisfy 11.3/11.4, even if the application itself passes cleanly. Before commissioning a test, an organisation should be able to produce a current network diagram showing the CDE boundary, all connected systems, and where segmentation controls are supposed to enforce that boundary. Any system missing from that diagram is a system a tester cannot be asked to cover, and a gap a QSA will find.

Who Can Perform the Test? Tester Qualification and Independence

PCI DSS requires the tester to be "qualified," meaning they must have demonstrable penetration testing skill and experience, and they must be organisationally independent from the team responsible for building and maintaining the systems under test. This does not require a specific mandatory certification by name, but assessors expect evidence of competence, commonly demonstrated through recognised industry certifications such as CREST, OSCP, GPEN, or CHECK-scheme accreditation, alongside a documented track record of similar engagements.

Internal staff can technically perform the test if they are demonstrably independent of the systems being assessed and can evidence appropriate skill, but in practice this is difficult to prove for smaller organisations where the security team also manages the infrastructure. Most organisations use an external provider specifically to remove any doubt about independence, since a QSA reviewing the evidence will ask direct questions about the tester's reporting line and day-to-day responsibilities if the test was performed in-house.

Penetration Testing vs Vulnerability Scanning Under PCI DSS

Vulnerability scanning and penetration testing are two separate, mandatory obligations under PCI DSS, and satisfying one does not satisfy the other. Scanning is an automated process that identifies known vulnerabilities against a signature database; penetration testing is a human-led, authorised attempt to exploit weaknesses, chain them together, and demonstrate real business impact.

Both are needed because they answer different questions. Scanning tells you what known weaknesses exist across your estate on a regular cycle; penetration testing tells you whether those weaknesses, and any unknown or logic-based flaws, can actually be exploited to reach cardholder data.

Preparing for Your PCI DSS Penetration Test

Preparation determines whether a test runs to schedule and produces evidence a QSA will accept without follow-up questions. Before the test window opens, the compliance owner should confirm the following with the testing provider and internal stakeholders.

• Confirm the exact CDE boundary and connected systems to be tested, backed by a current network diagram.
• Identify which sub-requirements this engagement is intended to satisfy (external, internal, segmentation, application-layer, or a combination).
• Arrange test account access, VPN or network access, and any application credentials needed for authenticated testing.
• Notify relevant internal teams (network operations, application owners, third-party vendors) of the test window to avoid false-positive security alerts.
• Confirm the reporting format required by your QSA in advance, so the final report does not need reformatting before submission.
• Retain the previous year's report and remediation evidence, since assessors often compare year-on-year testing history.

Remediation and Retesting Requirements

Retesting under PCI DSS is targeted, not a full repeat of the original engagement. Once exploitable vulnerabilities are identified, the organisation must remediate them according to assessed risk, and the tester then verifies the specific fixes, rather than re-running the entire scope from scratch.

A QSA will expect documented evidence that each finding was addressed, typically a short retest confirmation or an updated report section showing the vulnerability was retested and closed. High and critical-severity findings are generally expected to be remediated and verified before the RoC or SAQ is finalised; lower-severity findings may be accepted with a documented remediation plan and timeline, depending on the QSA's judgement. Reports older than 12 months, or reports with open critical findings and no remediation evidence, are two of the most common reasons a QSA rejects submitted evidence.

Common Reasons Organisations Fail This Requirement

Most PCI DSS penetration testing failures trace back to a small number of recurring issues rather than genuinely obscure technical gaps.

• Incomplete scope coverage, such as testing the payment application but omitting connected infrastructure, authentication systems, or third-party integrations.
• Missing segmentation testing, especially among service providers who assume the six-monthly rule does not apply to them.
• Lack of tester independence, where an internal team member with operational responsibility for the systems performed the test.
• No application-layer testing, relying solely on network-layer results despite running custom payment-facing applications.
• Stale reports, where the most recent test is older than 12 months by the time of assessment.
• Unresolved findings, where critical or high-severity vulnerabilities remain open with no documented remediation plan or verification.

Each of these is preventable with clear scope definition, an independent qualified tester, and a testing calendar that runs ahead of the assessment date rather than reactively around it.

Choosing a Provider for PCI DSS-Compliant Penetration Testing

A provider suitable for PCI DSS work must be able to demonstrate independence from your systems, evidence relevant qualifications and methodology (commonly aligned to standards such as NIST SP 800-115, PTES, or the OWASP Testing Guide for applications), and produce reports structured in a way your QSA will accept without rework. Ask directly whether the provider has produced PCI-specific reports before, since a generic security report and a PCI-aligned report are not interchangeable; the latter needs to map findings explicitly against the sub-requirements your assessor will be checking.

Engagement scope and effort are driven primarily by the number of external IPs, internal hosts, and applications in scope, the complexity of the segmentation to be verified, and how many sub-requirements are being tested in a single engagement versus staggered across the year. A provider should be able to explain how these factors shape the proposed scope and timeline for your specific environment before quoting, rather than pricing on a flat per-test basis.

A PCI DSS-aligned report should typically include:

• An executive summary suitable for non-technical stakeholders and the QSA.
• The methodology and standards followed (e.g., NIST SP 800-115, PTES, OWASP).
• Detailed findings mapped explicitly to the sub-requirement each result satisfies.
• Risk ratings and business impact for each finding.
• Remediation guidance and evidence of retesting for closed findings.

Organisations that need external, internal, segmentation, or application-layer testing performed by an independent, qualified team can review the penetration testing services available for compliance-driven engagements, including PCI DSS audits, to confirm scope, methodology, and reporting fit before committing to a test date.

Frequently Asked Questions