Overview
Articles 29-31 of the PDPL Implementing Regulation set the toughest privacy bar in the Kingdom: personal data may not leave KSA except under controlled conditions. SDAIA publishes a list of countries with adequate protection; transfers to those need no extra step beyond the standard PDPL safeguards. For everywhere else you need an authorised mechanism, a documented impact assessment, and in some cases SDAIA pre-approval.
Who this applies to
- Every controller processing personal data of subjects in KSA who transfers (or makes available) such data outside the Kingdom.
- "Transfer" includes: storing in foreign cloud regions, granting remote access from outside KSA, sending in an email attachment to a foreign recipient.
SDAIA adequacy decisions
As of the latest SDAIA update, adequacy decisions cover countries that demonstrate substantially equivalent privacy protection. The list is reviewed periodically. Other jurisdictions require additional safeguards.
Lawful transfer mechanisms
| Mechanism | When to use | SDAIA approval | |---|---|---| | Adequacy decision | Recipient country listed as adequate | Not required | | Standard Contractual Clauses (SCCs) issued by SDAIA | Recipient outside adequacy list | Notification | | Binding Corporate Rules (BCRs) | Intra-group transfers in multinationals | Approval required | | Derogations (Article 31) | Specific limited cases (consent, contract performance, vital interest, public interest) | Justification logged | | Explicit SDAIA approval | High-risk, large-scale, or sensitive data | Required, case-by-case |
Step 1: Map every transfer
Build a transfer register parallel to your ROPA:
transfer_id: TRF-2026-014
source: KSA-controller (Skyline LLC)
recipient: cloud-provider (AWS, US-EAST-1)
data: server logs containing user-agent + IP + email (Confidential)
purpose: backup retention
mechanism: SCC + supplementary measures
sdaia_status: notified (notification ref NS-2026-014)
volume: 12 TB/year
review_due: 2027-04-21
Step 2: Transfer Impact Assessment (TIA)
For any transfer outside an adequate jurisdiction conduct a TIA covering:
- Recipient country law (surveillance powers, government access).
- Recipient maturity (certifications, incident history).
- Volume and sensitivity of data.
- Effectiveness of supplementary measures (encryption, pseudonymisation, contractual restrictions).
- Recourse available to data subjects.
Step 3: Supplementary measures
Where adequacy is absent, layer:
- Encryption in transit (TLS 1.2+ minimum, prefer TLS 1.3).
- Encryption at rest with customer-managed keys not accessible by the recipient or its government.
- Pseudonymisation: separate identifiers from payload, keep identifier mapping in KSA only.
- Contractual override clauses requiring the recipient to notify in case of government access requests.
Step 4: Sensitive data
Sensitive personal data (health, genetic, biometric, religion, criminal, financial) is subject to heightened scrutiny for cross-border transfer. SDAIA typically requires:
- Explicit consent of the subject, or
- A vital-interest justification, or
- Specific approval per category.
Step 5: Cloud-region pinning
The simplest compliance strategy: pin everything to a KSA region. Hyperscalers operating in KSA (AWS me-central-1, Microsoft Azure Saudi Arabia, Oracle Jeddah, STC Cloud, Mobily Cloud) enable an architecture where no data leaves the Kingdom.
guard rails:
aws_organisation_scp: deny non-KSA regions
azure_policy_initiative: AllowedLocations = ['saudiarabia', 'saudiarabianorth']
oci_security_zone_recipe: tenancy-level region pin
internal_iac_lint: refuse PR if region != ksa
Step 6: Reporting
Annual reporting to SDAIA may be required for major transfers. Maintain:
- Transfer register.
- TIA outcomes per transfer.
- Logs of any government access requests received by the recipient.
- Subject-rights enforcement evidence.
Common gotchas
- "We use US cloud, but data is encrypted, so it's fine" — encryption alone is not a lawful basis for transfer.
- BCRs approved in another jurisdiction (e.g., GDPR) automatically transferable — SDAIA may not recognise.
- Remote support engineer in India accessing KSA system — that is a transfer; need SCC.
- Backup tapes shipped to a foreign archive site — transfer.
Verification
- Transfer register dated within last 6 months.
- TIAs for every non-adequate transfer.
- SCC text adopted from SDAIA template.
- Region pin SCPs / policies / lint rules.
- Subject-consent records where consent is the basis.
Conclusion
Cross-border transfer is the area where well-meaning organisations stumble hardest. Map every flow, prefer KSA regions, layer measures where you must transfer, and document everything. SDAIA will check the paper trail before the technology.
Comments
0 total · 0 threads