# The Penetration-Test Scoping Mistake That Invalidates PCI DSS v4.0 Requirement 11.4.2: Testing the Payment Application But Not the Cardholder-Data Flow
When Saudi payment firms, acquirers, and processors prepare for their annual PCI DSS assessment, the penetration-test scope statement often lists the payment application, the web server, and perhaps the database. The Qualified Security Assessor (QSA) reviews the scope, asks where cardholder data travels before and after the application, and the CISO realizes the PCI DSS penetration test scope omitted half the environment. The test proceeds, findings are remediated, but during the assessment the QSA cannot confirm that Requirement 11.4.2 is met because the scope did not cover the entire cardholder-data flow. The firm must commission a second penetration test, delaying certification and increasing cost.
This mistake is common because teams conflate the cardholder-data environment (CDE) boundary with the application boundary. PCI DSS v4.0 Requirement 11.4.2, published by the Payment Card Industry Security Standards Council, requires penetration testing of the segmentation controls and all system components that store, process, or transmit cardholder data. The standard does not permit testing only the application; it requires testing the entire data path from the moment a card is presented until the data is stored or forwarded, including every network hop, gateway, load balancer, API endpoint, message queue, and database write operation in between.
This article explains the three flow segments that every penetration-test scope statement must include, the evidence QSAs check to confirm flow coverage, and the four-step scoping workshop we run to map data paths before the tester arrives.
Mistake One: Scoping the Application but Not the Ingress Path
Many scope statements list the payment application and its database, but omit the ingress path: the web application firewall, reverse proxy, load balancer, API gateway, or message broker that sits between the cardholder and the application. These components handle cardholder data in transit, decrypt TLS sessions, perform routing decisions, and sometimes cache or log request bodies. Each is a system component that processes cardholder data and must be included in the penetration-test scope.
Why this matters for Requirement 11.4.2: The PCI DSS requires testing segmentation controls and all components that handle cardholder data. If the ingress path is excluded, the penetration test cannot verify that an attacker who compromises the reverse proxy or API gateway cannot pivot to the application or exfiltrate data from intercepted traffic.
Evidence QSAs check: The QSA will compare the penetration-test scope statement against the network diagram and data-flow diagram submitted during the assessment. If the diagrams show a load balancer or WAF in the cardholder-data flow but the penetration-test report does not list those IP addresses or hostnames as tested targets, the QSA will note a gap. The firm must either demonstrate that those components were tested or commission a supplementary test.
Do this instead: Map every network component between the point of interaction (the terminal, browser, or mobile application) and the payment application. Include in the scope statement the IP addresses or hostnames of the WAF, reverse proxy, load balancer, API gateway, and any middleware or message queue that handles cardholder data. Specify that the tester must verify TLS configuration, authentication enforcement, input validation at each layer, and the ability to pivot from one component to the next.
Mistake Two: Testing the Application Logic but Not the Processing Chain
The second common error is to scope the payment application's user-facing endpoints but omit the backend processing chain: the batch processor, tokenization service, encryption module, HSM integration, fraud-scoring engine, or third-party gateway connector. These components receive cardholder data from the application, transform it, enrich it, or forward it to acquirers or card networks. Each performs processing operations on cardholder data and must be tested.
Why this matters for Requirement 11.4.2: An attacker who compromises the payment application may attempt to intercept or manipulate data as it moves through the processing chain. If the tokenization service has an unauthenticated administrative interface, or the batch processor writes cardholder data to an unencrypted staging directory, the penetration test must discover these weaknesses. Excluding the processing chain from scope means these vulnerabilities remain undetected until the next incident or audit.
Evidence QSAs check: The QSA will review the data-flow diagram to identify every system component that receives cardholder data from the payment application. The QSA will then check the penetration-test report to confirm that each component was tested for authentication bypass, injection flaws, insecure API endpoints, and privilege escalation. If the report covers only the application's web interface, the QSA will ask why the tokenization service, HSM integration, or batch processor was not tested.
Do this instead: Document every service, module, or third-party integration that receives cardholder data from the payment application. Include in the scope statement the internal API endpoints, message queues, file-transfer directories, and database procedures that form the processing chain. Specify that the tester must verify authentication and authorization at each integration point, test for injection flaws in batch scripts, and confirm that cardholder data cannot be intercepted or manipulated in transit between components.
Mistake Three: Ignoring the Egress and Storage Segments
The third mistake is to test the application and its immediate dependencies but omit the egress path and storage layer: the database server, backup system, log aggregator, SIEM, data warehouse, or archival storage. Cardholder data that leaves the application must be encrypted at rest, protected by access controls, and segregated from other data. If these components are excluded from the penetration-test scope, the test cannot verify that an attacker who gains access to the network cannot retrieve cardholder data from the database, restore a backup to an unauthorized host, or query the data warehouse.
Why this matters for Requirement 11.4.2: The PCI DSS requires testing all system components that store cardholder data. A penetration test that covers the application but not the database server, backup repository, or log storage cannot confirm that segmentation controls prevent lateral movement to those systems. The QSA will ask how the firm verified that an attacker who compromises the application cannot pivot to the database or exfiltrate backup files.
Evidence QSAs check: The QSA will review the network diagram and asset inventory to identify every system that stores cardholder data. The QSA will then check the penetration-test report to confirm that the database server, backup system, and any other storage components were tested for weak authentication, missing patches, insecure configurations, and inadequate network segmentation. If the report does not list these systems as tested targets, the QSA will note a scoping gap.
Do this instead: Identify every system that stores cardholder data, including the primary database, read replicas, backup servers, disaster-recovery sites, log aggregators, and any data warehouse or analytics platform that receives cardholder data. Include in the scope statement the IP addresses or hostnames of these systems and specify that the tester must verify encryption at rest, access controls, network segmentation, and the ability to exfiltrate data from each storage location.
The Four-Step Scoping Workshop We Run Before the Tester Arrives
To avoid these mistakes, we conduct a scoping workshop before the penetration test begins. The workshop ensures that the scope statement covers the entire cardholder-data flow and that the evidence will satisfy the QSA during the assessment.
Step One: Map the Cardholder-Data Flow
We review the network diagram and data-flow diagram with the CISO, application owner, and infrastructure team. We trace the path of cardholder data from the point of interaction through every network hop, application tier, integration point, and storage location. We document the IP addresses, hostnames, and protocols used at each step.
Step Two: Identify Every System Component in the Flow
We compile a list of every system component that stores, processes, or transmits cardholder data. This includes not only the payment application and database but also the WAF, load balancer, API gateway, tokenization service, HSM, batch processor, backup system, log aggregator, and any third-party gateway or processor integration. We confirm with the infrastructure team that the list is complete and that no component has been overlooked.
Step Three: Define the Test Objectives for Each Segment
For each segment of the cardholder-data flow—ingress, processing, and egress/storage—we define the test objectives. For the ingress segment, the objectives include verifying TLS configuration, authentication enforcement, input validation, and the ability to pivot from the WAF or load balancer to the application. For the processing segment, the objectives include testing authentication and authorization at each integration point, injection flaws in batch scripts, and the ability to intercept or manipulate data in transit. For the egress and storage segment, the objectives include verifying encryption at rest, access controls, network segmentation, and the ability to exfiltrate data from the database or backup system.
Step Four: Document the Scope Statement and Rules of Engagement
We draft the scope statement, listing every IP address, hostname, and application endpoint to be tested. We specify the test objectives for each segment, the permitted testing methods, the test windows, and any systems or operations that are out of scope. We review the scope statement with the CISO and the QSA (if already engaged) to confirm that it covers the entire cardholder-data flow and will satisfy Requirement 11.4.2. Once approved, we provide the scope statement to the penetration tester and the firm's change-control process.
How We Deliver Penetration Testing That Satisfies PCI DSS Requirement 11.4.2
Our Penetration Testing service is designed to meet the requirements of PCI DSS, the SAMA Cyber Security Framework, and the NCA Essential Cybersecurity Controls. We follow a structured process: Scope: Targets, rules of engagement and test windows; Test: Reconnaissance, testing and manual exploitation; Report: Findings with evidence and fixes, walked through with your team; Retest: Verification after remediation.
We deliver an executive summary, technical report with evidence, risk-rated findings and fixes, and retest report. Our testing covers web, API and mobile application testing, internal and external network testing, cloud configuration testing, and manual exploitation and business-logic testing. We include a free retest of remediated findings so that the firm can demonstrate to the QSA that all critical and high-risk vulnerabilities have been resolved before the assessment.
The engagement typically takes 1–4 weeks depending on scope. For firms preparing for PCI DSS assessments, we conduct the four-step scoping workshop described above before testing begins, ensuring that the scope statement covers the entire cardholder-data flow and that the evidence will satisfy the QSA's review of Requirement 11.4.2.
If your firm is preparing for a PCI DSS assessment and you need to confirm that your penetration-test scope covers the entire cardholder-data flow, we can help.
