PDPL Data Residency vs Localisation

Data residency describes where data is located. Localisation describes a requirement or design choice that constrains where specified data or processing must remain. Neither term, by itself, tells a Saudi buyer who can access information, which entity processes it or whether an AI service satisfies the applicable obligations.

For procurement and governance, the useful question is precise: which information, operation and recipient must meet which location condition, and what evidence proves it? A broad claim that a product is “local” can conceal several different answers.

The PDPL transfer regulation provides conditional cross-border mechanisms. It does not support describing the PDPL as a universal rule that every item of personal data must always be stored in Saudi Arabia.

Use separate words for separate facts

In a business discussion, start by defining the terms you will use. People often say “local data” when they mean local storage, local processing, a locally incorporated supplier or a restriction on overseas access. Those are different facts and need different evidence.

Practical distinctions for evaluating a Saudi AI service

Term in the discussion	Question it should answer	What it does not establish alone
Data residency	Where is the specified information stored?	Where every processing operation or person is located
Data localisation	What rule or chosen boundary requires a location?	That the implemented service respects the boundary
Local processing	Where does the specified computation occur?	The location of all related copies or access
Local incorporation	Which legal entity is established in Saudi Arabia?	The location of the entity's technology and suppliers
Restricted overseas access	Who outside the Kingdom is prevented from seeing or using the information?	Every other security or privacy control

These are working distinctions for a clear buying decision, not a claim that every contract or regulation uses the words identically. Define the intended meaning in the actual requirement and avoid letting an ambiguous label carry several unstated promises.

Terms such as “sovereign” can be especially broad. Ask the supplier to translate the claim into specific commitments about location, access, authority and control. The buyer can then assess each commitment against the actual need.

Compare two proposals without judging by ownership alone

Consider a hypothetical Saudi engineering practice choosing an AI service for project correspondence. The material includes project documents and personal contact details. Proposal A comes from a Saudi-incorporated company and describes its product as local. Proposal B comes from an international provider offering a specified Saudi service arrangement.

The buyer should not infer the processing location from either company's ownership or headquarters. It should ask both providers the same concrete questions about the particular product, configuration, support arrangement and recipients.

Suppose Proposal A uses a local primary store but allows a specialist overseas support team to inspect selected content. Suppose Proposal B offers a defined local processing arrangement with a separately controlled support route. These are illustrative facts to investigate, not claims about any actual vendor.

The comparison should identify the applicable requirement and test each proposal against it. A local company can have an overseas dependency; an international company can offer a locally bounded service. Neither observation settles the full legal or security assessment.

Find the source of the location requirement

Ask who requires the location boundary and why. It may arise from an applicable law, sector rule, government data requirement, contract, customer commitment or internal policy. These sources can have different scopes and different owners.

Record the exact requirement and its applicability. Does it concern a category of information, a particular entity, a cloud service, an operation or a contract? A requirement that applies to one customer engagement should not silently become a factual claim about every Saudi business.

Distinguish an obligation from a risk preference. An organisation may choose a stricter boundary for commercial or operational reasons. That can be reasonable, but the decision should be described as its chosen policy rather than attributed to a regulator without evidence.

Identify who can interpret or change the requirement. A technical team cannot waive a legal obligation, while an internal preference may have an authorised exception process. Knowing the source prevents the project from negotiating with the wrong person.

Check the current version before applying an old rule

NCA states that Cloud Cybersecurity Controls, CCC–2:2024, were updated in relation to data-localisation requirements. Read the applicable current text and scope rather than repeating a location rule from an older presentation.

CST's approval decision also records that Cloud Computing Service Provisioning Regulations version 4 superseded the earlier framework version 3, effective 10 October 2023. A familiar document title or historical regulator name is not enough to establish the current requirement.

For the engineering practice, the review record should identify the documents actually relied on and the conclusion about their applicability. The purpose is not to collect every Saudi rule, but to establish the requirements that govern this service and information.

Do not infer that a revision removes every other relevant constraint. Different obligations can coexist, and a contract or sector condition may remain relevant even when another source changes. The responsible owner should explain the combined conclusion.

Define the information covered by the promise

A location promise needs an object. “Your data stays here” may refer only to uploaded files, while the buyer assumes it also covers prompts, generated summaries, support attachments and other information created through the service.

Describe the relevant categories in language that procurement and technical teams both understand. The engineering practice might distinguish project correspondence, contact information and service-generated summaries. The important point is whether the commitment covers the information the organisation actually cares about.

Do not assume that every category has identical legal status or business sensitivity. A public brochure, confidential project instruction and individual's contact details can require different analysis. The classification should reflect the content and use, not merely the file extension.

Ask how the supplier handles material that crosses categories. A generated summary can combine public project information with a private contact detail. The promise should not become unclear simply because the service creates a new representation of the original material.

Distinguish storage from processing and human access

Storage location answers where a specified copy is held. Processing location answers where a particular operation occurs. Human access answers who can inspect or use the information. A meaningful requirement can address one or more of these, but should say which.

In Proposal A, a local primary store does not explain the overseas support arrangement. The buyer needs to know what support staff can see, under what conditions and whether the relevant access is part of the approved service design.

In Proposal B, a local processing commitment should be tied to the purchased product and configuration. A provider's general regional capability does not prove that the buyer's selected feature or support plan uses that capability.

The privacy and legal owners should assess any actual cross-border disclosure or transfer arrangement. The technical team provides the facts. A location diagram can support the decision, but it cannot make the legal conclusion without the relevant purpose, recipient and conditions.

Test a sales claim against a contractual commitment

Collect the statement the buyer is relying on and identify where it becomes binding in the commercial arrangement. A presentation may describe an available option, while the order form selects a different service. Resolve that mismatch before treating the promise as a project requirement.

Write the commitment with sufficient specificity to verify. Identify the service, information, operations, permitted exceptions and change process. Avoid a sentence so broad that the supplier interprets it narrowly and the customer interprets it as covering everything.

Ask who is responsible when a subcontractor participates. The supplier should explain how its commitment applies to the actual service chain. The buyer should not have to discover after launch that an important operation was excluded because another entity performed it.

Make the evidence obligation usable. A promise to provide information on request is more valuable when the contract owner knows which information is available, who supplies it and how material changes are communicated.

Evaluate control alongside location

A local location can be part of a sound design, but location alone does not determine whether access is appropriate. The engineering practice still needs to know which users can retrieve each project's correspondence and who can approve broader access.

Consider the difference between physical proximity and decision authority. A server may be nearby while the customer has little ability to inspect settings, challenge changes or stop a particular use. Conversely, a well-defined service arrangement can provide meaningful control over a specified activity.

Assess the ability to enforce the chosen boundary. Can the organisation prevent an unapproved feature from being enabled? Does a change require an authorised decision? Can it stop the affected activity if the supplier no longer supports the agreed arrangement?

Keep this control analysis separate from national ownership preferences. The organisation may value local capability development or local commercial relationships. Those are legitimate procurement considerations, but they should not be used as evidence for a technical fact they do not establish.

Decide what evidence is sufficient for the claim

Match evidence to the statement. A corporate registration document supports the identity of an entity. A service specification supports a product commitment. An observed configuration can support how the purchased environment is set up. None should be used to prove an unrelated claim.

Distinguish a general provider certificate from evidence about the particular service. The certificate may be relevant, but the buyer still needs to understand its scope and whether the selected product, location and operating arrangement are covered.

For the two proposals, prepare a comparison showing each requirement, the supplier's answer, the evidence and unresolved questions. This makes an honest unknown visible. A confident sales statement should not automatically outrank a precise response that identifies a limitation.

Where independent verification is proportionate and available, define what question it should resolve. An assurance exercise that checks the wrong service or period can create confidence without answering the buyer's actual concern.

Handle exceptions without making the boundary meaningless

A proposed exception should state the activity, information, duration and reason. “Global support may apply” is too vague when the organisation relies on a local-access restriction. The responsible team needs to understand the actual exception before deciding whether it is acceptable.

Review exceptional access as a specific arrangement. Who requests it, who approves it, what is visible and how does it end? The answer should align with the legal assessment and contract, not depend on an informal support conversation.

Consider whether a less revealing method can solve the issue. A supplier may be able to investigate with a non-personal reproduction or limited diagnostic description. That possibility should be assessed against the real technical need rather than assumed sufficient for every fault.

Record the consequence if the exception cannot be justified. The organisation may need another support method, a restricted feature or a different service. An exception process should preserve the purpose of the boundary, not turn it into a promise that disappears whenever inconvenient.

Account for cost and continuity without inventing a legal shortcut

A chosen location boundary can affect available services, support, resilience and operating effort. Evaluate those consequences openly. The business case should describe the tradeoff between the required control and the capabilities the organisation can actually obtain.

Do not use a cheaper offer as evidence that a legal condition can be ignored. Equally, do not assume that the most restrictive design always creates the best business outcome. Identify the real requirement first, then compare compliant or otherwise appropriately approved alternatives.

For the engineering practice, a narrower AI feature may be preferable if the full product cannot meet the required arrangement. The team might begin with a defined document task while postponing a feature whose dependencies are unresolved.

Plan what happens if the selected arrangement becomes unavailable. The organisation should know whether it can continue a manual process, move to an approved alternative or pause the affected activity. Continuity planning should respect the same boundary rather than silently bypass it during disruption.

Review changes against the original promise

A provider can change a service without changing its brand. New features, support methods, recipients or commercial terms may affect the original location and access assessment. Assign an owner who receives and evaluates relevant changes.

Keep the purchased configuration connected to the decision record. If a team enables an optional feature later, it should know whether that feature is covered by the existing assessment. The default answer should come from evidence, not from familiarity with the supplier.

Review actual use as well as provider notices. Staff may upload material through an alternative product or use an unassessed integration. The organisation should understand why those paths emerge and provide a workable authorised route.

The requirement remains useful when it is precise enough to test over time. A broad “Saudi hosted” label is difficult to govern; a defined commitment about information, processing and access creates a decision that can be revisited when facts change.

Keep the decision understandable to a replacement supplier as well. If the requirement can only be explained through the incumbent's product language, rewrite it around the information and operation the organisation needs to protect. That makes future comparisons more reliable and reduces dependence on an ambiguous marketing term.

Ask for a precise answer to a precise requirement

The engineering practice should choose between the proposals using the actual obligation, intended service and available evidence. Company nationality, a regional badge or a familiar phrase can inform a conversation, but none replaces that comparison.

The Saudi PDPL and AI guide explains the wider processing responsibilities. Cross-border transfer review addresses overseas arrangements, NCA control applicability clarifies security scope and CST guidance for technology companies explains the regulator's AI guidance context. Impact assessment examines the consequences of the proposed design.

The Saudi AI authority guide collection connects these distinctions with business decisions. AI integration and delivery support can help translate a precise requirement into an implementable service boundary. Start by stating what must remain where, who may access it and why.