PCI DSS external penetration testing requirements Saudi Arabia have evolved significantly under version 4.0 of the Payment Card Industry Data Security Standard. What was once treated as an annual compliance formality has become a scenario-driven validation exercise that demands documented proof of resilience against specific attack vectors. For CISOs and IT security managers at Saudi payment processors, acquirers, and payment-gateway providers, understanding the four attack paths that Qualified Security Assessors expect in scope—and the evidence format they accept—is now essential to closing Requirement 11.3.1 without triggering costly follow-up requests or remediation delays.
The shift reflects a broader industry recognition that perimeter defences alone cannot protect cardholder data environments. Payment processors in the Kingdom handle high-value transaction flows, operate complex integrations with international card schemes, and face persistent targeting by financially motivated threat actors. An external penetration test that merely scans for common vulnerabilities or stops at the network edge no longer satisfies the standard's intent. QSAs now expect evidence that your environment has been tested against realistic attack chains—from initial compromise through to data exfiltration—and that remediation timelines are documented, tracked, and verified.
When External Penetration Testing Becomes Mandatory
Requirement 11.3.1 mandates external penetration testing at least annually and after any significant infrastructure or application upgrade. For Saudi payment processors, this includes changes to payment gateways, acquiring platforms, tokenization services, or any system component that stores, processes, or transmits cardholder data. The test must be performed by a qualified internal resource or qualified external third party, and the scope must include the entire cardholder data environment perimeter and critical systems.
Several signs indicate it is time to commission your annual test or an interim assessment:
- Your annual PCI DSS assessment window is approaching, and you need current penetration test evidence to present to your QSA.
- You have completed a major infrastructure change—migration to cloud, deployment of a new payment application, or network segmentation redesign—that alters your attack surface.
- A previous penetration test identified high-risk findings, remediation has been completed, and you require formal retest evidence to demonstrate closure.
- Your QSA has flagged gaps in prior penetration test documentation, such as missing attack scenarios, incomplete evidence of exploitation, or unclear remediation timelines.
- You are preparing for an acquiring license application or renewal with the Saudi Central Bank (SAMA) and need independent validation of your security posture.
The standard does not prescribe a specific testing methodology, but QSAs consistently expect evidence of manual exploitation, not automated scanning alone. Vulnerability scans satisfy Requirement 11.3.2; penetration testing under 11.3.1 must demonstrate attempted exploitation of identified weaknesses and document the depth of access achieved.
The Four Attack Paths QSAs Expect in Scope
Version 4.0 does not enumerate attack paths by name, but QSA guidance and industry practice have converged on four core scenarios that must be addressed in every external penetration test of a payment processor:
1. Perimeter Breach and Lateral Movement
The first attack path simulates an adversary gaining initial access through internet-facing systems—web servers, VPN gateways, email infrastructure, or exposed management interfaces—and then attempting lateral movement toward the cardholder data environment. Testers must identify exploitable vulnerabilities in perimeter defences, attempt to establish a foothold, and document how far they can move laterally before segmentation controls or monitoring mechanisms block progress.
QSAs expect evidence of:
- Enumeration of externally accessible services and their patch levels.
- Exploitation attempts against identified vulnerabilities, including proof-of-concept evidence where successful.
- Documentation of segmentation effectiveness: whether network controls prevented or delayed access to in-scope systems.
- Identification of misconfigurations that could enable privilege escalation or credential harvesting.
This scenario validates that your network segmentation, firewall rules, and intrusion prevention systems function as designed under adversarial pressure.
2. Payment-Application Exploit
The second path targets web-based payment applications, APIs, and mobile interfaces that handle cardholder data. Testers must probe for common application-layer vulnerabilities—SQL injection, cross-site scripting, insecure authentication, session management flaws, and business-logic errors—and attempt to extract or manipulate cardholder data through these weaknesses.
QSAs expect evidence of:
- Manual testing of authentication and authorization mechanisms, including attempts to bypass access controls.
- Input validation testing across all data-entry points, with documented proof of injection attempts.
- Session management review, including token predictability and session fixation tests.
- Business-logic testing, such as transaction-amount manipulation, payment-flow bypasses, or privilege escalation within the application.
Automated scanners often miss business-logic flaws and complex authentication bypasses. Manual exploitation and business-logic testing are critical to satisfying this requirement.
3. Cardholder-Data Exfiltration
The third attack path assumes a successful breach and tests whether an attacker can locate, access, and exfiltrate cardholder data from databases, file stores, or backup systems. Testers must demonstrate whether data-at-rest encryption, access controls, and data-loss prevention mechanisms would prevent or detect unauthorized data extraction.
QSAs expect evidence of:
- Identification of systems storing cardholder data, including primary databases, logs, and backups.
- Attempts to access encrypted data stores and documentation of encryption strength and key-management effectiveness.
- Testing of data-loss prevention controls, including whether exfiltration attempts trigger alerts or are blocked.
- Documentation of data-discovery findings: any unexpected storage locations or unencrypted data remnants.
This scenario often reveals shadow copies of cardholder data in development environments, log files, or misconfigured backup systems—findings that can trigger immediate remediation requirements.
4. Denial-of-Service Resilience
The fourth path tests the resilience of critical payment-processing systems to denial-of-service attacks. While full-scale volumetric DDoS testing is rarely feasible in production environments, testers must assess whether application-layer resource exhaustion, protocol abuse, or targeted service disruption could render payment services unavailable.
QSAs expect evidence of:
- Identification of single points of failure in the payment-processing chain.
- Testing of rate-limiting, request throttling, and resource-allocation controls.
- Documentation of failover and redundancy mechanisms, including whether they activate under simulated load.
- Assessment of third-party DDoS mitigation services and their configuration.
This scenario validates business continuity and resilience controls, which are increasingly scrutinized as payment processors face operational-resilience requirements from SAMA and international card schemes.
The Evidence Format QSAs Accept
A penetration test report that satisfies Requirement 11.3.1 must include several mandatory elements. QSAs will request clarification or additional evidence if any of these components are missing or incomplete:
Executive summary: A non-technical overview of the test scope, objectives, key findings, and overall risk posture. This section should clearly state whether the test identified any high-risk vulnerabilities that could lead to cardholder-data compromise.
Methodology: A detailed description of the testing approach, tools used, and the four attack paths addressed. QSAs expect to see evidence of manual exploitation, not just automated scanning, and documentation of any test limitations or exclusions.
Findings with evidence: Each identified vulnerability must be documented with sufficient technical detail to enable remediation. This includes proof-of-concept evidence (screenshots, command output, HTTP requests), risk ratings aligned to a recognized framework (CVSS scores are common), and specific remediation guidance.
Remediation timeline: For each finding, the report must document the agreed remediation deadline and track closure. QSAs will cross-reference this timeline against your risk-management processes and may request evidence that high-risk findings were escalated and addressed within defined service-level agreements.
Retest report: After remediation, a retest must verify that vulnerabilities have been effectively closed. The retest report should reference the original findings, document the retest methodology, and confirm closure or identify any residual risk.
How Penetration Testing Is Delivered
External and internal network testing is conducted in four stages. Scope defines targets, rules of engagement, and test windows to minimize operational disruption. Test encompasses reconnaissance, testing, and manual exploitation across the agreed attack paths. Report delivers findings with evidence and fixes, walked through with your team to ensure clarity and actionability. Retest provides verification after remediation, with a free retest of remediated findings to confirm closure.
Deliverables include an executive summary, technical report with evidence, risk-rated findings and fixes, and a retest report. The engagement typically requires one to four weeks depending on scope, covering web, API and mobile application testing, internal and external network testing, cloud configuration testing, and manual exploitation and business-logic testing. The service aligns to SAMA CSF, NCA ECC, and PCI DSS frameworks.
A Good Outcome
A successful external penetration test under Requirement 11.3.1 delivers three outcomes. First, it provides QSA-ready evidence that your cardholder data environment has been tested against realistic attack scenarios and that identified vulnerabilities have been remediated within documented timelines. Second, it identifies exploitable weaknesses before threat actors do, enabling your team to prioritize remediation based on actual risk rather than theoretical vulnerability scores. Third, it validates the effectiveness of your segmentation, encryption, access controls, and monitoring mechanisms under adversarial pressure, giving your board and executive leadership confidence in your security posture.
The test should not be a surprise audit that uncovers systemic failures. Instead, it should be a structured validation that confirms your controls work as designed and highlights specific areas for improvement. Findings should be actionable, with clear remediation guidance that your team can implement without external dependencies. The retest should confirm closure, providing documented proof that your environment is ready for QSA review.
Closing Requirement 11.3.1 Without Follow-Up Requests
Requirement 11.3.1 is no longer satisfied by a generic penetration test report. QSAs expect evidence of scenario-driven testing across four attack paths, documented proof of manual exploitation, and a clear remediation timeline with verified closure. For Saudi payment processors, the difference between a smooth annual assessment and a protracted remediation cycle often comes down to the quality and completeness of penetration test evidence.
If your annual PCI DSS assessment is approaching, or if you have completed infrastructure changes that alter your attack surface, now is the time to commission a penetration test that addresses all four attack paths and delivers the evidence format QSAs accept. Find exploitable weaknesses before attackers do—with fixes your team can act on.
