PCI DSS Penetration Testing Requirements: The Complete Guide for 2026

PCI DSS is the most prescriptive major compliance framework when it comes to penetration testing. While other standards leave testing frequency and methodology to the organization's judgment, PCI DSS 4.0 specifies exactly what tests must be run, how often, and what they must cover. If you store, process, or transmit cardholder data — or if your systems could affect the security of the cardholder data environment (CDE) — these requirements apply to you.

What PCI DSS 4.0 Requires: Section 11.4

PCI DSS version 4.0 became the only active standard in March 2025, replacing version 3.2.1. Section 11.4 states that "external and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected."

In concrete terms, this means:

• Annual external penetration test: covers internet-facing systems that interact with or could affect the CDE — web applications, APIs, firewalls, and remote access points.
• Annual internal penetration test: covers systems within the network that could be used for lateral movement to reach cardholder data.
• Segmentation testing: any organization using network segmentation to reduce PCI scope must verify that segmentation controls work and cannot be bypassed. Service providers must test segmentation every six months; other entities annually.
• Application-layer testing: must cover vulnerabilities listed in PCI DSS 6.2.4, including injection flaws, broken authentication, cross-site scripting, and insecure direct object references.
• Post-significant-change testing: any significant infrastructure or application change requires penetration testing before the change goes into production — or promptly after, with documented risk justification.

Defining Your CDE: Getting Scope Right

One of the most important steps before any PCI DSS penetration test is correctly scoping the cardholder data environment. A scope that is too narrow misses real attack paths; a scope that is too broad wastes budget.

The CDE includes all system components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus all systems that are connected to or could affect the security of those components. This typically includes:

• Payment terminals and point-of-sale systems
• E-commerce platforms and payment gateways
• Servers running payment applications
• Network devices (firewalls, switches, routers) that form the CDE boundary
• Authentication systems (Active Directory, SSO) used by CDE-privileged accounts
• Third-party integrations that have connectivity to CDE components

Scope reduction through segmentation is one of the most effective ways to reduce PCI DSS compliance costs — but the segmentation must be verified to hold under attack. Q-Sec's penetration testing service includes segmentation validation as a standard component of PCI DSS engagements.

PCI DSS Penetration Testing Methodology

PCI DSS 4.0 requires a documented penetration testing methodology. Industry-standard methodologies that satisfy this requirement include:

• PTES (Penetration Testing Execution Standard)
• OWASP Testing Guide (for application-layer testing)
• NIST SP 800-115 (Technical Guide to Information Security Testing)

The methodology must be applied consistently, documented, and available for review by a Qualified Security Assessor (QSA) during your PCI DSS assessment. Q-Sec provides methodology documentation as part of every engagement deliverable.

What the PCI DSS Penetration Test Report Must Include

The test report is the primary evidence artifact for your QSA. It must include:

• Test scope: systems tested, testing period, tester credentials
• Methodology used: which standard was followed
• Findings: all identified vulnerabilities, severity ratings, and evidence
• Exploitation results: documentation of which vulnerabilities were successfully exploited and what access was obtained
• Remediation recommendations: specific, actionable guidance for each finding
• Re-test results: confirmation that critical findings have been remediated (or formal risk acceptance with documentation for findings not remediated)

Q-Sec's reports are structured to meet QSA expectations directly. We have supported organizations through PCI DSS Level 1 and Level 2 assessments and understand what QSAs ask for. Reports are delivered in both technical detail (for your engineers) and executive summary format (for your QSA and management).

PCI DSS and ISO 27001: Running Combined Engagements

Many organizations subject to PCI DSS are also pursuing or maintaining ISO 27001 certification. The two frameworks share significant overlap in penetration testing requirements:

• Both require annual testing as a minimum
• Both require findings to feed into risk management processes
• Both require documented remediation tracking

A well-scoped engagement can generate evidence for both frameworks simultaneously. Read our ISO 27001 penetration testing guide for the control mapping that makes this work. Q-Sec's compliance team can structure a single test program that satisfies PCI DSS Section 11.4 and ISO 27001 Annex A in one engagement.

Frequently Asked Questions

Does PCI DSS require a third-party tester?

PCI DSS does not explicitly mandate third-party penetration testers. However, it requires testers to be qualified and organizationally independent of the systems being tested. For most organizations, this means either using an external provider or a clearly independent internal security team. QSAs will scrutinize tester qualifications and independence. For Level 1 merchants and service providers, external testing from a recognized provider eliminates questions about independence.

What is the difference between a vulnerability scan and a penetration test for PCI DSS?

PCI DSS requires both — and they are not interchangeable. Vulnerability scans (required quarterly under Section 11.3) identify known weaknesses through automated tools. Penetration tests (required annually under Section 11.4) go further: testers actively attempt to exploit identified vulnerabilities to demonstrate real-world risk. QSAs distinguish sharply between the two. Submitting scan reports when a pentest is required is a common compliance gap.

How does Q-Sec handle post-test remediation support?

Q-Sec provides remediation guidance as part of every engagement report. For organizations that want active remediation support, our IT infrastructure services team can assist with patch management, configuration hardening, and network architecture adjustments. We also offer re-test engagements to formally close findings and provide QSA-ready evidence of remediation.