PCI-DSS Penetration Testing Requirements: What Fintech and Payment Companies Need to Know

PCI-DSS v4.0 (effective March 2024, with v4.0.1 clarifications in effect) introduced significant changes to penetration testing requirements, particularly around scope definition, methodology, and the treatment of the Cardholder Data Environment (CDE) and connected systems. For Indian fintech companies — payment aggregators, payment gateways, prepaid instrument issuers, and fintech platforms integrated with acquiring banks — PCI-DSS compliance is a prerequisite for operating in the card payments ecosystem. RBI's payment system regulatory framework effectively makes PCI-DSS a compliance baseline; the RBI PA-DSS and the broader payment ecosystem requirements align with it closely.

PCI-DSS Requirement 11.4: the penetration testing mandate

Requirement 11.4 of PCI-DSS v4.0 is the penetration testing section. It mandates: an annual internal and external penetration test of the CDE and systems that may impact the CDE; a penetration test after any significant infrastructure or application change; correction of exploitable vulnerabilities and repetition of testing to confirm correction; use of a qualified internal resource or qualified external third-party — where independence is required for Level 1 merchants and service providers (QSAC/QSA-reviewed pentest). The "significant change" trigger is particularly important: a new payment API endpoint, a new payment processing server, or a significant code change to the payment authorisation flow each potentially triggers a requirement for a new penetration test or at minimum a targeted re-assessment.

Defining CDE scope accurately

The Cardholder Data Environment is defined as all system components — people, processes, and technology — that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), or that are in the same network segment. Scope creep is the primary PCI-DSS risk management failure: organisations that fail to accurately define CDE scope end up either over-testing (expensive and slow) or under-testing (leaving real attack surface outside the assessment). For a payment gateway, the CDE scope typically includes the authorisation and settlement servers, the payment page (if card data is entered on a hosted page), the tokenisation service, the encryption and key management infrastructure, and the networks on which these reside. Connected-to-CDE systems (an application server that can communicate with CDE systems even if it does not directly handle CHD) are in scope for penetration testing even if they are not in scope for some other PCI controls.

CDE scoping workshops, conducted before the penetration test begins, are where most of the analytical value is created. A poorly scoped engagement where critical systems are excluded produces a report that offers false assurance. Our VAPT service for financial services includes a formal scoping workshop as the first engagement phase.

Segmentation testing: the hardest PCI requirement to satisfy

PCI-DSS requires that if network segmentation is used to reduce CDE scope, the penetration test must include testing to confirm that the segmentation controls are effective and operational — that an attacker in an out-of-scope network cannot reach CDE systems through the segmentation controls. This is "segmentation testing" or "isolation testing." It requires the tester to operate from all in-scope out-of-scope network segments and actively attempt to reach CDE systems through firewall rules, network access controls, and routing. It is not a theoretical review of firewall rule sets — it is active exploitation attempts. Segmentation testing failures are among the most consequential PCI audit findings: if the segmentation controls don't hold, the CDE scope must be expanded, retroactively increasing compliance obligations.

Web application testing: Requirement 6.2 and the payment page

Requirement 6.2.4 of PCI-DSS v4.0 requires that web-based payment applications be protected against known vulnerabilities. For organisations with a PCI-DSS in-scope payment page (even if that page uses a hosted payment page from a third-party provider but is on the merchant's domain), web application penetration testing of the payment page is part of the Requirement 11.4 assessment. The OWASP Top 10 is the implicit baseline; PCI-DSS does not specify a testing framework by name, but assessors expect comprehensive testing against the standard web application vulnerability taxonomy. Client-side script integrity (Requirement 6.4, addressing Magecart-style attacks) requires that the organisation monitors and validates all scripts loaded on the payment page — a new testing surface introduced in v4.0.

PCI-DSS v4.0 changes that affect testing scope

Three v4.0 changes materially affect penetration testing scope. First, the expanded SAE requirements: payment page client-side script integrity (6.4.3) and the HTTP header requirements (6.3.3) create new testable controls. Second, the authenticated scan requirement (11.3.1.2) for internal vulnerability scans requires that scans be conducted with authenticated access to enumerate application-level vulnerabilities, not just service-level vulnerabilities — this raises the floor of internal scanning. Third, the requirement for a targeted risk analysis for customised implementations (12.3.1) means that organisations deviating from defined timeframes for controls must document their risk analysis — and their penetration testing cadence may need to reflect the higher-risk customised controls identified in that analysis.

CyVigilant conducts PCI-DSS penetration testing for payment gateways, fintech platforms, and acquiring banks, including segmentation testing and payment page web application assessment. Explore our VAPT services for financial services or talk to an expert to discuss your PCI-DSS audit cycle.