PCI DSS pentest for fintech: scope reduction and the Requirement 11.4 tests that remain

Most fintechs approach PCI DSS the same way: minimize scope. Tokenize early, push the PAN to a compliant processor, claim the smallest SAQ you can defend, and keep the Cardholder Data Environment (CDE) as thin as possible. That is the correct instinct. It is also where a lot of fintech CISOs stop reading, and where the Requirement 11.4 pentest obligation quietly survives.

This page is for fintechs that actually touch card data: card issuing, wallets and neobanks, Banking-as-a-Service (BaaS), and embedded finance. The angle is scope reduction done right, and the pentest obligations that remain no matter how aggressively you tokenize. PCI DSS 4.0 (the 4.0.1 revision) has been fully mandatory since 31 March 2025, so the future-dated testing expectations are now in force.

What PCI DSS actually requires for testing

Requirement 11.4 is the pentest requirement. Its sub-requirements all apply to whatever CDE you have left after scope reduction:

• 11.4.1 A penetration testing methodology must be defined, documented, and implemented, covering industry-accepted approaches, the entire CDE perimeter and critical systems, application-layer and network-layer testing, and the segmentation controls.
• 11.4.2 Internal penetration testing at least once every 12 months and after any significant change.
• 11.4.3 External penetration testing at least once every 12 months and after any significant change.
• 11.4.4 Exploitable vulnerabilities and security weaknesses found during testing must be corrected, and the testing repeated to verify the corrections.
• 11.4.5 Penetration testing on segmentation controls, at least every 12 months for service providers and every 24 months for merchants, confirming that segmentation isolates all out-of-scope systems from systems in the CDE.

Do not confuse 11.4 with Requirement 11.3, which covers vulnerability scanning: internal scans (11.3.1) and external ASV scans (11.3.2) by an Approved Scanning Vendor every three months. ASV scanning is not pentesting and does not satisfy 11.4. Assessors treat the two as separate evidence.

Requirement 6 (secure development) sits upstream: secure coding, code review, and change control feed the "after any significant change" logic in 11.4. If Requirement 6 shows a steady stream of significant changes to CDE-connected systems, an assessor will expect the retest evidence to match.

Two things fintechs consistently get wrong. First, the SAQ-versus-ROC distinction drives the pentest obligation more than the entity's size. Fintechs that store, tokenize, or issue on their own systems generally land on SAQ-D or a full Report on Compliance, and both carry the full Requirement 11.4 obligation. The fully outsourced, redirect-style SAQ paths that skip pentest are rarely available to a fintech that touches the PAN. Second, tokenization narrows the CDE but almost never eliminates it. Any system that handles the PAN before tokenization, performs detokenization, holds the token vault, or enforces the segmentation boundary stays in scope, and stays testable.

What assessors (QSA) actually look for

Three fintech patterns and the questions a QSA tends to ask:

A card-issuing fintech running a BIN-sponsor program. They issue virtual and physical cards through a processor, but their own platform handles cardholder PII, card lifecycle events, and detokenization for customer support screens. The QSA's questions: where exactly does the PAN enter your systems, which service performs detokenization and who can call it, is the support-tooling surface inside the CDE or segmented out, and can you show the segmentation test that proves it. Their scope-reduction claim rested on "the processor holds the card data," but the detokenization path pulled the support console back into scope. Pentest covered the issuing API, the detokenization service, and the segmentation between support tooling and the CDE.

A BaaS provider serving other fintechs. Classified as a service provider, so the stricter cadences apply: 12-month segmentation testing and Requirement 11.4.7 for multi-tenant environments. The QSA pushed hardest on tenant isolation: can one tenant's testing or one tenant's compromise reach another tenant's cardholder data, and is that boundary pentested rather than only architected. They also asked for the methodology document behind 11.4.1 and evidence that exploitable findings from the prior cycle were remediated and retested under 11.4.4, not just ticketed.

A wallet and neobank app storing tokenized cards for top-ups. They tokenize on capture and never persist the PAN, so their scope claim was genuinely thin. The QSA still probed the CDE boundary: the token vault, the app backend that requests tokens, and the API gateway in front of them. The specific questions: what defines the CDE boundary in your architecture diagram, does the external pentest reach every internet-facing component of that boundary, and where is the segmentation test that shows the rest of the neobank estate is out of scope. Thin scope, but a real Requirement 11.4 obligation on the components that remained.

The pattern across all three: the QSA validates the CDE boundary before accepting any scope-reduction claim, then checks that the pentest, the segmentation test, and the retest actually cover that boundary. A clean report on a boundary the assessor does not accept is worth nothing.

Where continuous AI pentest fits fintech specifically

1. "After any significant change" against weekly deploys. Fintech platforms ship continuously: new card programs, new payment rails, new partner integrations, IAM policy changes. Every significant change to a CDE-connected system triggers a retest obligation under 11.4.2 and 11.4.3. Annual human pentest cannot track that. Continuous validation between engagements makes the change-by-change evidence defensible.
2. API-first card surfaces. Issuing, tokenization, detokenization, and wallet top-ups are all API-driven. Broken object-level authorization, token-vault access flaws, and detokenization abuse are API-layer problems that continuous testing of the endpoints catches between deep engagements.
3. Segmentation drift. Scope reduction depends on segmentation holding. A new microservice, a temporary firewall rule, or a misrouted internal service can silently pull an out-of-scope system into the CDE. Continuous validation of the segmentation boundary flags drift long before the annual 11.4.5 test would.

The dangerous version is a scanner firing payloads at a production issuing or tokenization API with no rate limits and no kill switch. Test CDE systems on production-equivalent staging, with bounded safe-mode validation continuously, and keep the human pentest engagement for the annual mandatory scope.

Procurement checklist for fintech CISOs scoping PCI DSS pentest

• Does the vendor validate your CDE boundary and scope-reduction claims before testing, rather than testing only what you hand them?
• Does the vendor produce evidence QSAs specifically accept for 11.4.1 (methodology), 11.4.2/11.4.3 (internal and external), 11.4.4 (remediation and retest), and 11.4.5 (segmentation)?
• Can the vendor test tokenization, detokenization, and token-vault access paths specifically, not just generic web endpoints?
• Does the vendor handle segmentation testing as a distinct methodology, and can they retest the boundary when it drifts?
• Does the vendor continuously validate the API-first card surfaces between annual engagements to cover "after any significant change"?
• Where is your testing data stored, and under which jurisdiction? US-hosted pentest data is a CLOUD Act exposure for EU fintechs.
• Does the vendor coordinate with your QSA on evidence formatting, and are they clear about where their work stops and the QSA assessment begins?

Where Fleuret fits

Fleuret runs continuous AI pentest on fintech environments and maps findings to PCI DSS 4.0 Requirement 11.4 evidence automatically: methodology under 11.4.1, internal and external coverage under 11.4.2 and 11.4.3, remediation and retest under 11.4.4, and segmentation validation under 11.4.5. We test the surfaces that change between annual engagements: issuing APIs, tokenization and detokenization paths, token-vault access, and the segmentation boundary your scope reduction depends on. EU data residency by default; US-hosted available where an acquirer or scheme requires it.

We are not a QSA and we do not sign your Report on Compliance. Fleuret supplements the QSA assessment: the annual mandatory pentest and the formal ROC remain a QSA-led engagement, which we coordinate with on scope and evidence. Continuous validation between engagements, and keeping your CDE boundary honest as the platform ships, is where we add most value.

If you are scoping PCI DSS pentest for a fintech, book a demo.

Related compliance reading

• DORA pentest for fintech: the EU resilience-testing regime that runs in parallel for licensed fintechs, and where TLPT designation adds threat-led testing on top of PCI scope.
• PCI DSS pentest for ecommerce: the same Requirement 11.4 framework seen from the merchant side, where SAQ eligibility and hosted checkout drive scope.