Saudi PDPL cross-border transfers for offshore AI support and hosting
When offshore AI support for a Saudi financial business is a PDPL transfer, which sector approvals apply, and how to set access, transfer terms and contracts.
Saudi hosting can coexist with offshore AI support only where overseas access to personal data has a lawful transfer route, satisfies sector rules and is permitted by the contract. A Saudi PDPL data transfer assessment must therefore cover what foreign personnel and systems can see, receive and retain. Server location answers only part of that assessment. (Personal Data Protection Law, art. 29; SDAIA Standard Contractual Clauses, definitions.)
A Saudi financial business plans to use customer-service AI hosted in the Kingdom. An Indian supplier’s engineers need remote support access, while a UAE subcontractor will monitor the service. The business’s agreement with the supplier provides that all data stays local. The recommended starting design keeps identifiable production data within Saudi operations. Offshore access should remain disabled until the customer establishes the relevant permissions and the parties amend the contractual promise.
- Remote viewing can constitute a transfer even without a downloaded file. The Saudi clauses expressly include granting access. (SDAIA Standard Contractual Clauses, definitions.)
- Signing the Saudi standard contractual clauses (SCCs) does not establish eligibility for every outsourcing arrangement. The Transfer Regulation links exemptions to specified circumstances and safeguards. (Transfer Regulation, art. 4.)
- The customer’s licence can change the supplier chain. Banks, finance companies and payment institutions have different outsourcing requirements. (SAMA Rules on Outsourcing, para. 42; Finance Company Outsourcing Rules, para. 13(s); Payments Implementing Regulations, art. 27.)
- Logs, model calls, incident exports and onward disclosures need their own entries in the data map. Identifiability and purpose determine their treatment. (PDPL, arts. 1(4)–(5), 29; Transfer Regulation, art. 5.)
- Use a Saudi operating team and anonymous diagnostic material where an offshore personal-data route cannot be established. Sector restrictions and the contract still require separate attention. (Implementing Regulation, art. 9; SAMA Rules on Outsourcing, para. 42.)
Map the actors and every access event
The Saudi business normally determines why its customers’ information is processed and is the controller. The Indian supplier is a processor when it acts on that business’s instructions. The UAE monitor is a subprocessor when engaged by the supplier for the same instructed purpose. A separate hosting company or model provider needs its own classification. These roles follow the actual activity. Supplier reuse for its own training or product improvement requires a separate assessment. (PDPL, art. 1(18)–(19); Implementing Regulation, art. 17.)
Record each recipient’s legal entity, country, purpose, access method, data fields and retention period. Cover the following flows:
- Customer conversations, voice recordings, attachments and account information used to answer requests.
- Prompts, retrieved documents, outputs and embeddings sent to the inference service or retained for evaluation.
- Support sessions, screen sharing, database queries, terminal output and any ability to reveal production records.
- Application logs, identifiers, IP addresses and model telemetry sent to the UAE monitor or another observability service.
- Incident packages, crash dumps, screenshots and tickets exported to engineering, security or model-provider teams.
- Backups, disaster-recovery copies and further recipients used by either supplier.
An Indian engineer who reads a Saudi customer record receives access abroad. A Saudi-hosted application calling a foreign model endpoint can transmit personal data in the prompt. A UAE monitoring dashboard can expose identifiers even when the conversation database remains in Saudi Arabia. The same analysis applies to subsequent access granted by the Indian supplier. (PDPL, arts. 1(4)–(5), 29; Saudi SCCs, definitions; Transfer Regulation, art. 5.)
Classify the content before choosing a transfer route. Financial information is not automatically “sensitive data” under the definition in the Personal Data Protection Law (PDPL). Health information or identifying biometric data within a conversation can be sensitive. Credit data also have specific consent and disclosure controls. (PDPL, arts. 1(11), 1(15), 24; Implementing Regulation, art. 27.)
Removing a name may leave an identifiable account, device or transaction trail. Pseudonymisation reduces exposure but does not establish anonymity. Offshore diagnostics fall outside the personal-data analysis only when identification cannot be restored, including through indirect identifiers. The anonymisation process itself must be lawful and tested. (Implementing Regulation, arts. 1(7)–(8), 9.)
Identify the financial-sector restriction first
The description “Saudi financial business” does not establish which outsourcing rules apply. Procurement should obtain the customer’s licence and a written classification of the proposed function.
For a bank within the Rules on Outsourcing of the Saudi Central Bank (SAMA), proposed outsourcing to an overseas third-party provider requires written SAMA no-objection. Paragraph 42 extends beyond material outsourcing. A Saudi server does not remove that condition when the outsourced service is supplied from abroad. Material-function subcontracting also requires prior bank approval and SAMA no-objection. (SAMA Rules on Outsourcing, paras. 3–7, 19, 42.)
For a finance company, outsourced sharing, transfer, processing or storage of beneficiary data independently makes a function material. Routine support and call-centre labels do not override that definition. Material outsourcing requires the relevant SAMA no-objection, and the contract must prohibit subcontracting material functions. If the UAE monitoring subcontract covers such a function, redesign the chain unless an applicable SAMA exemption permits it. (Finance Company Outsourcing Rules, Chapter 1(b), paras. 13(s), 14–15, 22 and Appendices 1–2.)
Payment institutions have their own material-outsourcing requirements, including prior SAMA no-objection where Article 27 applies. Changes to material outsourcing arrangements and material new outsourcing agreements also require prior SAMA no-objection. Investment firms and insurers need assessment under their own regulator’s rules; the bank rule cannot be applied to them by description alone. (Payments and Payment Services Implementing Regulations, art. 27; art. 39(1), (2)(b)(iii).)
Covered public or hybrid cloud arrangements also require SAMA approval before cloud use or contract signature. Overseas cloud use requires explicit approval under the applicable controls. (SAMA Cyber Security Framework, control 3.4.3(4)(a)–(b).)
If the cloud rules of the Communications, Space and Technology Commission (CST) cover the arrangement, a registered provider must obtain the subscriber’s advance consent before transferring, storing or processing its content abroad, even temporarily. That consent does not replace the PDPL route, SAMA requirements or applicable government-data restrictions. (CST Cloud Computing Services Provisioning Regulations, v4, Arabic paras. 3-1-1, 3-3-2, 3-3-6, 3-3-8.)
Determine what “monitoring” means. If the UAE subcontractor provides managed security operations within the licensing rules of the National Cybersecurity Authority (NCA), those rules’ Saudi facilities, data processing and service-delivery requirements can prevent that offshore operating model. An application-performance dashboard is not automatically the same service. (NCA Regulatory Framework for Licensing Managed Security Operations Center Services, sections 4–6, particularly 6.4–6.7.)
Establish an available PDPL transfer route
The Personal Data Protection Law and its 2024 Regulation on Personal Data Transfer Outside the Kingdom require separate checks of purpose, protection and applicable exemptions. The customer must also establish a lawful basis for the underlying processing and provide the required information to individuals. Signing the outsourcing contract does not supply every permission. (PDPL, arts. 5–6, 12–13, 29; Transfer Regulation, arts. 2–4.)
Start with a permitted transfer purpose. Customer support may serve the individual receiving the service; necessary central processing can support the controller’s operations. A permitted purpose does not remove the remaining transfer conditions. National-security and vital-interest restrictions continue to apply, alongside the required protection and minimum-data conditions unless a specified exception applies. (PDPL, art. 29(1)–(4); Transfer Regulation, art. 2.)
An adequacy route needs an applicable determination by the Saudi Data and Artificial Intelligence Authority (SDAIA) covering the destination. Obtain the current official decision and check its territorial and substantive scope before relying on it for India, the UAE or a particular free zone. A destination’s privacy statute or an EU adequacy decision does not establish Saudi adequacy. (Transfer Regulation, art. 3.)
Where adequacy is unavailable, examine the actual Article 4 exemption:
- A non-recurring or time-limited transfer involving a limited number of individuals may use Saudi SCCs or the specified recipient certification. The data must not be sensitive. A continuous support entitlement should not be recast as isolated incidents merely because staff log in separately. (Art. 4(2)(b).)
- Necessary central operational processing can qualify where the controller belongs to a multinational group, using the safeguards specified for that case. Establish the group relationship and operational necessity. An Indian supplier’s international business does not establish that the Saudi controller meets this condition. (Art. 4(2)(c).)
- A transfer providing a service or benefit directly to the individual can qualify where it respects that individual’s expectations and interests. This route requires the recipient’s accreditation certificate from a body licensed by SDAIA, and excludes sensitive data. SCCs alone do not meet that case’s safeguard requirement. (Art. 4(2)(d).)
The public-body and scientific-research cases have their own conditions. Routine commercial support cannot rely on those descriptions without the corresponding facts. The PDPL’s extreme-necessity exception concerns life, vital interests or infectious-disease circumstances; an ordinary service outage does not establish it. (Transfer Regulation, art. 4(2)(a), (e); PDPL, art. 29(3).)
For the proposed recurring support arrangement, nothing described establishes adequacy, a qualifying multinational operation or recipient certification. Keep personal-data access closed while the customer investigates those routes. Where certification is proposed, obtain the actual certificate, the issuer’s licence, recipient identity, scope and validity. A general security certificate is insufficient evidence of this specific mechanism. (Transfer Regulation, art. 4; Accreditation Certificate Rules, arts. 1, 7–9.)
A transfer risk assessment is required before an Article 4 transfer and for continuous or large-scale sensitive-data transfers. Assess the purpose, geography, safeguards, minimisation, possible harm and protective measures. A separate processing impact assessment can also be required for the AI service. Each onward recipient needs an available route; passing the first transfer does not clear the chain. (Transfer Regulation, arts. 5, 7; Implementing Regulation, art. 25.)
Select Saudi SCCs only after establishing eligibility
Where the selected route permits SCCs, Template 2 fits the Saudi controller’s transfer to the Indian processor. Template 3 fits the Indian processor’s onward transfer to the UAE subprocessor, including the required accession arrangements. If the Saudi business transfers data directly to the UAE provider as its processor, that transfer instead calls for Template 2. A recipient acting as an independent controller requires reassessment of both the role and the relevant template. (Saudi SCCs, templates; cl. 7; cl. 13, Templates 2–3, paragraph 8.)
Complete the parties, transfer-description and security appendices. Identify remote access as well as stored copies, the permitted purposes, data subjects, fields, retention and safeguards. Preserve the approved clauses, their precedence and Saudi governing-law and jurisdiction provisions. EU SCCs can address a separate EU transfer obligation but do not replace Saudi terms. Foreign law that prevents performance of the Saudi clauses can make the proposed route unavailable. (Saudi SCCs, Rules 3–10; cls. 2, 5, 8; Appendices 1–3.)
Build the service around the permitted access
The recommended architecture separates production support from offshore engineering. Keep the production application, inference endpoint, retrieval store, identifiable logs, backups and privileged customer-data access within the approved Saudi environment. Confirm the provider’s actual support arrangements and model routing; a Saudi region label does not describe every service component.
Give Indian engineers synthetic test cases and diagnostic packages anonymised in Saudi Arabia before release. Use a Saudi team for incidents requiring live customer records. The UAE performance monitor should receive only approved anonymous service metrics until its personal-data access is cleared. Do not export identifiers merely because they appear in a telemetry field.
If an offshore route is established, restrict access to named personnel, approved countries and necessary fields. Use controlled sessions, individual authentication, time-limited privileges and locally retained access records. Disable downloads, clipboard transfers and uncontrolled support attachments. These are recommended implementation controls; they do not convert foreign viewing into a domestic operation or create a missing legal permission. (PDPL, art. 19; Implementing Regulation, art. 23; Saudi SCCs, cl. 11.)
Where the offshore route fails, retain identifiable support and monitoring with a suitable Saudi team or provider. Check whether the remaining overseas supplier arrangement still needs sector approval. A finance-company subcontracting restriction or NCA security-service requirement may require changing the contracting structure as well as the data access.
Replace the local-data promise with enforceable instructions
The agreement’s promise that all data stays local is broader than a statement about database hosting. Before allowing foreign viewing or diagnostics, the parties should agree exactly what remains in Saudi Arabia and what may be accessed or disclosed elsewhere. If the customer retains an absolute local-only requirement, the delivery design must satisfy it.
The customer contract, processing terms and supplier agreements should assign the following responsibilities:
- The Saudi customer approves the purposes, lawful basis, data categories and transfer route. Its regulatory owner obtains the applicable sector permissions. The release record identifies the evidence and conditions attached to each approval.
- The Indian supplier implements the agreed access restrictions and keeps the recipient and location schedules current. Prohibit general model training, cross-customer evaluation and independent reuse unless separately assessed and expressly authorised.
- The supplier obtains the controller’s prior approval before appointing subprocessors, with advance notice and an agreed objection period. Changes to countries, model endpoints, logging or support entities require review before activation. Equivalent obligations must reach the UAE provider and further recipients. (Implementing Regulation, art. 17(5).)
- Each recipient supplies incident information through the agreed escalation chain. The controller leads Saudi notifications and customer communications, while preserving each provider’s own statutory duties.
- The supplier assists with access, correction and deletion requests. Its inventory must locate information across conversations, prompts, embeddings, tickets, logs and backups, with evidence of completed action.
- The agreements preserve customer and regulator audit access, evidence production, suspension, return and deletion. Required retention must have an identified basis, limited purpose and expiry; a general security-log exception should not permit indefinite retention. (PDPL, arts. 8, 18–21; Implementing Regulation, arts. 8, 17; Saudi SCCs, cls. 9, 12–13.)
Incident clocks need particular care. The Implementing Regulation gives the controller up to 72 hours from awareness for a qualifying report. Where Saudi SCC Template 2 applies, its breach provision adds a 24-hour importer notice and a 48-hour exporter notification to SDAIA on the stated triggers. Template 3 requires importer-to-exporter and exporter-to-controller notifications within its respective 24-hour periods. The controller’s applicable reporting clock must still be met. Use immediate operational escalation so successive contractual periods do not exhaust an earlier deadline. (Implementing Regulation, arts. 17(1)(d), 24; Saudi SCCs, cl. 13, Templates 2–3, paragraph 6.)
Rights requests also need routing rules. Template 2 requires the importer to notify the exporter within 48 hours; Template 3 requires each notification step within 24 hours. Processors should not respond independently unless authorised. The controller ordinarily has 30 days, with the regulation’s conditional extension. (Implementing Regulation, art. 3; Saudi SCCs, cl. 13, Template 2, paragraph 10 and Template 3, paragraph 11.)
Check the Indian and UAE delivery obligations
As at 5 November 2026, India’s principal processing duties under the Digital Personal Data Protection Act (DPDP Act) and its foreign-contract processing exemption are not yet operative. The 18-month commencement stage reaches those provisions in May 2027. The existing Information Technology Act and applicable Sensitive Personal Data or Information (SPDI) Rules remain relevant. The official clarification for qualifying business-to-business processing excludes Rules 5 and 6, not the transfer and security requirements in Rules 7 and 8. (DPDP Act 2023, ss. 3–17, 44(2); G.S.R. 843(E), para. (c); SPDI Rules 2011, rr. 7–8; DIT clarification, 24 August 2011.)
The directions of India’s Computer Emergency Response Team (CERT-In) require covered entities to retain their information and communication technology logs securely for a rolling 180 days in India. Specified incidents must be reported within six hours of notice or awareness. Its FAQ permits storage abroad also, subject to timely production. Identify the supplier systems and log fields concerned, then reconcile required retention and disclosure with the Saudi arrangement. Those rules do not justify exporting every customer conversation. (CERT-In Directions of 28 April 2022, paragraphs (ii), (iv); official FAQ, questions 35–36.)
UAE federal law can cover a UAE processor handling individuals’ data from abroad. Banking and credit-data exclusions depend on the statutory conditions; they do not remove every technical log from protection. A Dubai International Financial Centre or Abu Dhabi Global Market establishment requires its own regime assessment. Confirm the monitor’s exact establishment, applicable implementing measures and any outward-transfer route before approving it. Saudi transfer terms do not automatically satisfy the UAE provider’s obligations. (UAE Federal Decree-Law No. 45 of 2021, arts. 2, 22–23, 28–29.)
Evidence required before activation
The customer’s licence, multinational-group status, sensitive-data content and monitoring function can change the recommendation. A different host, model endpoint or UAE establishment can also change the applicable obligations. Record those facts before choosing the delivery model.
Use this checklist before activation:
- Saudi customer: confirm its licence, outsourcing classification, processing basis, transfer route and required regulatory approvals.
- Indian supplier: supply the access map, staff locations, model-routing evidence, log schemas and retention settings. Demonstrate that unauthorised exports and independent training are disabled.
- UAE provider: identify its entity and regime, monitoring function, onward recipients, access locations and incident procedure.
- Contract owners: complete the processing terms, applicable Saudi transfer documents and location commitments. Record subprocessor permissions and change controls.
- Delivery and security owners: test configured access, anonymisation, incident escalation, rights handling and deletion against the approved design. Keep the results with the release decision.
Saudi Arabia’s data localisation requirements must be checked against the rules actually in force. The October 2026 consultation proposes a domestic-storage provision while retaining regulated overseas transfers. As at 5 November 2026, it remains a proposal. (SDAIA draft Implementing Regulation amendments, proposed arts. 23(2), 38; Istitlaa consultation announcement, 8 October 2026.)
The Saudi Arabia AI regulation hub covers the wider country context. The analysis of AI credit scoring contracts for UAE banks addresses a different financial-sector arrangement. For broader implementation work, see Saudi PDPL implementation for overseas AI and fintech suppliers.
Plan the offshore support model
Contact Licentium to assess the proposed offshore delivery model. Provide the customer’s sector, supplier countries, data-flow map and available contract documents so the review can identify the required changes and supporting evidence.
Related reading
AI credit scoring contracts for UAE banks and South African suppliers
A South African vendor supplies a model and scoring service to a bank regulated by the Central Bank of the UAE, or CBUAE. Support staff and some processing remain in South Africa. The bank decides whether to lend.
AI Risk Acceptance and Legal Responsibility in Saudi Arabia: Legal Effects of SDAIA’s 2026 AI Risk Management Framework
The Saudi Data and Artificial Intelligence Authority (SDAIA) has published a national method for assessing and managing AI risks. The question is whether adoption changes existing duties, permits residual risk, or reallocates responsibility between organisations and suppliers.
Outsourced AI AML alert triage from Kenya for UK fintechs
A Kenyan RegTech vendor operates AI that prioritises a UK fintech's money-laundering alerts and prepares investigation summaries. The fintech retains its nominated officer and compliance function. The commercial decision concerns how much investigation work the supplier can perform, which decisions remain with the firm, and whether the proposed service and data flows are lawful.
Planning a launch somewhere new?
Prefer email? Write to hello@licentium.io. By sending, you accept our privacy policy.
Where to go from here
Try Licentium AI
Licentium's AI workspace for regulatory questions. Web3 and AI teams shipping fast.
Browse the Fintech Licensing Hub
Jurisdiction-by-jurisdiction guides on licensing pathways, timelines, and costs.
Talk to us
Describe your product and plans, and we will reply with the next steps for scoping the work.