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 is written for the organisations carrying the heaviest version of that obligation: Level 1 and Level 2 merchants running multi-channel card acceptance, and service providers whose customers inherit their scope. Those environments have segmented cardholder data environments, several acceptance channels, an acquirer asking for validation artefacts on a schedule, and usually a QSA assembling a Report on Compliance. Smaller merchants validating by self-assessment face the same requirement text with a lighter evidence path, and that segment is covered below.
Every specific here 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 |
Note the mapping, because aggregated summaries frequently swap them: 11.4.2 is internal, 11.4.3 is external.
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, in addition to the testing required under 11.4.6. It is a second test, not the same one counted twice.
PCI DSS v4.0.1 was published on 11 June 2024. PCI SSC confirms there are no added or deleted requirements in that revision, that v4.0 retired on 31 December 2024, and that the 31 March 2025 effective date for future-dated requirements was unchanged, so Appendix A1.1.4 is fully in force.
Which level you are determines how the evidence is consumed
Requirement 11.4 applies identically to every entity in scope. What changes with size is who reads the output and how closely.
Visa's Account Information Security programme sets merchant levels by annual transaction volume, and Canadian acquirers restate the same structure. Moneris, Canada's largest acquirer, publishes four levels: Level 1 above six million transactions annually, validating by annual Report on Compliance with a Qualified Security Assessor plus an Attestation of Compliance and quarterly scans; Level 2 at one to six million transactions, validating by annual Self-Assessment Questionnaire validated by an assessor plus an AOC and quarterly scans; Level 3 at 20,000 to one million ecommerce transactions and Level 4 below 20,000, both by annual SAQ plus AOC and quarterly scans.
Service providers are graded separately. Visa's service provider validation guidance places any service provider handling more than 300,000 Visa transactions a year at Level 1, validating by annual on-site assessment and quarterly network scan, and those below that threshold at Level 2, validating by annual SAQ D and quarterly scan. Level 1 status is also what gets an organisation onto Visa's Global Registry of Service Providers, which is why enterprise customers ask for it during procurement.
What that means practically for penetration testing:
Level 1 merchants and Level 1 service providers. Testing artefacts are examined by a QSA and summarised inside a ROC. Scope of work, methodology, both sets of results and retest evidence are all assessor-facing, and ambiguity in any of them becomes schedule risk.
Level 2 merchants. The SAQ is signed by you but validated by an assessor, so the same artefacts get requested, usually later in the cycle and with less lead time. Mid-market teams routinely discover in month eleven that the segmentation test they budgeted for covered one method out of four.
Level 3 and Level 4 merchants, and startups inside a payment flow. Same requirement text, lighter evidence path. The risk is scoping by omission, since a single acceptance channel or integration is usually what pulled them into scope.
Multi-tenant service providers at any level. Requirement 11.4.7 and Appendix A1.1.4 add obligations no merchant carries, and customers ask for them in security reviews regardless of the acquirer.
Multi-channel acceptance is the other multiplier. Card-present terminals, ecommerce, call-centre capture, mobile SDKs and batch settlement files each drag their own systems into scope behind their own segmentation method. Since 11.4.5 requires coverage of every method in use, channel count and segmentation-method count drive test scope more directly than headcount or revenue.
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.
Element five settles most application-layer scope disputes. Requirement 6.2.4 names the minimum attack classes, 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. Business logic and broken authorisation are named obligations, not stretch goals.
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 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." An internal test that only runs from a jump box already inside the cardholder data environment does not satisfy 11.4.2. It must also attempt to reach the CDE from out-of-scope internal networks, including the corporate LAN, guest wireless and trusted third-party connections.
11.4.3 external penetration testing
External testing carries identical conditions applied to the outside, defined as "testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures." Neither test substitutes for the other, and a QSA will ask for the scope of work and 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, confirm the controls are operational and effective and isolate the CDE from all out-of-scope systems, and confirm the effectiveness of any isolation separating systems with differing security levels. Requirement 11.4.6 applies only to service providers and moves the same obligation to a six-month clock regardless of how stable the environment is.
On coverage, PCI SSC's supplement is pragmatic about large networks: where testing from every individual LAN segment is infeasible, testing should examine each type of segmentation methodology in use, such as firewall or VLAN ACL, at a level giving assurance it is effective in all instances. The supplement also expects the tester to have worked with the organisation or its QSA to understand every methodology 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 11.4.3 and 11.4.4, by either providing evidence that testing covered the customers' subscribed infrastructure or providing prompt access so customers can test themselves. Evidence 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 every six months, 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 most common category error on PCI DSS testing, and it is expensive in both directions: organisations buy quarterly scans and believe they have met 11.4, or buy a penetration test and believe it covers the scanning obligation. They are different requirements, with different frequencies, providers and 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 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, covering external scans after a significant change, 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, 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, so an internal team can satisfy it provided the testers do not report into the group operating the target environment. Because the expected testing procedure includes interviewing responsible personnel, independence gets probed in conversation, not just asserted in a document.
Certifications are evidence, not qualification. PCI SSC's supplement lists OSCP, GIAC, CREST penetration testing certifications and CHECK as examples, states that "the PCI SSC does not validate or endorse these certifications", and adds that "appropriate penetration testing experience and qualifications cannot be met by certifications alone", recommending assessment of years of experience and engagements actually performed.
Treat certifications as a filter and engagement history as the decision. Payments and fintech platforms can compare vendors on that basis in the best penetration testing companies for fintech.
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 reconciles three things:
Your confirmed PCI DSS scope. Requirement 6.5.2 requires confirmation that all applicable requirements are in place after a significant change, captured in the annual scope confirmation under 12.5.2. A 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 able to impact the CDE, including administrative jump hosts, identity infrastructure and the out-of-scope internal networks the internal test must pivot from.
Scope reduction through segmentation is legitimate and encouraged, but only as good as the test that validates it. Untested segmentation is an assumption, and 11.4.5 exists to convert that assumption into evidence. If the same systems sit inside a SOC 2 audit window, SOC 2 penetration testing explains how one engagement can serve both obligations.
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 so loosely that a change your QSA considers significant never triggered a test, and never defining it at all, which leaves you unable to demonstrate why any given change did not trigger testing. Either way the reconciliation happens against your change control records. Write the definition into the 11.4.1 methodology, tie it to change control, 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 gets missed. Exploitable vulnerabilities and security weaknesses 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, and neither does a vulnerability rescan. The verification must be penetration testing.
Prioritisation flows from your documented 6.3.1 risk ranking rather than raw CVSS scores, so a weak 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, defining networks and systems tested, clarifying CDE versus non-CDE segments, and identifying critical systems in or out of the CDE with justification.
Statement of methodology detailing the approaches used.
Statement of limitations, such as designated testing hours, bandwidth restrictions or special handling for legacy systems.
Testing narrative explaining how testing progressed and issues encountered, such as active protection systems blocking traffic.
Segmentation test results, summarising the testing performed to validate scope-reduction controls.
Findings, each covering whether and how the CDE may be exploited, risk ranking, affected targets, references such as CVE or CWE, and a description.
Tools used, and cleaning up the environment, with directions for removing test accounts and artefacts and verifying 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.
Evidence is defined as all information supporting the tester's conclusions, including screenshots, raw tool output, acquired dumps, photos and recordings, with any cardholder data encountered kept to a minimum. Requirement 11.4.1 element nine sets a 12-month retention floor for results and remediation records. 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 to 25,000 per engagement, per our 2026 penetration testing cost analysis, sitting above a SOC 2 test and below FedRAMP. Canadian bands are below. 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 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 obligation recurs annually with change-driven tests in between, some organisations buy a scheduled annual engagement and others a subscription. Stingrai's pricing page lists an Autonomous tier at US$650 per month and a Hybrid tier, Snipe with penetration testers testing alongside it throughout, at US$1,275 per month, both for one web application and its APIs 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.
What a mid-market or enterprise PCI buyer needs from a penetration testing vendor
A startup buying its first PCI penetration test is buying a report. A Level 1 or Level 2 organisation is buying an evidence package that has to survive a QSA, a procurement review and an internal audit function, on a fixed date, every year. Most of the difference between those two products sits outside the testing itself.
Requirement 11.4 evidence built for the ROC, not just for you. The set a QSA works from is a documented methodology mapped to all nine elements of 11.4.1, a statement of scope issued as its own artefact, separate internal and external results, segmentation results enumerated by method, and retest evidence under 11.4.4. Ask for a redacted example of each, not just a sample report. If the scope of work only exists as a paragraph inside the report, your assessor will ask for something that does not exist.
Segmentation cadence matched to your obligation. All entities test segmentation at least every 12 months under 11.4.5 and after any change to controls or methods. Service providers move to six months under 11.4.6, and multi-tenant service providers add the Appendix A1.1.4 logical-separation test on its own six-month clock. A vendor quoting a single annual segmentation test to a service provider has either misread your status or plans to bill the second half separately.
Organisational independence you can evidence on demand. Two things catch enterprise buyers: a vendor whose managed-services arm operates part of the target environment, and an internal team that reports into infrastructure. Document the reporting lines once and keep that document with the methodology.
Named testers with verifiable firm-level accreditation. PCI SSC's guidance is explicit that qualifications cannot be met by certifications alone. Ask for the named individuals who will run the engagement, their certifications, and the firm's own accreditation. Firm-level CREST accreditation is a different and stronger signal than individual certifications held by staff, and both are worth asking about by name.
Retesting inside the price. Requirement 11.4.4 makes retesting mandatory and does not cap the number of cycles. If retests are billed per cycle, your budget becomes a function of how many findings you have, which is exactly the number you cannot forecast. Get retesting written into the statement of work.
A portal, not an email thread. Enterprise remediation runs through Jira or ServiceNow across several engineering teams. Findings that arrive as a PDF three weeks after testing ends lose the window where the testers still have context. A portal with live findings, ticketing integration and a retest request flow is the difference between a two-week and a two-quarter remediation cycle.
Procurement fit. Vendor security reviews, insurance certificates, data-processing terms, background-checked personnel, agreed testing windows for card-present environments, and a change-freeze-aware schedule around peak retail periods. None of this is glamorous and all of it decides whether the engagement starts on time.
Annual and continuous, chosen deliberately. The 12-month clock is a floor, and the significant-change trigger is what breaks annual-only programmes: a two-week release cadence against a twelve-month testing cadence guarantees untested change. A scheduled annual engagement plus change-driven tests works, and so does a continuous programme that absorbs the change trigger. The mistake is buying the annual test with no mechanism for the changes in between.
Canada and US specifics
Price bands. The US$12,000 to 25,000 band above covers a typical scoped US engagement. In Canada, our market pricing breakdown puts a mid-size application test at C$12,000 to 25,000, an internal and external network test at C$15,000 to 35,000, and an annual continuous programme at C$40,000 to 120,000. A Level 1 merchant with several acceptance channels and four or five segmentation methods sits at or above the top of the network band, because each method adds test time that does not scale down. Big Four advisory firms typically price several times these figures for the same scope.
Canadian acquirer expectations. Your acquirer, not PCI SSC, is who chases you for validation. Moneris states that merchants of all sizes who accept, transact, process, store or have access to payment card account data must safeguard it in accordance with PCI DSS, that validation requirements vary by business size and merchant level, and that it assists merchants in confirming their level and the associated requirements. Other Canadian acquirers operate equivalent programmes. Two practical consequences: confirm your level with your acquirer in writing before scoping, because a level change moves you between a QSA-led ROC and an assessor-validated SAQ, and align the testing calendar to the acquirer's validation deadline rather than your fiscal year. Canadian procurement also tends to carry data-residency expectations, so confirm where testing data and reports are stored.
US card-brand programme references. In the United States the same structure runs through each brand's own programme: Visa's Account Information Security programme, Mastercard's Site Data Protection programme, American Express's Data Security Operating Policy and Discover's Information Security and Compliance programme. Where a merchant accepts multiple brands the obligation is the union of the programmes, and the highest level assigned by any single brand sets the practical evidence bar. Level 1 service providers additionally maintain the Visa Global Registry listing, an annual dependency on the assessment completing on time.
Cross-border scope. Organisations operating on both sides of the border usually run one CDE and two acquiring relationships. Test scope is set by the CDE and its segmentation, not by jurisdiction, so one well-scoped engagement normally serves both. What differs is the reporting calendar and the currency on the invoice.
How to choose a PCI DSS penetration testing provider
Since the standard does not require a QSA or ASV, the shortlist question is capability against the specific obligations in 11.4. Three technical checks separate serious proposals from generic ones:
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.
Is segmentation testing scoped by method rather than by host count? All segmentation controls and methods in use must be covered, and a proposal priced per IP usually has not counted the methods.
Does application-layer testing reach the Requirement 6.2.4 classes? Business logic abuse and authorisation bypass are named in the requirement, and neither falls out of a scanner.
Turn these checks into a scored tender with the pentest and red team RFP question bank, built for regulated scopes. For shortlisting, our directory of CREST-accredited penetration testing companies and our ranking of the best penetration testing companies in 2026 are structured around the same criteria.
Where Stingrai fits
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
The firm-level accreditation is the signal a QSA weighs when reviewing tester qualification under 11.4.2 and 11.4.3. Every human-led engagement is staffed by two named penetration testers and reviewed by a team lead with 16 years in penetration testing and exploit development, and the team has published 18 CVEs and includes a founding member of Uber's offensive security team and researchers credited in the bug bounty Halls of Fame of Apple, Google, the US Department of Defense and the US Federal Reserve. For a cardholder data environment that means the same firm covers the external perimeter, internal lateral movement and privilege escalation, segmentation testing by method rather than host sample, Active Directory attack paths into the CDE, and the application and API layer where Requirement 6.2.4 lives.
We work with mid-market and enterprise merchants and service providers in Canada and the United States, delivering both scheduled annual engagements and continuous programmes, so the 12-month clock and the significant-change trigger can be covered by one vendor. Our penetration testing supports your PCI DSS 4.0.1 compliance programme by producing the artefacts Requirement 11.4 is assessed against: a documented methodology mapped to all nine elements of 11.4.1, a statement of scope delivered as a distinct artefact, 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 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 penetration testers' methodology, performs 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 penetration testers work alongside Snipe throughout the engagement, directing its focus and extending the attack paths it opens, and both contribute findings across every severity. Network, infrastructure and segmentation testing across a multi-channel CDE is human-led work by CREST-certified penetration testers. Coverage runs as a one-time annual engagement or continuously through the PTaaS platform, 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." 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 testing under 11.4.2 and 11.4.3 runs 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.
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 describes a scan as identifying, ranking and reporting vulnerabilities with largely automated tooling in seconds to minutes per host, while a penetration test is a manual process identifying 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 v3.x it sat under Requirement 11.3, which is why older pages and PCI SSC's own 2017 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 with organisational independence, adding "not required to be a QSA or ASV." ASV status is required only for the quarterly external scan under 11.3.2. 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, selection is capability-based rather than credential-gated. Strong candidates 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 price, and cover the Requirement 6.2.4 classes including business logic and authorisation flaws. Firm-level accreditation such as CREST is a useful signal alongside individual certifications. Stingrai is a CREST-accredited penetration testing service provider working to these criteria and delivers both annual and continuous engagements, and our CREST directory, USA shortlist and Canada shortlist compare the wider market.
What do Level 1 and Level 2 merchants need from a penetration testing vendor?
Level 1 and Level 2 organisations are buying an evidence package rather than a report. The vendor should deliver a documented 11.4.1 methodology covering all nine elements, a statement of scope as its own artefact, separate internal and external results, segmentation results enumerated by method rather than by host sample, and 11.4.4 retesting priced into the engagement. Buyers should also confirm organisational independence from anyone operating the target systems, ask for the named penetration testers and the firm's own accreditation, check the segmentation cadence matches their obligation at 12 or six months, and require a findings portal that integrates with their ticketing system.
What counts as a significant change under PCI DSS 11.4?
PCI DSS does not prescribe it. PCI SSC states that what is significant depends heavily on the entity's risk assessment process and environment configuration, and that a change which could impact network security or allow access to cardholder data may be considered significant. You therefore define the threshold, document it inside the 11.4.1 methodology, and apply it consistently against 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 to 25,000 per engagement in the United States. In Canada, a mid-size application test runs C$12,000 to 25,000, an internal and external network test C$15,000 to 35,000, and an annual continuous programme C$40,000 to 120,000. The range is 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. Current Stingrai package pricing is published on our pricing page.
Put these numbers to work
Requirement 11.4 is one of the few controls where the evidence is only as good as the engagement behind it. Stingrai is a CREST-accredited penetration testing service provider headquartered in Toronto with a London office, working with mid-market and enterprise merchants and service providers across Canada and the United States. Two named penetration testers run each engagement, drawn from a team holding OSCE³, OSWE, OSEP, OSCP, CREST CRT and CISSP with 18 published CVEs between them, and they cover the whole CDE: external and internal network, segmentation by method, Active Directory, cloud and the application and API layer. Findings land in the PTaaS portal as they are confirmed with a working proof of concept, 11.4.4 retesting is included, and each engagement closes with a redactable report your QSA can read and an attestation letter. Scheduled annual engagements and continuous programmes are both available. Book a free scoping call, get a quote, or read the published pricing.
Related reading
SOC 2 penetration testing companies for 2026, for teams carrying a SOC 2 audit alongside PCI DSS.
Cloud penetration testing companies for AWS and SOC 2, where the CDE runs in AWS.
Best penetration testing companies for fintech, for payment platforms and service providers.
Top penetration testing companies in Canada, including Canadian price bands by engagement type.
PCI DSS audit process and preparation, for the surrounding assessment lifecycle.
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.
Visa. Account Information Security (AIS) Program and PCI. https://usa.visa.com/support/small-business/security-compliance.html. Merchant level definitions and validation requirements.
Visa. Data Security Compliance for Service Providers. https://usa.visa.com/content/dam/VCOM/download/business/resources-and-tools/DataSecurityComplianceServiceProviders.pdf. Service provider Level 1 and Level 2 thresholds and validation methods.
Moneris. PCI Data Security. https://www.moneris.com/en/support/compliance-and-security/pci-data-security. Merchant levels, validation requirements and acquirer expectations in Canada.
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.
