PCI DSS Requirement 11.4 requires penetration testing at least annually and after any significant change to the cardholder data environment, with a six-month cadence for segmentation testing at service providers. Compliance teams need to confirm scope covers the full CDE (external and internal), document a methodology and rules of engagement before testing starts, and retain retest evidence proving exploitable findings were fixed.
TL;DR:
- A vulnerability scan only flags possible weaknesses; a penetration test must attempt exploitation, and most assessments require both internal and external perspectives.
- Include connected systems that can affect card data security, such as domain controllers, backups, vendor access paths, VPNs, and payment APIs in scope.
- Representative sampling may suffice for straightforward networks, but complex or frequently changing environments may need testing across every network segmentation boundary.
- Internal staff may conduct tests if they are independent of the systems under review and demonstrate relevant experience; a Qualified Security Assessor credential is unnecessary.
Table of Contents
- Penetration testing versus vulnerability scanning: why the distinction matters
- What Requirement 11.4 specifically requires compliance teams to produce
- Scope and segmentation: defining the CDE and proving isolation works
- Methodology and tester qualifications: what assessors expect to see
- Remediation, retest, and when an assessor will accept a test as complete
- Reporting and evidence: what your assessor will want to review
- Pre-test checklist: getting ready before the tester arrives
- How Zero Through supports PCI penetration testing and compliance
- Priorities that matter more than checklist completion
- Ready to schedule your PCI penetration test?
- FAQ
- Sources
Penetration testing versus vulnerability scanning: why the distinction matters
A vulnerability scan flags potential weaknesses. A penetration test goes further: testers actively attempt to exploit those weaknesses to determine what an attacker could actually achieve, which is why PCI guidance treats the two as separate requirements rather than interchangeable activities. That distinction drives most of the confusion we see from compliance teams preparing for their first PCI assessment.
Several test types fall under the Requirement 11.4 umbrella, and most organizations need more than one:
- External testing probes internet-facing systems from outside the network perimeter.
- Internal testing simulates an attacker who has already gained a foothold inside the network.
- Application-layer testing targets payment applications, APIs, and web interfaces for logic flaws and injection vulnerabilities.
- Network-layer testing examines firewalls, routing, and protocol-level weaknesses.
- Segmentation testing verifies that out-of-scope systems cannot reach the cardholder data environment.
Most PCI assessments require both internal and external tests because attackers rarely stop at the perimeter. A compromised laptop, a phished credential, or a misconfigured VPN can put an internal attacker inside the network just as easily as an external one, so the standard treats both perspectives as necessary evidence.
What Requirement 11.4 specifically requires compliance teams to produce
Requirement 11.4 breaks down into a handful of concrete deliverables. Here is what an assessor expects to find when they review your testing program:
- A test performed at least once every 12 months and after any significant change, such as a new payment application, a network redesign, or a major infrastructure migration.
- Segmentation testing on a tighter clock for service providers, who must validate that segmentation controls isolate the CDE from out-of-scope systems every six months rather than annually.
- A documented methodology and rules of engagement that cover external, internal, and application-layer testing, agreed before the engagement begins rather than improvised during it.
- Evidence that exploitable findings were remediated and retested, because an assessor will not sign off on an annual cycle that ends with unverified high-risk findings sitting open.
Organizations moving between PCI DSS versions should treat this as a moving target rather than a one-time checklist exercise. PCI DSS v4.0.1 clarifications became mandatory as of March 31, 2025, and many organizations were still catching up on those future-dated requirements after the deadline passed. If your last penetration test was scoped against an older version of the standard, it is worth checking whether your methodology and segmentation testing cadence still line up with current expectations before your next assessment cycle.
The documentation burden here is often underestimated. An assessor is not just checking that a test happened. They are checking that the test was planned against a defined methodology, executed against an agreed scope, and followed through to a verified remediation state.
Scope and segmentation: defining the CDE and proving isolation works
Scoping mistakes cause more PCI pentest headaches than any technical finding. The cardholder data environment includes every system, process, and person that stores, processes, or transmits cardholder data, plus any connected system that could affect the security of that data. Getting this wrong in either direction creates problems: too narrow a scope leaves real attack paths untested, and too broad a scope wastes budget on systems that genuinely sit outside the CDE.
Start by mapping the full environment before you talk to a tester:
- Identify every system that directly handles card data, along with connected systems like domain controllers, jump boxes, and backup infrastructure.
- Map third-party and nested service-provider connections, including any vendor with persistent or on-demand access to in-scope systems.
- Document remote access paths such as VPNs, remote management tools, and administrative interfaces, since these are common attacker entry points.
- List external-facing APIs and web applications that touch payment data, even indirectly.
Segmentation testing is where scope reduction gets tested for real. If you rely on network segmentation to shrink your PCI footprint, that segmentation has to be validated through testing that confirms no connectivity exists between out-of-scope systems and the CDE. Representative sampling can work for straightforward environments, but complex or frequently changing networks often need full-layer testing across every segmentation boundary to produce evidence an assessor will accept.
Pro Tip: Keep a current network diagram that your tester can annotate directly. It turns scope disputes with your assessor into a five-minute conversation instead of a week of back-and-forth.
Methodology and tester qualifications: what assessors expect to see
Assessors look for a documented approach, not just a finished report. A credible methodology covers pre-engagement scoping, a defined testing approach (black-box, grey-box, or white-box depending on what you are trying to learn), and explicit coverage of both application-layer and network-layer techniques from external and internal vantage points.
Rules of engagement matter just as much as the technical approach:
- Test windows and communication protocols, so production incidents during testing get triaged correctly instead of triggering a false-alarm response.
- Data handling rules, including what happens if a tester encounters live cardholder data during the engagement.
- Source IP ranges and safety controls, so defensive teams can distinguish the authorized test from a genuine attack.
On tester qualifications, PCI guidance allows internal testers as long as they are organizationally independent of the systems being tested and can demonstrate relevant experience. The tester does not need to be a Qualified Security Assessor. What matters to an assessor is organizational separation and evidence of competence, not a specific certification on a resume.
Remediation, retest, and when an assessor will accept a test as complete
A penetration test is not finished when the report lands in your inbox. Exploitable findings have to be remediated, and then retested to confirm the fix actually closed the gap, before the cycle counts as complete.
- Remediate exploitable findings based on severity, prioritizing anything that gave the tester access to cardholder data or a path into the CDE.
- Retest the remediated items using the same or an equivalent technique that originally proved exploitation, not just a configuration review.
- Retain retest evidence showing the specific finding, the fix applied, and confirmation that the exploit path no longer works.
A frequently missed compliance failure is skipping the retest step entirely: an assessor will not accept an annual test as complete if significant exploitable findings remain unverified at the time of review.
Pro Tip: Build retest time into your original testing budget and calendar, not as an afterthought. A retest scheduled four to six weeks after the initial engagement gives remediation teams enough runway without letting the finding go stale.
Reporting and evidence: what your assessor will want to review
A PCI-ready penetration test report needs a specific set of components, and PCI SSC guidance is explicit about what belongs in it:
- Scope and methodology, stating exactly what was tested and how.
- Findings with proof-of-exploit evidence where exploitation succeeded, not just a vulnerability list.
- Remediation plans tied to each finding, with owners and target dates.
- Retest results confirming which findings were closed and which remain open.
- Segmentation validation artifacts, when scope reduction depends on segmentation controls.
If a tester encounters live cardholder data during the engagement, that data has to be secured immediately and the organization notified per the agreed rules of engagement, rather than retained in a report or test environment longer than necessary. Keep final reports and retest evidence in a controlled location your assessor can access during the review, with access limited to people who genuinely need it.
Pre-test checklist: getting ready before the tester arrives
Most testing delays come from scoping arguments and missing stakeholder sign-off, not technical surprises. A short checklist up front saves weeks later.
- Confirm CDE boundaries with every stakeholder, including nested service providers who touch in-scope systems.
- Document rules of engagement, authorized source IPs, test windows, and an incident contact who can be reached during the test.
- Prepare your remediation pathway before testing starts, so findings have an owner the day the report arrives.
- Flag fragile systems that need cautious testing or exclusion, with a documented rationale your assessor can review.
Service providers face a materially tighter clock than merchants: segmentation testing is required every six months rather than annually, which means the pre-test checklist above needs to run twice a year, not once, for any organization that fits that category.
How Zero Through supports PCI penetration testing and compliance
We deliver penetration testing scoped to map directly onto Requirement 11.4 deliverables: a documented methodology and rules of engagement agreed before testing begins, external and internal coverage, and a report built around findings, exploit evidence, remediation guidance, and retest results rather than a raw vulnerability dump.
Where scope extends beyond the test itself, our IT security audit work adds broader evidence of control effectiveness, and our managed SIEM and SOC services give teams visibility into what happens after remediation, including detection coverage that supports the next testing cycle. Engagements can scale across multi-location environments, with practical remediation guidance delivered in terms a compliance team can act on immediately rather than a generic finding list that needs translation before anyone can use it.
Priorities that matter more than checklist completion
Accurate scoping and genuine segmentation verification matter more than ticking a box that says a test happened. We see organizations treat the annual penetration test as a calendar event, when the real compliance risk sits in untested connected systems and segmentation controls nobody has actually validated end to end.
Remediation and retest deserve the same budget and timeline weight as the test itself. A finding left open because the retest got squeezed out of the schedule is a gap an assessor will catch, and a gap an attacker might find first. Bring your assessor into the conversation early on evidence expectations rather than after the report is finished.
— Shirish
Ready to schedule your PCI penetration test?
A typical engagement with us starts with a scoping call to confirm your CDE boundaries and testing objectives, followed by a proposal that lays out methodology, timeline, and cost. From there we move into test delivery, a remediation tracking phase where findings get prioritized and assigned, and a scheduled retest that closes the loop with evidence your assessor can review directly.
If your last test is approaching its 12-month mark, or your segmentation controls have not been validated recently, reach out through our penetration testing page to get a scoping call on the calendar, or visit Zero Through to see how our broader security services fit around your compliance calendar.
FAQ
How often does PCI DSS require penetration testing?
PCI DSS Requirement 11.4 requires a penetration test at least once every 12 months and after any significant change to the cardholder data environment. Service providers face a tighter cadence for segmentation testing specifically, which must be performed every six months rather than annually.
What qualifies as a proper penetration test under PCI DSS?
A proper PCI penetration test attempts to exploit vulnerabilities to determine real-world impact, covering both application-layer and network-layer techniques from external and internal perspectives. This goes beyond a vulnerability scan, which only identifies potential weaknesses without attempting exploitation.
Can internal staff perform PCI penetration tests?
Yes, internal testers are acceptable under PCI guidance as long as they are organizationally independent of the systems being tested and can demonstrate relevant experience. The tester does not need to hold a specific certification, but an assessor will expect evidence of competence and separation from the teams responsible for the systems tested.
Is PCI compliance legally required?
PCI DSS compliance is a contractual requirement imposed by payment card brands and acquiring banks rather than a government law in most jurisdictions. Organizations that handle card data agree to it through their merchant or processing agreements, and failing to comply can lead to contractual penalties, increased fees, or loss of card processing privileges rather than direct legal prosecution.
What changed with PCI DSS v4.x requirements for penetration testing?
PCI DSS v4.0.1 clarifications became mandatory as of March 31, 2025, and organizations should confirm their testing methodology and segmentation validation approach still align with the current version. Many organizations were still adjusting their programs to these future-dated requirements after the deadline passed, so it is worth reviewing your last test scope against the current standard.
Sources
- Penetration Testing Guidance v1.1
- Penetration testing (Information Supplement 11.3)
- Now is the time for organizations to adopt the future-dated requirements of PCI DSS v4.x
