Saudi cloud services: six decisions before deployment

A Saudi cloud deployment should not begin with the vendor’s order form.

The legal and operational decision requires answers to several connected questions: what service is actually being supplied; whether the provider falls within the Saudi cloud framework; where data is stored and who can access it; which cybersecurity controls apply; how the contract allocates responsibility; and whether the customer can leave the service without losing continuity, evidence or control of its data.

These questions apply differently to a global SaaS provider, a hyperscale infrastructure provider, a Saudi reseller and an enterprise customer. They should therefore be answered from the live service architecture—not from marketing terminology.

This guide reflects official CST, NCA and SDAIA materials available on 14 August 2026. It is general information and does not determine the requirements for a particular provider, tenant, sector or dataset.

Six decisions before deployment

Before deployment, the parties should settle six connected decisions:

1. Provider status: who provides which cloud layer, to whom, and from where?
2. Service and data architecture: where are production, backups, logs, support and administration located?
3. Personal-data governance: who is controller or processor, and does overseas access engage the Saudi transfer framework?
4. Cybersecurity evidence: which controls apply, who implements them, and what evidence proves that they operate?
5. Contract allocation: do the documents match the technical and regulatory design?
6. Exit plan: can data, services and security evidence be recovered or migrated on time?

Treating these as one deployment decision prevents a familiar failure: a contract is signed, the technical team configures the service, and only then does legal discover that the promised data location, support model or sub-processor chain is different from the system being launched.

1. Decide the provider status from the substance of the service

CST’s current framework is the Cloud Computing Service Provisioning Regulations, version 4, supported by the provider and registration guides approved under Decision 506/1445. The decision states that these documents replaced the earlier version 3 regulatory framework and took effect on 10 October 2023.

The first question is therefore not simply, “Is this technology?” It is whether the entity is providing a cloud computing service within the current framework and, if so, in what capacity and category.

The analysis should identify:

• the contracting provider and every material affiliate;
• whether the service is IaaS, PaaS, SaaS or a combined model;
• which entity controls the infrastructure and customer relationship;
• whether a reseller, managed-service provider or marketplace participates;
• the intended Saudi customers and sectors;
• the location of service delivery, support and administration; and
• which entity will hold any required CST registration.

CST maintains a cloud-computing registration service and requires applicants to meet the current framework and guide. The service page identifies different registration classes and supporting facility or information-security evidence. A provider should test its actual model before offering the service, using a local label or appointing a reseller. An enterprise customer should also verify the status represented by its provider rather than assume that a global brand settles the Saudi position.

The output should be a short provider-status memorandum: the regulated activity, responsible entity, registration conclusion, customer scope and any conditions to launch.

2. Define the service and data architecture before legal drafting

“Saudi region” is not a complete architecture.

A deployment map should cover:

• primary hosting and processing locations;
• replication, disaster-recovery and backup locations;
• identity, security, analytics and logging systems;
• customer-support and engineering access;
• remote privileged administration;
• group-company access;
• sub-processors and their countries;
• encryption and key-management responsibility;
• customer-configurable location controls; and
• deletion, return and migration paths.

The selected cloud model changes the responsibility boundary. CST’s cloud materials distinguish IaaS, PaaS and SaaS: the provider assumes different layers of the technology stack in each model. That boundary should appear consistently in the solution design, security responsibility matrix and contract.

The customer should request evidence, not adjectives. “Local”, “sovereign”, “isolated” and “compliant” may each describe a useful feature, but they do not answer where support occurs, whether telemetry leaves the Kingdom, who controls encryption keys or whether an overseas administrator can view personal data.

3. Separate hosting location from personal-data compliance

Saudi hosting can be important, but it is not the whole PDPL analysis.

Where the service processes personal data, the parties should identify:

• the controller and each processor;
• defined processing purposes and the applicable legal basis;
• categories of data and data subjects;
• any sensitive data;
• instructions and restrictions imposed on processors;
• privacy information and data-subject request workflows;
• retention and deletion periods;
• breach escalation and cooperation; and
• the record of processing and assessment evidence.

Overseas access requires particular attention. A production database may remain in Saudi Arabia while global support, engineering, fraud, security or group teams obtain remote access. SDAIA’s transfer materials require the controller to examine the purpose, recipient, destination, route, safeguards and any required risk assessment. A contract stating “data is hosted in Saudi Arabia” does not answer those questions.

The data architecture should therefore distinguish storage location from access location, processing location and onward disclosure. The approved system permissions should implement the legal decision, including restrictions on downloads, support access, logging and escalation.

For the transfer analysis itself, see our source-led guide to Saudi personal data and overseas access.

4. Convert cybersecurity claims into an evidence matrix

NCA’s current page identifies the Cloud Cybersecurity Controls (CCC – 2: 2024) and notes that the update reflects changes relating to data-localisation requirements. The controls address cloud service providers and cloud service tenants.

NCA describes a defined scope that includes government entities and private-sector organisations owning, operating or hosting critical national infrastructure. It also strongly encourages other organisations in the Kingdom to use the controls as best practice. A deployment may additionally be subject to sector rules, customer requirements or other NCA controls.

The practical task is to convert the applicable control set into an evidence matrix. For each material control, record:

• whether the provider or tenant is responsible for implementation;
• the technical or organisational measure;
• the evidence available before go-live;
• any customer configuration dependency;
• the person approving residual risk;
• the review frequency; and
• the contractual remedy if the control or evidence changes.

Evidence may include independent assurance reports, certifications, architecture diagrams, penetration-test summaries, vulnerability-management records, incident procedures, business-continuity tests, logging capability and sub-provider governance. A certificate can be valuable, but it should not be treated as proof of every customer-specific configuration or obligation.

At minimum, the deployment team should settle identity and privileged access, encryption and key management, tenant segregation, event logging, incident response, vulnerability management, resilience, backup restoration and third-party risk.

5. Make the contract describe the approved deployment

The commercial agreement, data-processing terms, security schedule and technical order form should reflect the same approved arrangement.

The contract should address the allocation of responsibility for:

• precise services, regions and service levels;
• the parties’ provider, tenant, controller and processor roles;
• approved data and support locations;
• access by affiliates, personnel and sub-processors;
• change control for locations and sub-processors;
• security responsibility and customer dependencies;
• incident notification, evidence preservation and cooperation;
• regulatory assistance and audit evidence;
• availability, continuity and disaster recovery;
• data return, deletion and verification;
• suspension and lawful-access processes;
• intellectual-property and licence rights in data, configurations and outputs;
• liability allocation; and
• transition support on termination.

A global template may allocate commercial risk efficiently but still fail to reflect Saudi provider status, a local deployment representation or overseas access. Conversely, a heavily negotiated schedule is ineffective if the implementation team is free to select a different region or enable unrestricted support access.

The final legal review should compare the executed documents with the approved architecture and evidence matrix. It should not review the words in isolation.

6. Approve the exit plan before go-live

Cloud exit is a deployment requirement, not a termination afterthought.

The customer should know:

• which data and configurations can be exported;
• the available format and transfer method;
• whether logs and security evidence are included;
• how long extraction and transition will take;
• what assistance is available and at what cost;
• when access ends;
• how backup and residual copies are deleted; and
• how deletion is evidenced.

For a material service, the exit plan should be tested against continuity needs and dependency on proprietary tools. The provider should also be able to perform an orderly suspension or termination without compromising other tenants, required retention or security obligations.

The contract should preserve enough time and access for migration. An obligation to “return data on termination” is not operational if the export is incomplete, unusable or delivered after the replacement system must be live.

The pre-deployment decision record

Before authorising production use, management should receive a concise record confirming:

1. the provider status and registration conclusion;
2. the approved service and data architecture;
3. the PDPL roles, overseas-access analysis and required safeguards;
4. the applicable cybersecurity controls and evidence gaps;
5. the executed contractual allocation and outstanding conditions; and
6. the tested continuity and exit plan.

The record should identify the responsible people and the changes that require reassessment. A new sub-processor, region, support location, sensitive-data use case or material architecture change should trigger a review of the approved arrangement.

Cloud legal work is strongest when it determines the operating design before launch. The objective is not to produce the longest security schedule. It is to ensure that registration, architecture, permissions, evidence, contract and exit arrangements describe one controlled service.

Temairik Law’s cloud and technology practice advises providers and enterprise customers on Saudi cloud regulation, technology contracts and deployment governance. Personal-data architecture and overseas access are addressed through our data-protection practice.

This publication is general information only and does not constitute legal advice. Requirements must be assessed against the service, provider, customer, sector, data, system architecture and official materials in force at the relevant time.