Payment card fraud losses worldwide reached US$33.41 billion in 2024 against US$51.920 trillion of card volume, according to The Nilson Report. PCI DSS is the control framework built to push that number down, and it is one of the very few security standards that names penetration testing directly in requirement text rather than leaving it to auditor interpretation.
That requirement is 11.4. Under PCI DSS v4.0.1, Requirement 11.4 reads: "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected." Seven sub-requirements hang off it, and they carry different scopes, different clocks and different applicability depending on whether you are a merchant, a service provider or a multi-tenant service provider.
This guide works through the PCI DSS penetration testing requirements at the requirement level. Every specific in it is sourced from PCI Security Standards Council documents, which matters more than usual on this topic: the sub-requirement numbering changed between PCI DSS versions, and a large share of the pages covering PCI penetration testing still describe the old structure.
PCI DSS penetration testing requirements at a glance
Sub-requirement | What it covers | Minimum frequency | Applies to |
|---|---|---|---|
11.4.1 | Defined, documented and implemented penetration testing methodology (nine elements) | Continuous obligation | All entities |
11.4.2 | Internal penetration testing | Every 12 months and after any significant infrastructure or application upgrade or change | All entities |
11.4.3 | External penetration testing | Every 12 months and after any significant infrastructure or application upgrade or change | All entities |
11.4.4 | Correcting exploitable findings and repeating testing to verify corrections | Event-driven, tied to each test | All entities |
11.4.5 | Segmentation control testing where segmentation isolates the CDE | Every 12 months and after any change to segmentation controls or methods | All entities |
11.4.6 | Segmentation control testing | Every six months and after any change to segmentation controls or methods | Service providers only |
11.4.7 | Supporting customers' external penetration testing per 11.4.3 and 11.4.4 | Tied to customer cycles | Multi-tenant service providers only |
Appendix A1.1.4 adds a separate obligation for multi-tenant service providers: confirm the effectiveness of logical separation controls between customer environments at least once every six months via penetration testing. The applicability note states this is in addition to the testing required under 11.4.6, so it is a second test, not the same one counted twice.
PCI DSS v4.0.1 was published on 11 June 2024. PCI SSC's announcement confirms that "there are no additional or deleted requirements in this revision", that v4.0 was retired on 31 December 2024, and that the limited revision did not change the 31 March 2025 effective date for the standard's future-dated requirements. Those future-dated items, including Appendix A1.1.4, are fully in force now.
Why so many pages still say "Requirement 11.3"
Penetration testing did not always live at 11.4. In PCI DSS v3.x it sat under Requirement 11.3, with segmentation testing at 11.3.4. In v4.0 and v4.0.1, Requirement 11.3 covers vulnerability scanning and penetration testing moved to 11.4.
The confusion is not purely the fault of careless writers. PCI SSC's own Penetration Testing Guidance information supplement is version 1.1, dated September 2017, and it predates v4 entirely. It still says "Per PCI DSS Requirements 11.3.1 and 11.3.2, penetration testing must be performed at least annually and after any significant change", and it describes segmentation validation as a 11.3.4 obligation. The supplement remains genuinely useful for methodology, tester qualification and reporting guidance, and PCI SSC still lists it, but its clause references point at a retired version of the standard.
Two practical consequences. First, when a vendor page cites "PCI DSS 11.3 penetration testing" in 2026, it is quoting a structure that has not been current since v4.0. Second, the internal and external sub-requirements are frequently swapped in aggregated summaries. Under v4.0.1 the mapping is unambiguous: 11.4.2 is internal, 11.4.3 is external. Check any source that tells you otherwise.
Requirement 11.4.1: the methodology has nine elements
Before any testing happens, 11.4.1 requires a penetration testing methodology that is defined, documented and implemented. The requirement enumerates nine elements:
Industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope-reduction controls.
Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12 months.
A documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
Retention of penetration testing results and remediation activities results for at least 12 months.
The expected testing procedures for 11.4.1 are to examine documentation and interview personnel. A methodology that exists as an unread PDF will not survive the interview half of that.
Element five deserves attention because it is where most application-layer scope disputes are settled. Requirement 6.2.4 names the attack classes that application-layer testing must cover at minimum, and the list is broader than a scanner checklist: injection attacks; attacks on data and data structures; attacks on cryptography usage; attacks on business logic, including abuse or bypass of application features through manipulation of APIs, communication protocols and client-side functionality, and explicitly including XSS and CSRF; and attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication or authorisation mechanisms.
Business logic and broken authorisation are named obligations, not stretch goals. Any methodology that covers only the OWASP-scanner floor is not meeting 11.4.1 element five.
Internal, external and segmentation testing are three separate obligations
11.4.2 internal penetration testing
Internal testing must be performed per the entity's defined methodology, at least once every 12 months, after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party, with organisational independence of the tester (not required to be a QSA or ASV).
The applicability note to 11.4.1 defines the term precisely, and it is wider than most buyers assume: "Testing from inside the network (or 'internal penetration testing') means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks."
That second clause is the one that catches people. An internal test that only runs from a jump box already inside the cardholder data environment does not satisfy 11.4.2. The test must also attempt to reach the CDE from internal networks that are out of scope, including the corporate LAN, guest wireless and any trusted third-party connection.
11.4.3 external penetration testing
External testing carries an identical list of conditions to 11.4.2, applied to the outside. The applicability note defines it as "testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures."
Internal and external are separate obligations. Neither substitutes for the other, and a QSA will ask for the scope of work and the results of each as distinct artefacts.
11.4.5 and 11.4.6 segmentation testing
If segmentation is used to isolate the CDE from other networks, segmentation controls must be penetration tested. Requirement 11.4.5 is the baseline for all entities: at least once every 12 months and after any changes to segmentation controls or methods. Note the trigger is any change, not the higher "significant change" bar that applies to 11.4.2 and 11.4.3.
The test must cover all segmentation controls and methods in use, follow the defined methodology, confirm that the controls are operational and effective and isolate the CDE from all out-of-scope systems, and confirm the effectiveness of any use of isolation to separate systems with differing security levels.
Requirement 11.4.6 applies only to service providers and moves the same obligation to a six-month clock. If you are a service provider, your segmentation testing runs twice a year regardless of how stable the environment is.
On coverage, PCI SSC's guidance supplement is pragmatic about large networks: where it is infeasible to test from every individual LAN segment, testing should be planned to examine each type of segmentation methodology in use, such as firewall or VLAN ACL, at a level that provides assurance the methodology is effective in all instances of its use. The supplement also expects the tester to have worked with the organisation or its QSA to understand every methodology in use before testing begins.
11.4.7 and Appendix A1.1.4: multi-tenant service providers
Requirement 11.4.7 obliges multi-tenant service providers to support their customers for external penetration testing per Requirements 11.4.3 and 11.4.4. The applicability note gives two routes: provide evidence to customers showing that testing was performed on the customers' subscribed infrastructure, or provide prompt access so customers can test themselves. Evidence supplied to customers may be redacted but must still be sufficient.
Appendix A1.1.4 then separately requires confirmation of logical separation between customer environments via penetration testing at least once every six months, and states plainly that this is in addition to 11.4.6. For a deeper cross-framework treatment of what evidence auditors accept, see our guide to pentest evidence auditors accept across SOC 2, ISO 27001, PCI DSS and CMMC.
ASV scanning under 11.3.2 is not penetration testing under 11.4
This is the single most common category error on PCI DSS testing, and it is expensive in both directions: organisations either buy quarterly scans and believe they have met 11.4, or they buy a penetration test and believe it covers the scanning obligation. Neither is true. They are different requirements, with different frequencies, different providers and different outputs.
11.3.2 external vulnerability scan | 11.4.2 / 11.4.3 penetration test | |
|---|---|---|
Frequency | At least once every three months | At least once every 12 months, plus after significant change |
Who performs it | Must be a PCI SSC Approved Scanning Vendor (ASV) | Qualified internal resource or qualified external third party, not required to be a QSA or ASV |
Passing criteria | ASV Program Guide requirements for a passing scan, with rescans as needed | Exploitable findings corrected per your 6.3.1 risk assessment, then re-tested under 11.4.4 |
Method | Typically automated tooling with manual verification of identified issues | A manual process that may use scanning or other automated tools, producing a comprehensive report |
Purpose | Identify, rank and report vulnerabilities | Identify ways to exploit vulnerabilities to circumvent or defeat security features |
Duration | Seconds to minutes per scanned host | Days or weeks depending on scope |
Two nuances worth knowing.
First, the ASV mandate is narrower than most people think. It attaches to the quarterly external scan under 11.3.2. Internal vulnerability scans under 11.3.1 run on the same three-month clock but require only qualified personnel with organisational independence. And Requirement 11.3.2.1, which covers external scans performed after a significant change, states that scans are performed by qualified personnel with organisational independence and explicitly adds "not required to be a QSA or ASV". The after-change external scan does not need an ASV; the quarterly one does.
Second, the standard's own framing is that a scan identifies while a test exploits. Buying four ASV scans a year and filing them as your 11.4 evidence is a finding waiting to happen. Our penetration testing versus vulnerability assessment guide covers how the distinction plays out across other frameworks.
Who is allowed to perform PCI DSS penetration testing
Requirements 11.4.2, 11.4.3, 11.4.5 and 11.4.6 all carry the same two-part answer: the test is performed "by a qualified internal resource or qualified external third party" and "organizational independence of the tester exists (not required to be a QSA or ASV)."
You do not need a QSA. You do not need an ASV. This is stated in the requirement text itself, four times. Vendors who imply that only a QSA can deliver a compliant penetration test are misreading the standard.
Independence is organisational, not contractual. The bar is separation from the management of the systems being tested. An internal security team can satisfy it, provided the testers do not report into the group that operates the target environment. Because the expected testing procedure for 11.4.2 and 11.4.3 includes interviewing responsible personnel, independence gets probed in conversation, not just asserted in a document.
Certifications are evidence, not qualification. PCI SSC's guidance supplement lists examples including OSCP, GIAC certifications, CREST penetration testing certifications and CHECK, then states directly: "the PCI SSC does not validate or endorse these certifications." It goes further: "Appropriate penetration testing experience and qualifications cannot be met by certifications alone", and recommends assessing years of experience and the extent of actual engagements performed.
Treat certifications as a filter, and engagement history as the decision.
Scoping the test to the cardholder data environment
Requirement 11.4.1 element two sets the scope floor: coverage for the entire CDE perimeter and critical systems. Critical systems are not limited to those inside the CDE, which is why the guidance supplement's recommended report outline asks for "identification of critical systems in or out of the CDE and explanation of why they are included in the test as targets."
A defensible scope generally reconciles three things:
Your confirmed PCI DSS scope. Requirement 6.5.2 requires that after a significant change, all applicable PCI DSS requirements are confirmed in place, and the applicability note directs that significant changes be captured in the annual scope confirmation activity under Requirement 12.5.2. A penetration test scoped narrower than your confirmed scope is difficult to defend.
Every segmentation method in use, because 11.4.5 requires coverage of all of them, not a representative sample of hosts.
Systems connected to or that could impact the CDE, including administrative jump hosts, identity infrastructure and out-of-scope internal networks that the internal test must attempt to pivot from.
Scope reduction through segmentation is legitimate and encouraged, but it is only as good as the segmentation test that validates it. Segmentation that has never been tested is an assumption, and 11.4.5 exists precisely to convert that assumption into evidence.
Timing: the 12-month clock and the significant-change trigger
The 12-month clock for 11.4.2 and 11.4.3 is the part everyone plans for. The significant-change trigger is the part that generates findings.
PCI SSC does not prescribe what counts as significant. The guidance supplement is explicit: "What is deemed 'significant' is highly dependent an entity's risk-assessment process and on the configuration of a given environment. Because of this variability, a significant change is not prescribed by PCI DSS. If the change could impact the security of the network or allow access to cardholder data, it may be considered significant by the entity."
That places the burden on you to define the threshold and apply it consistently. Two failure modes follow:
Defining it too loosely, so that a change your QSA considers significant never triggered a test. The reconciliation happens against your change control records, and gaps show up there.
Never defining it at all, which leaves you unable to demonstrate why any given change did not trigger testing.
Write the definition into the methodology required by 11.4.1, tie it to your change control process, and keep the records that show the two were reconciled. Note also that the segmentation trigger under 11.4.5 and 11.4.6 is lower: any change to segmentation controls or methods, whether or not you would classify it as significant.
Requirement 11.4.4: retesting is mandatory
Requirement 11.4.4 has two limbs, and the second is the one that gets missed. Exploitable vulnerabilities and security weaknesses found during penetration testing must be corrected "in accordance with the entity's assessment of the risk posed by the security issue as defined in Requirement 6.3.1", and "penetration testing is repeated to verify the corrections."
A closed remediation ticket does not satisfy the second limb. Neither does a vulnerability rescan. The verification must be penetration testing.
Two planning implications. Prioritisation flows from your documented 6.3.1 risk ranking rather than raw CVSS scores, so a weak or undocumented ranking process quietly undermines 11.4.4. And because the number of retest cycles is not fixed, retesting should be scoped into the engagement from the start rather than discovered as a change order after the report lands.
What your QSA expects to see
PCI SSC's guidance supplement publishes a recommended penetration test report outline, and it is the closest thing to a specification for what a compliant report contains:
Executive summary covering scope and major findings.
Statement of scope, including a detailed definition of networks and systems tested, clarification of CDE versus non-CDE systems or segments, and identification of critical systems in or out of the CDE with justification.
Statement of methodology detailing the approaches used.
Statement of limitations, documenting restrictions such as designated testing hours, bandwidth restrictions or special handling for legacy systems.
Testing narrative explaining how testing progressed and any issues encountered, such as active protection systems blocking traffic.
Segmentation test results, summarising the testing performed to validate segmentation controls used to reduce scope.
Findings, each covering whether and how the CDE may be exploited using the vulnerability, risk ranking, affected targets, references such as CVE or CWE, and a description.
Tools used.
Cleaning up the environment, with directions for removing test accounts, test tools and other artefacts and verifying that security controls were restored.
Alongside the report, the expected testing procedures for 11.4.2 and 11.4.3 require examination of the scope of work as a separate artefact from the results. Many entities produce only the report and get caught on this.
On evidence, the supplement defines it as all information supporting the tester's conclusions, giving examples including screenshots, raw tool output, acquired dumps, photos and recordings, and recommends that any cardholder data encountered during testing be kept to a minimum. Requirement 11.4.1 element nine sets the retention floor at 12 months for results and remediation activity records.
For how this evidence lands in the wider assessment, our guide to the PCI DSS audit process and preparation covers the surrounding lifecycle.
What PCI DSS penetration testing costs
Compliance-driven penetration testing for PCI DSS typically runs US$12,000–25,000 per engagement, per our 2026 penetration testing cost analysis, sitting above a SOC 2 test and below FedRAMP. The spread is driven by five things:
Scope size, meaning live host and application counts inside and adjacent to the CDE.
Number of segmentation methods, since 11.4.5 requires all of them to be covered.
Application-layer depth, because the Requirement 6.2.4 classes include business logic and authorisation testing that cannot be automated away.
Service provider status, which doubles segmentation testing frequency under 11.4.6 and may add Appendix A1.1.4 testing.
Retest cycles under 11.4.4, which are unbounded in number.
Because the 11.4 obligation recurs annually with change-driven tests in between, many organisations move to a subscription model rather than repeatedly buying one-off engagements. Stingrai's pricing page lists an Autonomous tier at US$450 per month and a Hybrid tier combining AI agents with certified human pentesters at US$1,275 per month, both on 12-month engagements with automated retests included, plus a custom Enterprise tier for full attack surface coverage. Verify current figures on the pricing page, and use get a quote for a scoped estimate against your actual CDE.
How to choose a PCI DSS penetration testing provider
Since the standard does not require a QSA or ASV, choosing who runs your PCI pentest comes down to demonstrable capability against the specific obligations in 11.4:
Can they produce the 11.4.1 methodology as a document? Ask to see how they cover all nine elements, especially element five against the Requirement 6.2.4 attack classes.
Do they deliver the scope of work as a distinct artefact? The expected testing procedure examines it separately from results.
Is segmentation testing scoped by method, not by host count? All segmentation controls and methods in use must be covered.
Is 11.4.4 retesting included in the engagement price? If retesting is billed per cycle, budget certainty disappears the moment findings land.
Does the internal test include pivoting from out-of-scope internal networks? If the proposal only describes testing from inside the CDE, it does not meet the 11.4.1 applicability note.
Can they evidence organisational independence? For a third party this is straightforward, but it still gets probed by interview.
What is the actual engagement history? PCI SSC's own guidance says qualifications cannot be met by certifications alone.
Firm-level accreditation is a useful signal on top of individual certifications. Our directory of CREST-accredited penetration testing companies and our ranking of the best penetration testing companies in 2026 are both structured around these criteria.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing service provider founded in 2021, with teams in Toronto and London, 18 published CVEs across the team, and a 5.0 out of 5.0 rating across 19 Clutch reviews. Team certifications include OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, GCPN, CRTE and eWPTX, and our researchers present at DEFCON and BSIDES.
Our penetration testing supports your PCI DSS 4.0.1 compliance programme by producing the artefacts Requirement 11.4 is actually assessed against: a documented methodology mapped to all nine elements of 11.4.1, a statement of scope delivered as a distinct artefact rather than a paragraph inside the report, separate internal and external results, segmentation validation covering every method in use, and 11.4.4 retesting scoped into the engagement rather than sold afterwards as a change order.
Snipe, our autonomous web application penetration testing agent, is built for exactly the application-layer classes Requirement 6.2.4 names and generic scanners miss: IDOR, business logic flaws and broken authorisation. It is custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports and on skills distilled from our own pentesters' methodology, performs both black-box dynamic testing and white-box source review, generates AutoFix pull requests, and can gate pull requests so vulnerable code never reaches the environment handling cardholder data. Our senior testers validate and extend what Snipe finds, and the PTaaS platform keeps coverage live between formal 12-month cycles, which is where the significant-change trigger tends to bite.
Frequently Asked Questions
Does PCI DSS require penetration testing?
Yes. PCI DSS v4.0.1 Requirement 11.4 states that "external and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected." It is one of the few security frameworks that names penetration testing in requirement text rather than treating it as an optional control. Internal testing is required by 11.4.2 and external testing by 11.4.3, both at least once every 12 months and after any significant infrastructure or application upgrade or change.
How often is PCI DSS penetration testing required?
Internal and external penetration testing under 11.4.2 and 11.4.3 must be performed at least once every 12 months and after any significant infrastructure or application upgrade or change. Segmentation testing under 11.4.5 runs at least every 12 months and after any change to segmentation controls or methods. Service providers move to a six-month segmentation clock under 11.4.6, and multi-tenant service providers additionally confirm logical separation between customer environments every six months under Appendix A1.1.4. Retesting under 11.4.4 is event-driven and occurs whenever exploitable findings are corrected.
What is the difference between a PCI penetration test and a vulnerability scan?
They are separate requirements. Quarterly external vulnerability scanning sits at Requirement 11.3.2 and must be performed by a PCI SSC Approved Scanning Vendor. Penetration testing sits at Requirement 11.4, runs at least every 12 months, and explicitly does not require an ASV. PCI SSC's guidance describes a scan as identifying, ranking and reporting vulnerabilities using largely automated tooling in seconds to minutes per host, while a penetration test is a manual process that identifies ways to exploit vulnerabilities to circumvent or defeat security features, running for days or weeks. Four ASV scans a year do not satisfy Requirement 11.4.
Which PCI DSS requirement covers penetration testing?
Requirement 11.4 in PCI DSS v4.0 and v4.0.1. In PCI DSS v3.x, penetration testing sat under Requirement 11.3, which is why many older pages and even PCI SSC's own 2017 Penetration Testing Guidance supplement still reference 11.3. Under the current standard, 11.3 covers vulnerability scanning and 11.4 covers penetration testing.
Does a PCI penetration test have to be performed by a QSA or ASV?
No. Requirements 11.4.2, 11.4.3, 11.4.5 and 11.4.6 each state that testing is performed by a qualified internal resource or qualified external third party and that organisational independence of the tester exists, adding in parentheses "not required to be a QSA or ASV." ASV status is required for the quarterly external vulnerability scan under 11.3.2, which is a different control. Organisational independence means separation from the management of the systems being tested, so a suitably separated internal team can qualify.
What are the best PCI penetration testing companies?
Because PCI DSS does not restrict testing to QSAs or ASVs, the selection criteria are capability-based rather than credential-gated. Strong candidates can show a documented methodology mapped to all nine elements of 11.4.1, deliver the scope of work as a separate artefact, scope segmentation testing by method rather than host sample, include 11.4.4 retesting in the engagement price, and cover the Requirement 6.2.4 application-layer classes including business logic and authorisation flaws. Firm-level accreditation such as CREST is a useful signal alongside individual certifications like OSCP and CREST CRT. Stingrai is a CREST-accredited penetration testing service provider working to these criteria, and our CREST directory and 2026 rankings compare the wider market.
What counts as a significant change under PCI DSS 11.4?
PCI DSS does not prescribe it. PCI SSC's guidance states that what is deemed significant depends heavily on the entity's risk assessment process and environment configuration, and that if a change could impact the security of the network or allow access to cardholder data, the entity may consider it significant. The obligation is therefore to define the threshold yourself, document it inside the 11.4.1 methodology, and apply it consistently against your change control records. Segmentation testing under 11.4.5 and 11.4.6 uses a lower trigger: any change to segmentation controls or methods.
How much does PCI DSS penetration testing cost?
Compliance-driven PCI DSS penetration testing typically runs US$12,000–25,000 per engagement, with the range driven by CDE size, the number of segmentation methods requiring coverage, application-layer depth, service provider status, and the number of 11.4.4 retest cycles. Subscription models can be more economical given the recurring annual obligation plus change-driven tests. Current Stingrai package pricing is published on our pricing page.
References
PCI Security Standards Council. PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants (April 2022). https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-D-Merchant.pdf. Requirement 11.3.1, 11.3.2, 11.3.2.1, 11.4 through 11.4.5, Requirement 6.2.4 and Requirement 6.5.2, quoted verbatim.
PCI Security Standards Council. PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers (April 2022). https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-D-Service-Provider.pdf. Requirements 11.4.6, 11.4.7 and Appendix A1.1.4, quoted verbatim.
PCI Security Standards Council. Just Published: PCI DSS v4.0.1 (11 June 2024). https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1. Confirms no added or deleted requirements in v4.0.1, the 31 December 2024 retirement of v4.0, and the unchanged 31 March 2025 effective date.
PCI Security Standards Council. Information Supplement: Penetration Testing Guidance, version 1.1 (September 2017). https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf. Scan versus test comparison, significant change guidance, tester qualification, segmentation coverage, report outline and evidence retention. Note this supplement predates PCI DSS v4 and uses v3.x clause numbering.
PCI Security Standards Council. Document Library. https://www.pcisecuritystandards.org/document_library/. Canonical source for the current standard and supporting documents.
The Nilson Report. Global Card Fraud Losses at $33 Billion (7 January 2026). https://www.globenewswire.com/news-release/2026/01/07/3214821/0/en/global-card-fraud-losses-at-33-billion.html.
