# How to Scope PCI DSS v4.0 When Your Payment Gateway Sits Outside the Kingdom
Most Saudi merchants, e-commerce platforms and payment service providers rely on payment gateways hosted outside the Kingdom — whether in Europe, North America or regional hubs. This architecture is efficient and often necessary, but it introduces a scoping challenge that catches many organizations unprepared when they begin PCI DSS scoping Saudi Arabia assessments: which of your systems, networks and people fall inside the cardholder data environment (CDE) when the gateway that processes card data sits beyond your direct control?
The answer is not always obvious. It depends on how card data flows through your environment, how you have segmented your networks, and whether any of your systems store, process or transmit cardholder data — even temporarily. Scoping errors are costly. Scope too broadly and you subject unnecessary systems to PCI DSS requirements, increasing cost and complexity. Scope too narrowly and you fail the assessment or, worse, leave gaps that expose card data.
This article walks through the scoping decision tree we use in readiness assessments for organizations with cross-border payment architectures. It shows how to map card-data flows, identify segmentation boundaries, document exclusions and prepare the evidence your Qualified Security Assessor (QSA) or self-assessment questionnaire (SAQ) will require.
When Cross-Border Architectures Create Scoping Uncertainty
A typical Saudi merchant or e-commerce platform does not operate its own payment gateway. Instead, it integrates with a third-party payment service provider whose gateway infrastructure is hosted abroad. The merchant's website or point-of-sale system collects payment details, sends them to the gateway, receives an authorization response, and completes the transaction.
The question is: does cardholder data ever enter your environment?
If your integration uses a redirect or hosted payment page, the customer enters card details directly on the gateway's page. Your systems never see the full primary account number (PAN). In this case, your CDE may be very small — perhaps limited to the web server that initiates the redirect and receives the tokenized response.
If your integration uses an API or server-to-server connection, your application collects card details and transmits them to the gateway. Even if you do not store the data, your application processes it. That application server, the network segment it sits on, and any system that could access it are now in scope.
If you use a point-to-point encryption (P2PE) solution validated by the PCI Security Standards Council, card data is encrypted at the point of interaction and decrypted only at the gateway. Your environment never handles plaintext PAN, and your scope shrinks dramatically.
The scoping decision depends on the integration method, the presence of segmentation, and whether any system retains card data — in logs, databases, backups or temporary files.
The Scoping Decision Tree: Five Questions
We use a structured decision tree in readiness assessments to determine what falls inside the CDE. It begins with five questions.
1. Does any system in your environment store, process or transmit cardholder data?
This is the foundational question. Store means retaining PAN in any form — databases, flat files, logs, backups, screenshots. Process means performing any operation on PAN — encryption, tokenization, transmission, display. Transmit means sending PAN across a network, even within your own infrastructure.
If the answer is no — because you use a redirect or validated P2PE solution — your CDE is limited to systems that manage the payment flow but never touch card data. If the answer is yes, those systems are in scope, and you must identify every component connected to them.
2. Is the system that handles card data segmented from the rest of your network?
Segmentation is the practice of isolating the CDE from other networks using firewalls, VLANs, access controls or physical separation. Effective segmentation reduces scope by ensuring that systems outside the CDE cannot access cardholder data.
If segmentation is in place, you must document it and demonstrate that it prevents unauthorized access. If segmentation is absent or weak, every system that shares the same network as the CDE is in scope — including corporate workstations, development servers and administrative systems.
3. Can any system outside the proposed CDE connect to a system inside it?
Even with segmentation, systems that can connect to the CDE — whether for administration, monitoring, backup or support — are considered connected-to systems. PCI DSS requires that connected-to systems either meet the same security requirements as in-scope systems or be included in the CDE.
Common examples include jump hosts, centralized logging servers, patch management systems and help-desk workstations. Each must be evaluated. If the connection is necessary, the system is in scope. If it is not necessary, it should be removed or blocked.
4. Does any system outside the proposed CDE share infrastructure with a system inside it?
Shared infrastructure — hypervisors, storage arrays, network switches, DNS servers — can create scope creep. If a virtual machine that processes card data runs on the same hypervisor as a corporate file server, the hypervisor and potentially the file server are in scope unless you can demonstrate effective isolation.
Cloud environments require particular attention. If your payment application runs in a public cloud, you must understand which components the cloud provider secures (the infrastructure) and which you secure (the application, data and access controls). The PCI Security Standards Council publishes guidance on cloud scoping, and many cloud providers offer PCI-compliant services, but responsibility for scoping remains with you.
5. Could any person access cardholder data, even if no system is designed to allow it?
People are part of the CDE. If an administrator, developer or support engineer can access a system that stores, processes or transmits card data — through SSH, RDP, console access or database queries — that person is in scope. You must enforce role-based access, log all access, and ensure that only those with a legitimate business need can reach the CDE.
This extends to third parties. If a vendor, contractor or managed service provider can access your CDE, they must comply with PCI DSS requirements or be subject to your oversight.
How to Document Segmentation and Justify Exclusions
Scoping is not complete until it is documented. Your QSA or SAQ will require evidence that you have correctly identified the boundaries of your CDE and that systems outside it are genuinely isolated.
The core deliverable is a scoping document that includes:
- A narrative description of your payment environment and integration method
- Data-flow diagrams showing how cardholder data enters, moves through and exits your environment
- Network diagrams showing segmentation boundaries, firewalls and access controls
- An inventory of all in-scope systems, applications and databases
- An inventory of connected-to systems and the justification for each connection
- An inventory of out-of-scope systems and the controls that keep them out of scope
Data-flow diagrams are particularly important. They must show every point where card data is collected, transmitted, processed or stored, and every system involved in the flow. If your integration uses tokenization, the diagram must show where tokenization occurs and confirm that your environment never handles plaintext PAN after that point.
Network diagrams must show segmentation controls. If you use VLANs, the diagram must show VLAN IDs and the firewall rules that enforce separation. If you use physical segmentation, the diagram must show separate network infrastructure. If you use cloud network controls, the diagram must show security groups, network ACLs or equivalent mechanisms.
For each system you propose to exclude, you must document why it is out of scope. Common justifications include:
- The system cannot connect to any in-scope system (blocked by firewall rules)
- The system is on a separate network with no routing to the CDE
- The system is used only for purposes unrelated to payment processing
- The system is a development or test environment that never handles production card data
These justifications must be verifiable. Your QSA will test firewall rules, review routing tables and interview administrators. If the evidence does not support the exclusion, the system will be brought into scope.
Common Scoping Mistakes in Cross-Border Architectures
Three mistakes appear frequently in organizations preparing for their first PCI DSS assessment or transitioning to version 4.0.
Assuming the gateway provider handles everything. Even if the gateway is hosted abroad and managed by a third party, your responsibility does not end at the API call. If your application collects card data before sending it to the gateway, your application is in scope. If your web server logs include PANs, your logs are in scope. If your database retains transaction records that include truncated PANs, your database may be in scope depending on what else is stored alongside the truncated number.
Failing to account for connected-to systems. Many organizations focus on the payment application itself and overlook the systems that support it — the jump host used for administration, the SIEM that collects logs, the backup server that stores nightly snapshots. Each of these is a potential path into the CDE and must be secured or excluded.
Relying on segmentation that has not been tested. Segmentation on paper is not the same as segmentation in practice. Firewall rules may be misconfigured, VLANs may be bridged unintentionally, and cloud security groups may allow broader access than intended. Segmentation must be tested — through penetration testing, network scans or configuration reviews — and the results documented.
The Readiness Assessment Process
A PCI DSS readiness assessment begins with scoping. The process includes card-data flow mapping and segmentation review, followed by a gap assessment against version 4.0 requirements, remediation support and preparation of the evidence pack for the final assessment.
Card-data flow mapping and scoping involves interviewing stakeholders, reviewing integration documentation, inspecting network and application architectures, and tracing every path that card data could take through your environment. The output is a scoping document and data-flow diagrams that define the boundaries of your CDE.
Segmentation review involves testing the controls that separate in-scope systems from out-of-scope systems. This may include firewall rule reviews, VLAN configuration checks, cloud network policy audits and, where necessary, penetration testing to confirm that segmentation cannot be bypassed.
The gap assessment compares your current state against every applicable PCI DSS requirement. Version 4.0 introduced new requirements around authentication, logging, encryption and vulnerability management, and many organizations discover gaps even if they were compliant under version 3.2.1.
Remediation support means helping you close the gaps — updating policies and procedures, configuring controls, implementing monitoring and preparing documentation. The goal is not merely to pass the assessment but to establish sustainable security practices.
The final step is preparing the evidence pack for the assessment: policy documents, configuration screenshots, scan reports, access logs, change records and attestations. A well-prepared evidence pack shortens the assessment, reduces back-and-forth with the QSA and increases confidence in the outcome.
The duration for a readiness project is typically six to twelve weeks, depending on the complexity of your environment and the number of gaps identified.
Preparing for Version 4.0 with Cross-Border Gateways
PCI DSS version 4.0 does not fundamentally change scoping principles, but it does introduce requirements that affect cross-border architectures.
Requirement 11.4.7 (effective March 2025) mandates that multi-factor authentication (MFA) mechanisms are reviewed at least once every three months to confirm they remain effective. If your administrators access in-scope systems remotely — common when the gateway is abroad and support is distributed — you must implement MFA and document the review process.
Requirement 10.7 (effective March 2025) requires that failures of critical security control systems are detected, alerted and responded to in a timely manner. If your segmentation depends on firewalls or cloud network controls, you must monitor those controls for failures and have a process to respond.
Requirement 12.3.2 expands the requirement for security awareness training to include phishing and social engineering. If your staff have access to systems that connect to the CDE, they must receive training and the training must be documented.
These requirements do not change the scoping boundary, but they do increase the evidence burden. Organizations that have deferred documentation or relied on informal processes will need to formalize them before the assessment.
Moving from Scoping to Readiness
Scoping is the first step, not the last. Once you know what is in scope, you must ensure that every in-scope system, process and person meets the applicable requirements. That means configuring controls, updating policies, training staff, collecting evidence and testing everything before the QSA arrives.
A PCI DSS readiness project provides scoping and segmentation, gap assessment, remediation support and readiness for your QSA assessment or self-assessment questionnaire. The process includes card-data flow mapping and segmentation review, gap assessment against version 4.0, policy and procedure updates, and QSA and SAQ readiness. Deliverables include a scoping document and data-flow diagrams, a gap assessment report, a remediation plan, and an evidence pack for the assessment.
If your payment gateway sits outside the Kingdom and you are preparing for a PCI DSS assessment, the time to begin scoping is now — before the QSA asks questions you cannot answer.
