Saudi PDPL compliance starts with a decision about how the service will operate. An Egyptian or Indian company plans to supply AI-assisted customer operations to a Saudi financial business. Hosting, support access and subprocessors extend beyond Saudi Arabia. The customer needs evidence that the proposed processing, contracts and supplier chain meet the applicable requirements.
The engagement establishes which activities can proceed, which need changes, and which depend on customer or regulatory action. Its outputs connect the data map, legal assessment, contract terms and operating procedures. Live overseas access should follow evidence of a lawful transfer route and any required sector approvals.
Who the engagement is for
The engagement suits suppliers preparing a Saudi customer proposal, negotiating procurement terms or changing an existing delivery model. It covers customer support, document handling and analytics where identifiable people’s data enter the service.
Saudi territorial scope reaches processing in the Kingdom and overseas processing of personal data concerning individuals residing there. An offshore supplier therefore needs a scope assessment even without a Saudi establishment. The relevant test is the processing and affected individuals, alongside the statutory definitions of controller and processor. (Personal Data Protection Law, arts. 1(18)–(19) and 2(1).)
A supplier proposing to provide regulated financial services itself needs a separate licensing assessment. Employee systems, healthcare services, public-sector deployments and independent credit decisions can also require a different scope. The Saudi Arabia AI regulation hub explains the wider country context.
The work and its deliverables
Establish the processing and transfer map
The first stage records the customer, supplier entities, model providers, hosting operators and support teams. It follows data through collection, prompts, retrieved records, outputs, logs, human review, backups and deletion. Each flow identifies its purpose, data categories, people affected, destination countries and access permissions.
Roles follow actual decisions about processing. A supplier working within the customer’s instructions can act as processor. Independent reuse for product development, model training or cross-customer analytics needs a separate purpose and role assessment. Departing from instructions can attract controller treatment for the resulting violation. (Personal Data Protection Law, art. 8; Implementing Regulation, art. 17.)
The deliverable is a processing and transfer map with role allocation, unresolved facts and proposed changes. It also identifies responsibility for processing records and for checking each subprocessor.
Set the permitted uses and operating procedures
The review assigns a lawful basis to each purpose. The customer’s commercial contract with the supplier does not itself establish an individual’s agreement. Legitimate interests require the statutory conditions and a documented assessment; that route excludes sensitive data. (Personal Data Protection Law, arts. 5–6; Implementing Regulation, art. 16.)
Data classification affects the design. Identity biometrics and health information are sensitive data. Credit data have separate controls, so financial information should not be assigned one undifferentiated classification. Solely automated decisions also need specific assessment, including the applicable explicit-consent requirement. (Personal Data Protection Law, arts. 1(11), 1(15) and 24; Implementing Regulation, arts. 11(2) and 27.)
The resulting procedure requirements cover privacy information, access and correction requests, retention, deletion, incidents and responsibility for implementation. The retention schedule covers purpose limits, statutory retention duties, backups and deletion evidence. A processing impact assessment is added where its statutory triggers apply. Those triggers include sensitive-data processing and specified data-linking, monitoring and automated-processing activities. (Personal Data Protection Law, arts. 4, 12–13, 18 and 22; Implementing Regulation, arts. 3–4, 8 and 25.)
Incident escalation must preserve the available response time. The Implementing Regulation requires qualifying controller reports within 72 hours of awareness. Selected Saudi transfer clauses can impose shorter importer and exporter deadlines. The incident procedure therefore assigns separate customer, supplier and subprocessor steps. (Implementing Regulation, arts. 17(1)(d) and 24; SDAIA Standard Contractual Clauses, cl. 13, Templates 2–3.)
Establish an available transfer route
Saudi Arabia data transfers require more than selecting a hosting location. Granting overseas access can constitute a transfer, including access by support staff to a Saudi-hosted system. Further disclosure to another provider needs onward-transfer analysis. (SDAIA Standard Contractual Clauses, definitions; Transfer Regulation, art. 5.)
The assessment first checks the transfer purpose and conditions under Article 29 of the Personal Data Protection Law (PDPL). It then tests any applicable adequacy decision or exemption under the Transfer Regulation. Article 4 links specified exemption cases to particular safeguards. A Saudi contractual-clause signature alone cannot establish eligibility for every recurring outsourced service. (Personal Data Protection Law, art. 29; Transfer Regulation, arts. 2–4.)
Where Saudi clauses support the available route, the parties select the template matching their actual roles. Controller-to-processor and processor-to-processor transfers use different templates. The parties must complete the transfer and security appendices and address onward access, conflicting foreign-law duties and suspension. EU clauses cannot substitute for this Saudi assessment. The transfer risk assessment is separately required for Article 4 exemptions and continuous or large-scale sensitive-data transfers. (SDAIA Standard Contractual Clauses, Rules 3–10 and Templates 2–3; Transfer Regulation, art. 7.)
The deliverable records the selected route, supporting evidence, required documents and conditions preventing activation. If the proposed arrangement cannot qualify, the next decision concerns narrower data use, a different recipient or operating model, or postponement of the affected feature.
Resolve sector conditions and complete the contract pack
The Saudi customer’s licence determines the sector review. Banks must seek written no-objection from the Saudi Central Bank (SAMA) for proposed outsourcing to overseas third-party providers within the outsourcing rules. This requirement extends beyond material outsourcing. (SAMA Rules on Outsourcing, paras. 3–7 and 42.) Finance companies must require providers not to subcontract material functions. Payment institutions have a separate material-outsourcing test. (SAMA Rules on Outsourcing for Finance Companies, para. 13(s); Payments and Payment Services Implementing Regulations, art. 27.)
Covered public and hybrid cloud arrangements require SAMA approval before cloud use or contract signature. Overseas cloud services require explicit approval under the applicable cloud controls. These requirements need their own customer action and evidence. (SAMA Cyber Security Framework, control 3.4.3(4)(a)–(b).)
The contract pack addresses processing instructions, permitted AI uses, security obligations, subprocessor approval, incidents, rights assistance, audit access, deletion and exit. Selected transfer documents sit alongside the customer and vendor terms. The procurement pack records supporting evidence, unresolved approvals, responsible owners and implementation actions. Sector restrictions may require changing the supplier chain before those documents can be finalised.
Boundaries that change the scope
Data protection officer (DPO) appointment, registration and contact arrangements require separate trigger checks. Core monitoring or sensitive-data activities can trigger a DPO requirement. The Saudi Data and Artificial Intelligence Authority (SDAIA) also provides an overseas registration process; its existence does not establish a universal duty for every foreign processor. The assessment distinguishes statutory requirements, certification conditions and customer demands. It does not infer a universal Saudi-company requirement. (Implementing Regulation, art. 32; DPO Appointment Rules, arts. 3–9; Controller Register Rules, introduction and arts. 1–2; SDAIA Overseas Entity Registration, requirements; Accreditation Certificate Rules, arts. 3–4.)
Egyptian or Indian operations also need their own legal review. The supplier’s location, access arrangements and independent data uses determine that review. In India, the principal processing duties under the Digital Personal Data Protection Act and the overseas-contract exemption are not yet operative on 4 November 2026. That review must address the continuing Information Technology Act regime and applicable security and incident duties. (Digital Personal Data Protection Act 2023, ss. 17(1)(d) and 44(2); commencement notification G.S.R. 843(E), para. (c).) Saudi transfer documentation cannot resolve conflicting recipient-country duties.
An internal AI risk decision cannot authorise processing that the law prohibits. The Saudi AI risk-acceptance analysis explains that distinction. Where the same data flows engage EU law, Data Protection and GDPR for AI addresses that additional scope. Suppliers negotiating parallel European sales can also use AI supplier contracts for EU and UK enterprise sales.
The engagement covers legal documentation and implementation coordination. Technical testing, statutory certification, regulated financial-service licensing, litigation and appointment to a statutory office require separately agreed scope and the necessary authorisation. Customer regulatory applications remain subject to the customer’s responsibilities and the authority’s decision.
Information needed to scope the work
Provide the documents available at the current stage:
- The service description, customer type and licence, intended functions and launch dependencies.
- A data-flow diagram, data categories, processing purposes and all hosting, support and subprocessor countries.
- Customer contracts, data-processing terms, model-provider terms and the current subprocessor list.
- Security and access descriptions, retention settings, incident procedures and available impact assessments.
- Procurement questions, existing approvals and details of proposed training or independent reuse.
The initial scope identifies missing evidence and assigns it to the supplier or customer team responsible.
Buyer questions
Can Saudi hosting resolve the overseas-access issue?
Saudi hosting addresses one part of the architecture. Overseas support, model calls, logs or backups can still create transfer questions. An overseas provider can also trigger sector outsourcing requirements even where storage remains local. (SDAIA Standard Contractual Clauses, definitions; SAMA Rules on Outsourcing, para. 42.)
Can the existing global data-processing agreement be used?
It can provide the starting document. The review tests it against Saudi processing obligations, the parties’ actual roles and any available transfer route. The selected Saudi clauses require their own completed particulars and precedence terms. (Implementing Regulation, art. 17; SDAIA Standard Contractual Clauses, cls. 2 and 5.)
Can customer data be used to improve the AI service?
The answer depends on the purpose, role, lawful basis and applicable sector restrictions. General product training cannot be assumed to fall within instructions to deliver customer support. Any permitted use needs matching notices, contract terms and controls. (Personal Data Protection Law, arts. 5–8 and 10–13; Implementing Regulation, art. 17.)
Does every supplier need a Saudi DPO or local company?
Those conclusions require separate legal triggers. The DPO rules permit an external appointment, while registration and sector requirements need their own analysis. Contractual contact arrangements should identify who responds without inventing a statutory local-presence obligation. (DPO Appointment Rules, arts. 4–9; Controller Register Rules, introduction.)
What happens if the intended delivery model cannot meet the conditions?
The review identifies the affected processing and the evidence or change needed. The parties can assess a narrower feature, different provider or revised access model. Activation of the affected processing remains pending where a required legal condition or approval is missing.
Assess Saudi data protection requirements for your service
Contact Licentium with the proposed service, customer sector, supplier countries and available data-flow and contract documents to scope the review.