What Is a Penetration Test Under PCI DSS v4.0? The Three Testing Methods Saudi Payment Firms Must Understand
A penetration test PCI DSS v4.0 Saudi Arabia payment firms must conduct is no longer a single, monolithic exercise. The Payment Card Industry Data Security Standard version 4.0, published by the PCI Security Standards Council and enforced through acquirer agreements and card-scheme rules, introduces formal distinctions between testing methods that were previously bundled or left to assessor interpretation. IT managers and compliance officers preparing for annual assessments now face a requirement to scope three separate testing approaches: authenticated versus unauthenticated network-layer testing, application-layer testing, and internal versus external perspectives. Each method targets different attack surfaces within the cardholder data environment, and omitting one—or conflating them into a single engagement—creates gaps that Qualified Security Assessors will flag during Report on Compliance reviews.
This article defines each testing method, explains which components of your CDE require which approach, and clarifies when a Saudi payment firm needs all three to satisfy PCI DSS v4.0 requirements.
Why PCI DSS v4.0 Changed Penetration Testing Requirements
Previous versions of PCI DSS referenced penetration testing in Requirement 11.3 but left considerable room for interpretation. Assessors and payment firms often debated whether a single external test sufficed, whether web applications required separate testing, and whether authenticated scans met the standard's intent. Version 4.0 removes that ambiguity by codifying three distinct testing methods, each with explicit scope boundaries and objectives.
The Saudi Arabian Monetary Authority does not directly enforce PCI DSS—card schemes and acquiring banks impose it contractually—but SAMA's Cybersecurity Framework expects regulated entities to conduct regular penetration testing as part of vulnerability management. Payment service providers, acquirers, processors and any entity storing, processing or transmitting cardholder data in the Kingdom must therefore align their testing programs to both PCI DSS v4.0 and SAMA CSF expectations, which often overlap but are not identical.
Understanding the three testing methods is essential because each reveals different classes of vulnerability. Network-layer testing uncovers infrastructure weaknesses—misconfigured firewalls, unpatched services, weak authentication on management interfaces. Application-layer testing finds business-logic flaws, injection vulnerabilities and session-management defects that network scans miss entirely. Authenticated testing simulates an insider or a compromised credential; unauthenticated testing simulates an external attacker with no prior access. A payment firm that scopes only external, unauthenticated network testing will satisfy one requirement but leave application and internal attack surfaces untested—and fail the assessment.
The Three Testing Methods Defined
Network-Layer Penetration Testing (External and Internal)
Network-layer penetration testing targets the infrastructure that supports the cardholder data environment: routers, switches, firewalls, operating systems, database servers and any network service exposed on a TCP or UDP port. The objective is to identify exploitable vulnerabilities in network protocols, services and configurations that would allow an attacker to gain unauthorized access, move laterally or exfiltrate data.
PCI DSS v4.0 requires both external and internal network-layer testing. External testing simulates an attacker on the public internet attempting to breach perimeter defenses—firewalls, VPN gateways, public-facing application servers. Internal testing simulates an attacker who has already bypassed perimeter controls, either through physical access, a compromised endpoint or social engineering, and is now attempting lateral movement within the CDE.
The distinction matters because many Saudi payment environments deploy strong perimeter defenses but weaker segmentation internally. An external test may find no critical vulnerabilities, while an internal test from a simulated compromised workstation reveals flat network architecture, unencrypted database connections and administrative interfaces accessible without multi-factor authentication.
Application-Layer Penetration Testing
Application-layer penetration testing targets web applications, APIs and mobile applications that process, store or transmit cardholder data. The objective is to identify vulnerabilities in application code, business logic, authentication and authorization mechanisms, session management and data validation—flaws that exist above the network layer and cannot be detected by network-layer testing.
Common application-layer vulnerabilities include SQL injection, cross-site scripting, insecure direct object references, broken authentication, insufficient authorization checks and business-logic flaws that allow an attacker to manipulate transaction amounts, bypass payment workflows or access another user's cardholder data. These vulnerabilities exist in the application's design and implementation, not in the underlying infrastructure.
PCI DSS v4.0 explicitly requires application-layer testing for all web applications, APIs and mobile applications in scope for the CDE. A network-layer test that scans port 443 and confirms TLS is enabled will not detect an SQL injection vulnerability in a payment API endpoint. Payment firms that rely solely on network testing leave their most critical attack surface—the applications that handle cardholder data directly—unexamined.
Authenticated Versus Unauthenticated Testing
PCI DSS v4.0 introduces a formal distinction between authenticated and unauthenticated testing. Unauthenticated testing simulates an external attacker with no credentials, no prior knowledge and no authorized access. Authenticated testing simulates an attacker who has obtained valid credentials—either through phishing, credential theft or insider threat—and is now attempting to escalate privileges, access unauthorized data or exploit trust relationships.
Authenticated testing is particularly important for cloud environments, APIs and applications that rely on role-based access controls. An unauthenticated test may confirm that an API requires a valid token, but an authenticated test with a low-privilege token will reveal whether that token can be used to access administrative functions, query other users' data or modify transaction records.
The standard requires both methods because the threat landscape includes both external attackers attempting initial access and insiders or compromised accounts attempting abuse of legitimate access. A Saudi payment processor that tests only unauthenticated attack paths will not discover privilege-escalation vulnerabilities, insecure direct object references or business-logic flaws that require valid credentials to exploit.
Which CDE Components Require Which Testing Method
PCI DSS v4.0 Requirement 11.4 specifies that entities must conduct both external and internal penetration testing at least annually and after any significant infrastructure or application upgrade. The scope must include the entire CDE and any systems that could impact the security of the CDE.
External network-layer testing must cover all internet-facing systems in the CDE: payment gateways, web application servers, VPN concentrators, firewalls and any service accessible from the public internet.
Internal network-layer testing must cover systems within the CDE perimeter: database servers, application servers, internal APIs, management interfaces, workstations and any system that stores, processes or transmits cardholder data or could be used to pivot to such systems.
Application-layer testing must cover all web applications, APIs and mobile applications that handle cardholder data, regardless of whether they are hosted internally, in a private cloud or in a public cloud environment. This includes payment pages, transaction APIs, cardholder portals and any application that accepts, displays or transmits primary account numbers, expiration dates or cardholder names.
Authenticated testing must be performed on applications and systems that enforce role-based access controls, particularly APIs, administrative interfaces and multi-tenant applications where privilege escalation or horizontal access violations could expose cardholder data.
A Saudi payment firm operating a card-present acquiring platform, a web-based merchant portal and a mobile payment application will require external network testing of the perimeter, internal network testing of the acquiring infrastructure, application-layer testing of the merchant portal and mobile app, and authenticated testing of the portal's role-based access controls. Scoping only one or two methods leaves entire attack surfaces untested.
Common Scoping Mistakes That Fail QSA Review
Three scoping mistakes recur in Saudi payment firms preparing for PCI DSS v4.0 assessments.
The first is treating vulnerability scanning and penetration testing as interchangeable. Automated vulnerability scans, required quarterly under Requirement 11.3, identify known vulnerabilities by matching signatures and configurations against databases. Penetration testing involves manual exploitation, chaining vulnerabilities, testing business logic and simulating real attacker behavior. A QSA will reject a Report on Compliance that substitutes authenticated vulnerability scans for penetration testing.
The second mistake is scoping only external, unauthenticated network testing and assuming that satisfies the standard. Payment firms that operate entirely in cloud environments sometimes believe that because they have no on-premises infrastructure, internal testing is unnecessary. PCI DSS v4.0 requires internal testing regardless of hosting model; "internal" refers to the logical CDE perimeter, not physical location. A cloud-hosted payment application with a VPC, database instances and application servers requires internal testing within that VPC.
The third mistake is conducting application-layer testing only on public-facing web applications and omitting APIs and mobile applications. Many Saudi payment firms now expose APIs to merchants, partners and mobile applications. These APIs process cardholder data and require application-layer testing, including authentication bypass, authorization testing and input validation. A QSA reviewing the scope will ask for evidence that all in-scope applications—web, API and mobile—were tested.
How CISO Consulting Delivers PCI DSS v4.0 Penetration Testing
CISO Consulting's penetration testing service is designed to meet PCI DSS v4.0 requirements across all three testing methods. The engagement begins with scoping: defining targets, rules of engagement and test windows to ensure that all CDE components—external perimeter, internal infrastructure and applications—are covered without disrupting production payment processing.
The testing phase includes reconnaissance, vulnerability identification and manual exploitation. Web, API and mobile application testing targets application-layer vulnerabilities. Internal and external network testing covers infrastructure. Manual exploitation and business-logic testing go beyond automated tools to simulate real attacker techniques. Cloud configuration testing examines IAM policies, storage permissions and network segmentation in cloud-hosted CDE components.
Findings are documented in a technical report with evidence, risk-rated according to exploitability and business impact, and accompanied by remediation guidance that your team can act on. An executive summary translates technical findings into business risk for senior management and the board. The engagement concludes with a walkthrough session where findings and fixes are reviewed with your IT and compliance teams.
After your team remediates findings, CISO Consulting provides a free retest of remediated findings to verify that vulnerabilities have been closed and to produce the retest report required by PCI DSS v4.0 Requirement 11.4. The full engagement, from scoping through retest, typically requires one to four weeks depending on scope.
The service is aligned to PCI DSS, SAMA's Cybersecurity Framework and the National Cybersecurity Authority's Essential Cybersecurity Controls, ensuring that a single engagement satisfies multiple regulatory and contractual testing obligations.
When to Engage Penetration Testing for PCI DSS v4.0
PCI DSS v4.0 requires penetration testing at least annually and after any significant infrastructure or application upgrade. Significant upgrades include new payment applications, major version changes to operating systems or databases, network redesigns, cloud migrations and changes to segmentation controls.
Saudi payment firms preparing for an annual Report on Compliance assessment should schedule penetration testing at least eight weeks before the assessment date to allow time for remediation and retesting. Firms that have recently migrated payment infrastructure to the cloud, deployed a new merchant portal or integrated a mobile payment application should conduct testing immediately after go-live to identify vulnerabilities before the QSA review.
Payment firms that have previously relied on a single external network test should re-scope their engagement to include internal network testing, application-layer testing and authenticated testing. Firms that outsource penetration testing to a provider that does not distinguish between these methods should verify that the scope explicitly covers all three and that deliverables include separate evidence for network-layer, application-layer and authenticated testing.
Leading to the Service
If your Saudi payment firm is preparing for a PCI DSS v4.0 assessment and needs penetration testing that covers external, internal, network-layer, application-layer and authenticated scopes—with findings your team can remediate and a retest report for your QSA—CISO Consulting's penetration testing service is designed for that requirement. The engagement delivers the technical report, risk-rated findings and retest verification that satisfy Requirement 11.4, aligned to SAMA CSF and NCA ECC expectations.
