PCI DSS Penetration Testing Requirements: What Enterprises Actually Need for Compliance
Getting PCI DSS Requirement 11.4 Right From the Start Enterprises often know they need PCI compliance penetration testing but remain uncertain about what makes a test compliant. PCI DSS v4.0.1 Requirement 11.4 involves considerably more than scheduling an annual external assessment. Scope, internal and external testing, methodology, tester qualifications, segmentation validation, remediation, retesting, and evidence all influence whether the work will satisfy assessor scrutiny. This guide explains what enterprise security and compliance teams should have in place before their next PCI DSS assessment. Introduction PCI DSS v4.0.1 Requirement 11.4 requires documented internal and external penetration testing, generally at least annually and after significant changes. Segmentation controls need separate testing where segmentation reduces cardholder data environment scope, and service providers face a shorter six-month cycle. Vulnerability scanning does not replace penetration testing, and exploitable findings need correction and retesting. Confirm your exact obligations with your QSA before treating any single testing model as sufficient evidence.
Key Takeaways
- PCI DSS testing must cover both internal and external attack paths where applicable to the environment.
- A documented testing methodology is part of the compliance obligation, not optional paperwork attached after the fact.
- Significant infrastructure, application, or system changes can trigger testing outside the annual cycle.
- Segmentation testing is required whenever segmentation is used to reduce cardholder data environment scope.
- Scanning and penetration testing answer different questions, and neither substitutes for the other.
- Audit-ready reporting, documented remediation, and successful retesting are essential parts of the PCI penetration testing lifecycle.
Enterprises that treat these as separate, documented obligations make it easier for assessors to trace the evidence. Those that don’t often find gaps only after an assessment has already started.
Is Penetration Testing Required for PCI DSS Compliance?
Yes, for entities to which Requirement 11.4 applies. PCI DSS v4.0.1 addresses internal and external penetration testing, testing frequency, tester qualifications, remediation, and segmentation validation. Exact applicability depends on the entity’s environment and validation method, so organizations should confirm their scope and evidence requirements with their Qualified Security Assessor.
The PCI Security Standards Council confirmed that v4.0.1 clarified existing wording without adding or removing requirements, and the underlying Requirement 11.4 penetration testing obligations already existed in the prior version of the standard. That said, applicability still depends on the organization’s environment, validation method, and the relevant Self-Assessment Questionnaire or Report on Compliance.
Not every merchant follows an identical path, and the scope of the cardholder data environment shapes what gets tested and how often. A pentest report on its own does not automatically demonstrate that every PCI DSS requirement has been satisfied elsewhere in the standard. The current version of PCI DSS, along with the full library of supporting guidance, sits in the PCI SSC Document Library.
Enterprises that want testing built around penetration testing for compliance frameworks, rather than a generic annual scan, can reduce clarification requests during an assessment. Synack positions this work around on-demand assessments with reporting designed to support evidence requirements across frameworks and regulated security programs, including PCI DSS, SOC 2, HIPAA, and FedRAMP.
Compliance note: Organizations should confirm testing scope, evidence, and assessor expectations with their Qualified Security Assessor before relying on any single testing model.
What Does PCI DSS Requirement 11.4 Actually Require?
Requirement 11.4 breaks into several sub-requirements that an assessor checks directly, covering methodology, internal and external testing, remediation, and segmentation. The table below summarizes what each area expects at a practical level.
| Requirement area | What the enterprise needs to address |
| Testing methodology | A defined and documented penetration testing methodology |
| Internal testing | Testing of relevant internal systems and attack paths |
| External testing | Testing of externally accessible systems and attack paths |
| Frequency | At least annually and after significant changes, where applicable |
| Segmentation | Validation that segmentation controls effectively isolate the CDE |
| Tester qualifications | Testing by a qualified internal or external resource |
| Independence | Appropriate organizational independence from the systems being tested |
| Remediation | Correction of exploitable vulnerabilities and security weaknesses |
| Retesting | Follow-up testing to verify that remediation was effective |
| Evidence | Reports and records suitable for compliance validation |
None of these areas function in isolation. A methodology without independence, or testing without documented remediation, may leave gaps in the compliance evidence even if the annual test technically occurred.
How Often is PCI Penetration Testing Required?
Frequency depends on more than one trigger, and enterprises that treat the calendar as the only clock tend to miss the second one.
At least once every 12 months
Annual testing is generally the minimum cadence for applicable internal and external penetration testing. However, “annually” should not be read as “security only needs testing once a year.” It sets a floor, not a target.
After a significant change
Applicable internal and external penetration testing must also be performed after a significant infrastructure or application upgrade or change. PCI guidance describes significant changes as context-dependent, and examples typically include:
- Major application releases
- New internet-facing systems
- Significant network architecture changes
- Cloud migrations
- New authentication or payment flows
- Major firewall or segmentation changes
- New system components within or connected to the CDE
- Acquisitions or integrations that alter the attack surface
The organization itself should define and document how it determines whether a particular change counts as significant, since that judgment call provides a documented basis for assessor review.
Segmentation testing frequency
Where segmentation isolates the cardholder data environment, applicable segmentation controls must be tested. For most entities, that means at least every 12 months and after changes to segmentation controls or methods. Service providers carry an additional obligation to test segmentation at least every six months and after changes. Readers should verify which requirements apply to their specific environment and validation method with their QSA.
What Systems Must be Included in a PCI DSS Penetration Test?
Scope should reflect realistic attack paths, not a list of IP addresses copied from last year’s report. That distinction matters more than it sounds, since a technically polished report built on stale scope can still fail to test the organization’s actual exposure. Systems typically in scope include the cardholder data environment itself, systems that store, process, or transmit payment account data, connected-to systems, external-facing assets, internal network paths, web applications and APIs, authentication systems, cloud infrastructure, wireless networks where relevant, and segmentation controls.
Before testing begins, a practical scoping checklist helps confirm nothing material has been missed:
- Current asset inventory
- Current data-flow diagrams
- CDE boundaries
- Internet-facing assets
- Internal trust relationships
- APIs and payment integrations
- Cloud accounts and services
- Segmentation technologies
- Third-party connections
- Material changes since the previous test
Enterprises that skip this step often discover the gap only when a QSA asks why a newly connected system wasn’t in the tested scope at all.
What Must a PCI Penetration Testing Methodology Include?
A PCI DSS penetration testing methodology should cover the entire CDE perimeter and critical systems, testing from inside and outside the network, application and network layers, and any segmentation or scope-reduction controls. It should also consider threats and vulnerabilities experienced during the previous 12 months, define how exploitable weaknesses are assessed and addressed, and require penetration-testing and remediation records to be retained for at least 12 months.
Requirement 11.4.1 spells out these expectations directly, and a compliant methodology needs to address each one specifically rather than in general terms.
- The entire CDE perimeter and critical systems.
- Testing from both inside and outside the network.
- Segmentation and scope-reduction controls.
- Application-layer testing.
- Network-layer testing, including systems supporting network functions and operating systems.
- Threats and vulnerabilities experienced during the previous 12 months.
- How the entity assesses and addresses the risk created by exploitable vulnerabilities.
- Retention of penetration-test and remediation results for at least 12 months.
A methodology can reference an industry-accepted testing framework, such as NIST SP 800-115, as one methodological resource, though naming a recognized framework in an appendix is not the same as following it, and it does not substitute for the specific PCI DSS requirements above.
The OWASP Web Security Testing Guide serves a similar role for application-layer testing. The methodology needs to describe what the organization actually does, including tester qualifications and independence, evidence handling, and report contents, in enough detail that an assessor can trace a finding back to the process that produced it.
Who is Allowed to Perform a PCI DSS Penetration Test?
Testing may be conducted by an appropriately qualified internal or external resource, provided the required independence and qualifications hold up. Relevant experience, familiarity with the technologies in scope, understanding of PCI DSS expectations, and clear separation from the teams that build or administer the tested systems all factor into whether a QSA accepts the work.
A crowdsourced vulnerability program, an automated scanner, or an internal security tool should not automatically be treated as a formal PCI penetration test. Synack itself advises organizations to get written confirmation from the relevant assessor before depending on any community-driven or automated output as compliance evidence, and that caution applies regardless of vendor.
PCI Vulnerability Scanning vs Penetration Testing
These two activities get conflated often enough that it’s worth stating plainly: passing a vulnerability scan does not prove that an attacker cannot chain weaknesses together to reach the cardholder data environment.
| Vulnerability scanning | Penetration testing |
| Broadly identifies known weaknesses | Actively tests whether weaknesses can be exploited |
| Frequently automated | Includes skilled analysis and adversarial testing |
| Often performed on a scheduled cadence | Performed according to defined compliance and risk triggers |
| May produce false positives | Should validate whether findings represent real risk |
| Useful for continuous detection | Useful for proving attack paths and business impact |
| Does not replace a pentest | Does not eliminate the need for required scanning |
Approved Scanning Vendor scans still play a role in the broader PCI DSS program, but that role sits alongside penetration testing rather than in place of it. Synack’s own resource on vulnerability scanning and penetration testing draws the same distinction in more detail, if you want the fuller comparison.
What Happens When a PCI Penetration Test Finds Vulnerabilities?
Finding vulnerabilities is not the end of the process, and treating it as one is where a lot of otherwise solid testing programs fall short on evidence. The workflow generally runs:
- Validate the vulnerability.
- Determine affected systems and attack paths.
- Prioritize remediation.
- Correct exploitable vulnerabilities and weaknesses.
- Retest the affected systems.
- Capture proof that the issue is no longer exploitable.
- Retain reports and remediation records for assessment.
A screenshot or a ticket marked closed does not, on its own, provide enough assurance. Assessors generally want reproduction steps, evidence of exploitability, business impact, remediation ownership, retest status, and a clear audit trail. It also helps to distinguish between a rescan, a full retest, and a complete regression or renewed penetration test, since each carries different evidentiary weight.
What Evidence Will PCI Assessors Expect?
Audit-ready evidence should make it easy to trace a straight line: requirement, test performed, result, remediation, retest, closure. A practical evidence checklist covers:
- Defined penetration testing methodology
- Final scope
- Rules of engagement
- Tester qualifications and independence
- Internal and external penetration test reports
- Segmentation test results, where applicable
- Vulnerability findings and remediation records
- Retest results
- Evidence of tests following significant changes
- Dates demonstrating that frequency requirements were met
Synack states that its platform supports audit-ready penetration testing reports built around exactly that chain, which matters more during assessment season than most teams plan for in advance.
Why Annual PCI Penetration Testing May not be Enough for Enterprise Risk
This distinction matters for security posture even though PCI DSS does not universally mandate continuous testing. Annual testing establishes a minimum compliance milestone, but enterprise attack surfaces change throughout the year. New code, APIs, cloud resources, and third-party connections can all appear after the annual test closes out, and a vulnerability discovered shortly afterward could remain exposed for months before the next cycle.
Continuous security validation does not replace the enterprise’s formal PCI obligations. It can help reduce the exposure that accumulates between required assessments, and it can make annual compliance evidence easier to assemble since ongoing asset discovery and retesting produce documentation continuously rather than in a single yearly push.
Where AI Penetration Testing Fits Into a PCI Compliance Program
AI can support faster attack-surface discovery, repeatable testing, initial vulnerability triage, and more frequent validation between formal assessment milestones. That said, AI output needs appropriate governance, and automated results should not automatically be treated as formal compliance evidence on their own.
Synack’s Sara AI Pentesting expands discovery and analysis across the enterprise attack surface, while the Synack Red Team provides human adversarial validation for findings that require deeper expertise. Sara, the Synack Autonomous Red Agent, works alongside Synack’s vetted security researcher community as a force multiplier rather than a replacement for human testing. Enterprises exploring how to automate penetration testing workflows still need qualified testing, documented scope, and assessor-acceptable evidence behind whatever automation they adopt.
How to Choose a PCI Compliance Penetration Testing Provider
Selecting a provider is where many compliance programs quietly succeed or fail, well before the first test ever runs.
Confirm experience with PCI DSS environments
Ask whether the provider understands Requirement 11.4, CDE scoping, segmentation validation, and significant-change testing specifically, not just penetration testing in general terms.
Assess testing depth
Confirm coverage across networks, web applications, APIs, cloud environments, mobile applications, authentication systems, and business-logic vulnerabilities, since gaps in any of these can leave real attack paths untested.
Verify tester qualifications and independence
Request evidence of relevant experience, vetting and quality controls, documented methodology, and clear organizational independence from the systems being tested.
Review remediation and retesting support
Determine whether the service includes actionable findings, proof of exploitability, remediation guidance, retesting, and evidence of closure, rather than a report and nothing further.
Evaluate reporting
The provider should support both technical reports and executive summaries, along with retest status and historical tracking that auditors can follow without extra explanation.
Confirm the delivery model with the QSA
Before committing to a provider, confirm that the proposed scope, delivery model, and evidence format will actually be accepted by your assessor. A strong testing program still needs sign-off up front.
PCI DSS Penetration Testing Checklist for Enterprises
Breaking the process into before, during, and after phases makes it easier to assign ownership and confirm nothing slips between testing cycles.
Before testing
- Confirm the applicable PCI DSS requirements
- Consult the QSA
- Validate the CDE scope
- Update asset and data-flow inventories
- Identify internal and external systems and segmentation controls
- Document material changes
- Define rules of engagement
- Confirm tester qualifications and independence
During testing
- Test internal and external attack paths
- Test application and network layers
- Validate exploitable vulnerabilities
- Test segmentation controls where applicable
- Record evidence and reproduction steps
- Escalate critical findings immediately
After testing
- Review the report for scope completeness
- Assign remediation owners and correct exploitable weaknesses
- Retest remediated findings and retain evidence of closure
- Map evidence to Requirement 11.4
- Schedule the next required assessment and define significant-change triggers
Treat this as a living document rather than a one-time exercise, since the “after testing” phase for one cycle feeds directly into the “before testing” phase of the next.
How Synack Supports Enterprise PCI Penetration Testing
Synack combines on-demand and continuous penetration testing across internal and external attack surfaces, pairing Sara AI Pentesting with human validation from the Synack Red Team. The platform supports vulnerability management workflows, remediation tracking, retesting, and centralized dashboards, with audit-ready reporting built for compliance-led programs. Synack describes its approach as combining Sara with more than 1,500 vetted security researchers, testing across web, API, mobile, cloud, infrastructure, and AI systems.
This helps enterprises prepare compliance evidence and validate exploitable risk, though it does not guarantee PCI compliance on its own. The Synack platform is designed to support formal testing obligations alongside ongoing security validation between assessment cycles.
See how Synack supports PCI-focused penetration testing. Get a personalized walkthrough of Sara AI Pentesting, human-led validation, remediation workflows, and audit-ready reporting. Request a Demo.
Conclusion
PCI DSS penetration testing is not simply an annual scan or a PDF handed over at renewal time. It requires a documented methodology, clearly scoped internal and external testing, qualified and independent testers, segmentation validation where applicable, and evidence that traces from finding through remediation to retest. Confirm applicability and scope with your QSA, build the methodology before the test rather than after, and consider continuous validation to reduce exposure between required assessments.
PCI compliance should demonstrate that security controls work, not merely that a test occurred. See how Sara AI Pentesting and the Synack Red Team help enterprises identify, validate, and prioritize exploitable risk while producing the evidence security and compliance teams need.
This article is for informational purposes only and does not constitute legal, audit, or compliance advice. Organizations should confirm their precise PCI DSS obligations with a Qualified Security Assessor.
Frequently Asked Questions
Generally yes, for entities to which Requirement 11.4 applies. Exact applicability depends on your environment, validation method, and the relevant SAQ or Report on Compliance, so confirm scope and evidence expectations with your QSA before relying on a single testing model.
Applicable internal and external penetration testing must be performed at least once every 12 months and after significant infrastructure or application upgrades or changes. Where segmentation is used to isolate the CDE, segmentation controls must also be tested annually and after relevant changes. Service providers have an additional six-month segmentation-testing requirement.
Yes, for applicable entities, Requirement 11.4 covers both internal and external attack paths rather than one or the other. See penetration testing for compliance for how scope is typically structured across both testing types.
No. Scanning detects known issues on a scheduled cadence, while penetration testing validates whether those issues, and others, can actually be exploited. PCI DSS treats the two as complementary, not interchangeable, obligations.
It depends on risk and context, since PCI DSS does not define an exhaustive list. Major application releases, cloud migrations, new internet-facing systems, and new CDE-connected systems are common examples that typically trigger additional testing.
Yes, provided the internal team has the right qualifications and sufficient organizational independence from the systems being tested. This arrangement is worth confirming with your QSA in advance, since expectations around independence can vary by assessor.
Automation can support the program by expanding coverage and frequency between formal engagements, but it does not automatically satisfy Requirement 11.4 on its own. Confirm methodology and evidence expectations with your QSA, and see how to automate pen testing and how automation fits alongside qualified human testing.
Yes. Segmentation controls used to isolate the CDE must be tested at least annually for most entities and at least every six months for service providers, plus after any change to the segmentation controls or methods. Readers should confirm the exact cycle that applies to their validation method with their QSA.
No. A pentest supports specific requirements, particularly Requirement 11.4, but it does not independently establish full PCI DSS compliance across the rest of the standard. Other controls, documentation, and validation activities still need to be in place.
A compliance-ready report should include scope, methodology, findings, evidence of exploitability, risk ratings, remediation steps, and retesting status. It should also make it easy for an assessor to trace each finding from discovery through to closure.
