PCI DSS pentest for payments: scoping Requirement 11.4 for payment institutions, PSPs, and acquirers-issuers

PCI DSS 4.0 is the one major compliance framework that names penetration testing as a literal, mandatory control. ISO 27001 and SOC 2 expect a pentest without ever writing the word. PCI DSS 4.0 writes it plainly in Requirement 11.4: internal and external penetration testing, at least every 12 months, and after any significant change. Version 4.0 is fully mandatory since 31 March 2025, so the future-dated requirements are now in force, not on the horizon.

For payment institutions, PSPs, payment gateways, and acquirers-issuers, this changes the question. It is never "is a pentest required." It is scope, cadence, and segmentation. Where does the cardholder data environment (CDE) boundary actually sit, how often do you test it, and can you prove that segmentation isolates it. This page works through those three questions for payment-sector entities, which are usually service providers under PCI DSS terminology and therefore carry obligations that merchants do not.

What PCI DSS actually requires for testing

Requirement 11.4 breaks into sub-requirements that apply directly to payment entities handling cardholder data:

• 11.4.1 A penetration testing methodology must be defined, documented, and implemented. It has to include industry-accepted approaches, cover the entire CDE perimeter and critical systems, test from inside and outside the network, validate segmentation and scope-reduction controls, and include application-layer and network-layer testing.
• 11.4.2 Internal penetration testing at least once every 12 months and after any significant infrastructure or application change, by a qualified resource with organisational independence.
• 11.4.3 External penetration testing at least once every 12 months and after any significant change, by a qualified independent resource.
• 11.4.4 Exploitable vulnerabilities and security weaknesses found during testing must be corrected in line with the risk they present, and the penetration testing repeated to verify the corrections.
• 11.4.5 If segmentation isolates the CDE from other networks, penetration testing of the segmentation controls at least once every 12 months, confirming they are operational and effective and that they isolate the CDE from all out-of-scope systems.
• 11.4.6 Service providers only: if segmentation is used, the segmentation controls must be pentested at least once every six months and after any change to those controls. This is the sub-requirement most PSPs, gateways, and processors miss, because they read the 12-month entity-wide 11.4.5 rule and stop there.
• 11.4.7 Multi-tenant service providers only: they must support their customers' external penetration testing under 11.4.3 and 11.4.4. A gateway serving many merchants carries this obligation.

Requirement 11.4 sits next to, but is distinct from, Requirement 11.3. Requirement 11.3 is vulnerability scanning: internal scans and external scans performed at least every three months, with external scans run by a PCI SSC Approved Scanning Vendor (ASV). Scans enumerate known vulnerabilities. Pentest under 11.4 proves exploitability and tests segmentation. An assessor will not accept ASV scan output as a substitute for 11.4 pentest, and will not accept a pentest as a substitute for the quarterly ASV scan. Requirement 6 (secure development, including 6.2 secure software and 6.3 vulnerability management) feeds the picture: the application-layer pentest under 11.4.1 is expected to cover the software weaknesses that Requirement 6 is meant to prevent.

What assessors (QSA) actually look for

Three payment-sector patterns from scoping conversations:

A payment institution processing acquiring flows for SMB merchants. The QSA opened on CDE scope. Which systems store, process, or transmit the primary account number, where does the tokenization boundary sit, and which supposedly out-of-scope systems can reach into the CDE. Because the entity is a service provider, the assessor pressed on 11.4.6: show the segmentation pentest from the last six months, not the last twelve. The institution had an annual segmentation test and had to add a second engagement to meet the six-month service-provider cadence.

A card acquirer with a merchant-facing portal and an authorisation core. The QSA's questions centred on retest evidence under 11.4.4. Two exploitable findings from the prior engagement had been remediated, but the acquirer produced a remediation ticket, not a repeat test proving the fix held. The assessor treated closed tickets without a retest as an open item. The lesson the acquirer took away: 11.4.4 closure is a repeated test, not a Jira status change.

A PSP and gateway serving many merchants. Here 11.4.7 drove the conversation. The gateway is a multi-tenant service provider, so the assessor asked how it supports customer external pentest requests: is there a documented process, a scoping contact, a rules-of-engagement template. The PSP also had to demonstrate that one merchant's testing could not reach another tenant's cardholder data, which folded back into segmentation validation under 11.4.6.

The common thread: assessors care about the CDE scope definition, the segmentation evidence at the right cadence, and retest proof. A clean pentest report on a mis-scoped environment fails. A modest report on the correct CDE, with segmentation validated and findings retested, passes.

Where continuous AI pentest fits payments specifically

PCI DSS 4.0 sets the external and internal pentest floor at annual, plus after every significant change. Continuous testing does not replace that floor. It supplements it and, done well, it is how you evidence the after-change trigger. Three concrete reasons this matters more in payments than elsewhere:

1. The "after significant change" trigger with frequent releases. Payment platforms ship merchant-portal features, new payment methods, and partner integrations on a weekly or faster cadence. Every significant change to the CDE or systems connected to it re-arms the 11.4.2 and 11.4.3 obligation. Continuous validation between annual engagements turns a narrow interpretation of "significant change" into a defensible one, because every change is tested against the same controls.
2. Segmentation validation. Service providers carry the six-month 11.4.6 cadence, and segmentation drifts as infrastructure changes. Continuous testing of the boundaries between the CDE and out-of-scope systems catches drift as it happens, so the twice-yearly formal segmentation test confirms a state you already monitor rather than discovering surprises.
3. API-heavy card-data surfaces. Modern PSPs and gateways expose authorisation, tokenization, and detokenization through APIs that change constantly. These surfaces are well suited to continuous automated testing: bounded, repeatable, and safe to validate on production-equivalent staging. Human-led depth testing still owns the HSM and key-management surfaces.

The version that works: continuous AI pentest on the merchant portal, the payment APIs, and the authentication boundaries, plus the mandatory annual external and internal pentest by a QSA-aligned vendor, plus segmentation pentest at the service-provider six-month cadence, plus quarterly ASV scans under Requirement 11.3. The version that fails an assessor: scanner output with no human triage, no retest, and no segmentation validation.

Procurement checklist for payments CISOs scoping PCI DSS pentest

• Does the vendor's methodology satisfy Requirement 11.4.1 explicitly (industry-accepted approach, CDE perimeter coverage, application-layer and network-layer testing, segmentation validation)?
• Does the vendor understand CDE scoping and avoid expanding scope by testing outside the segmented environment without instruction?
• Can the vendor perform segmentation testing as a distinct methodology, at the six-month cadence service providers need under 11.4.6, not just the annual entity-wide 11.4.5?
• Does the vendor support a retest workflow that closes 11.4.4 with a repeated test proving remediation, not a closed ticket?
• Does the vendor produce evidence a QSA accepts (methodology, scope, findings, remediation and retest results) that drops into the Report on Compliance or SAQ without rework?
• For multi-tenant gateways, can the vendor help you meet 11.4.7 by supporting your merchant customers' external pentest requests?
• Where is the pentest data stored and under which jurisdiction? EU payment entities should confirm data residency and exposure before sharing CDE detail.

Where Fleuret fits

Fleuret runs continuous AI pentest on payment environments and produces evidence that maps to PCI DSS 4.0 Requirement 11.4. We continuously validate the merchant portal, the payment and tokenization APIs, and the authentication boundaries between annual engagements, which is where the "after significant change" trigger bites hardest for a platform that ships weekly. Findings stream into your evidence repository with the methodology, scope, and retest results a QSA expects, and EU data residency is the default.

We are honest about the boundary. Fleuret supplements the assessment, it does not replace it. The Report on Compliance and the sign-off still require a QSA, or an internal SAQ where you are eligible. The mandatory annual external and internal pentest and the formal segmentation test remain a QSA-aligned engagement, which we coordinate with. Continuous validation between those engagements, and the after-change evidence it generates, is where we add the most value.

If you are scoping PCI DSS pentest for a payment institution, PSP, gateway, or acquirer-issuer, book a demo.

Related compliance reading

• PCI DSS pentest for ecommerce: the merchant-side view of Requirement 11.4, where SAQ flavour and hosted checkout decide how small the CDE stays.
• DORA pentest for payments: how DORA Article 24, PSD2 SCA, and PCI DSS 4.0 reconcile into one testing programme for the same payment entities.