Saudi Data Residency in 2026 — SDAIA, PDPL, and What Buyers Should Ask

“Our data is in Saudi Arabia” has become table stakes for SaaS vendors selling into the Kingdom. But saying it and meeting the actual requirements are two very different things. This piece walks through what Saudi data residency means in 2026, what SDAIA and the PDPL actually require, and the five questions every procurement team should ask before signing a SaaS contract.

What Saudi data residency means today

Saudi data residency is the principle that certain classes of data — especially personal data of Saudi residents, government data, and regulated-sector data (banking, health, legal) — must be stored and processed inside the Kingdom's borders, under Saudi jurisdiction, on infrastructure that Saudi regulators can inspect.

The rules have sharpened considerably since the Personal Data Protection Law (PDPL) came into force and SDAIA (the Saudi Data and AI Authority) began issuing implementing regulations. Saudi residency is no longer a marketing bullet point; it's a compliance requirement that auditors and courts will test.

SDAIA and the PDPL, briefly

The PDPL gives Saudi residents enforceable rights over their personal data: access, correction, deletion, objection to processing, and data portability. Controllers have obligations around lawful basis, purpose limitation, proportionality, and retention. Cross-border transfers are restricted.

SDAIA's implementing regulations define what “personal data” covers (broader than you think), when cross-border transfers are permitted (narrower than you think), and what technical and organisational measures controllers and processors must put in place.

Five questions to ask every SaaS vendor

1. Where is customer data physically stored? The right answer names specific Saudi regions or Saudi-based data centres, not “our global network” or “multiple regions.”
2. Where is it processed at runtime? Data at rest in Saudi doesn't help if every API call routes through Frankfurt. Ask about inference, queues, caches, and backups.
3. Who can access it, and under what legal regime? If the vendor is US-incorporated, US authorities can compel disclosure via the CLOUD Act, regardless of where the bytes sit. Saudi-incorporated vendors sit under Saudi jurisdiction.
4. How are cross-border transfers handled? PDPL restricts cross-border transfers unless specific exceptions apply. Your vendor should have explicit transfer mechanisms documented, not “we comply with everything.”
5. What's the incident response plan? Data breaches in Saudi Arabia must be notified within strict windows. Your vendor's runbooks should show Saudi-law-aligned notification, not US-style generic playbooks.

How Sadq meets each requirement

• 100% of customer data — documents, metadata, audit logs — is stored inside the Kingdom.
• All processing, including AI Hub inference, runs on Saudi infrastructure.
• Sadq is a Saudi entity under Saudi jurisdiction; no US CLOUD Act exposure.
• Cross-border transfers are disabled by default. Where customers opt in (e.g. for specific integrations), transfers are contractually restricted and PDPL-aligned.
• SDAIA-aligned incident response with documented Saudi regulator notification paths.

Bottom line for procurement

If you're a Saudi-operating legal, HR, finance, or procurement team, data residency isn't just a compliance box to tick — it's a risk-management decision that shapes which vendors you can safely sign with. Vendors built outside the Kingdom can usually bolt on residency; vendors built inside it can guarantee it.

Read our security documentation for the full technical detail, or request a compliance packet.