# Saudi PDPL and data residency for messaging: what enterprises sending to KSA must know

> Saudi PDPL, enforced by SDAIA, treats a mobile number as personal data. What enterprises sending A2P SMS and OTP into KSA must know about consent and residency.

- Canonical URL: https://www.broadnet.me/blog/saudi-pdpl-data-residency-messaging
- Language: en
- Last updated: 2026-10-10
- Publisher: BroadNet (https://www.broadnet.me)

- Published: 2026-08-03
- Author: BroadNet Regulatory Affairs

Saudi Arabia's Personal Data Protection Law (PDPL), supervised by SDAIA, applies to A2P SMS and OTP traffic because a mobile number is personal data. Senders act as data controllers or processors, need a lawful basis such as consent, and must follow the cross-border transfer rules that govern where message content, delivery metadata, and logs may be stored and processed.

> This post covers the data-protection layer. For the sender-ID registration and routing regime run by the telecom regulator, read our companion guide on [Saudi CST (formerly CITC) sender-ID rules](https://www.broadnet.me/blog/saudi-citc-cst-sender-id-rules) and the country page for [Saudi Arabia](https://www.broadnet.me/regulations/saudi-arabia). The two regimes overlap and you must satisfy both.

## What the PDPL is, and who enforces it

The PDPL was issued by Royal Decree M/19 of 2021 and amended by Royal Decree M/148 of 2023. It came into force on 14 September 2023, with active enforcement following a one-year grace period from 14 September 2024. It is supervised by the Saudi Data and Artificial Intelligence Authority (SDAIA), together with its Implementing Regulations and a separate Regulation on Personal Data Transfer outside the Kingdom. The law reaches any processing of the personal data of individuals residing in Saudi Arabia — including processing carried out by entities based outside the Kingdom — so an international business messaging Saudi customers is squarely in scope even if its servers sit elsewhere. See the country overview under [regulations for Saudi Arabia](https://www.broadnet.me/regulations/saudi-arabia).

## Phone numbers are personal data

Under the PDPL, personal data is any data that identifies a natural person directly or indirectly. A mobile number — the MSISDN you send to — identifies and relates to an individual, so it is personal data in its own right. That pulls a lot of what a messaging sender handles into scope: recipient lists, OTP request and verification records, delivery receipts (DLRs) tied to a number, message bodies that contain names or account details, and the timestamps, IP addresses, and network metadata generated along the path. Treating the number as 'just a technical identifier' is the most common and most expensive misreading of the law.

## Lawful basis, consent, and data minimization

Every send needs a lawful basis. Consent is the primary basis in the PDPL, and the 2023 amendment recognised additional bases, including legitimate interest for non-sensitive data, performance of a contract, and compliance with a legal obligation. In practice, marketing traffic should rest on explicit, demonstrable opt-in with a working opt-out — which is also what the telecom regulator expects — while OTP and transactional messages typically rely on contractual necessity or legitimate interest because the user asked to log in or complete a transaction. Two further principles bind you throughout: purpose limitation (use the number only for what the person agreed to) and data minimization (collect and retain only the fields you actually need). The classification you declare for [CST sender-ID registration](https://www.broadnet.me/blog/saudi-citc-cst-sender-id-rules) should match the lawful basis you rely on under the PDPL.

## Controller and processor duties, mapped to a messaging sender

If you decide why and how the numbers are processed you are a controller; your CPaaS provider or aggregator, acting on your instructions, is typically a processor. Both carry duties, and the relationship must be governed by a written data-processing agreement. The table maps the core PDPL obligations to what each one means for an enterprise sending A2P SMS or OTP into the Kingdom.

| PDPL obligation | What it means for a messaging sender |
|---|---|
| Lawful basis and consent | Hold a valid basis per traffic type; explicit opt-in and honoured opt-out for marketing. |
| Purpose limitation and minimization | Send only to numbers collected for that purpose; store only the fields you need. |
| Records of processing | Maintain a register of what personal data you send, why, where it flows, and how long you keep it. |
| Data subject rights | Honour access, correction, deletion, and withdrawal of consent for numbers you hold. |
| Processor governance | Bind your provider or aggregator with a data-processing agreement covering security and sub-processors. |
| Cross-border transfer | Only move data outside KSA under the PDPL transfer conditions; assess the destination first. |
| Breach notification | Notify SDAIA within 72 hours of becoming aware; tell affected individuals when harm is likely. |

## Data residency and cross-border transfer — what actually applies

This is where 'Saudi data residency' is most misunderstood. The amended PDPL does not impose a blanket data-localization mandate for all personal data. Instead, its Article 29 and the Regulation on Personal Data Transfer permit transfers outside the Kingdom under conditions: the transfer must serve a permitted purpose, must not prejudice national security or the Kingdom's vital interests, must go to a destination that SDAIA assesses as offering an adequate level of protection or be covered by appropriate safeguards (such as standard contractual clauses, binding rules, or certification), may require a transfer risk assessment, and must be limited to the minimum data necessary.

So where must messaging metadata and logs live? For much A2P traffic, personal data can lawfully be processed abroad if those transfer conditions are met. But strict in-Kingdom residency is driven by three things that sit alongside the PDPL: sector regulators — most notably the central bank's rules for banking and fintech, which push regulated financial data to stay inside Saudi Arabia; national data-classification and cloud frameworks that raise residency expectations as data sensitivity rises; and enterprise contracts that simply require it. The practical consequence for a sender is to classify what you generate — OTP records, DLR logs, routing metadata, message archives — and let that classification, plus your customer's sector, decide whether it can leave the Kingdom or must be hosted in-region. Design the data path deliberately; see how we approach data flows and isolation in our [security architecture](https://www.broadnet.me/security/architecture).

## Breach notification and accountability

The PDPL requires a controller to notify SDAIA of a personal-data breach, and to inform affected individuals where the breach is likely to cause them harm, within timelines set by the Implementing Regulations — 72 hours from becoming aware is the operative window. Accountability runs through documentation: the records of processing, your lawful-basis mapping, your transfer assessments, and your processor agreements are what demonstrate compliance if the regulator asks. On penalties, the published law sets fines of up to SAR 5 million for violations, which may be doubled for repeat offences, with separate criminal penalties for the unlawful disclosure of sensitive data. Rather than fixate on headline figures, treat a silently non-compliant data flow as the real operational risk.

## A compliance checklist for A2P SMS and OTP into KSA

1. Map your data flows — identify every point where a Saudi MSISDN and its related metadata is collected, transmitted, stored, and logged, end to end.
2. Fix a lawful basis per traffic type — explicit opt-in with opt-out for marketing; contractual necessity or legitimate interest for OTP and transactional.
3. Classify the data and decide residency — determine sector rules (for example, banking) and whether OTP records, DLR logs, and metadata must stay in-Kingdom.
4. Put a data-processing agreement in place with your CPaaS provider or aggregator, covering security, sub-processors, and breach cooperation.
5. Minimize and set retention — keep OTP and verification records only as long as needed, and purge message bodies after the delivery and audit window.
6. Prepare a breach runbook — a 72-hour SDAIA notification process with owners, templates, and a decision rule for informing individuals.
7. Align with the telecom regime — register sender IDs and route through approved channels per the CST rules so the two regimes stay consistent.
8. Consult local counsel to confirm the current Implementing Regulations and any sector-specific obligations before you go live.

> Sending A2P SMS or OTP into Saudi Arabia is where MENA-native routing and compliance pay off. BroadNet has run direct, approved Saudi operator interconnects since 2003, holds ISO 27001, ISO 9001 and ISO 22301 and maintains SOC 2, and can align sender-ID registration, routing, and data handling to your PDPL posture — see [compliance](https://www.broadnet.me/compliance) and our [security architecture](https://www.broadnet.me/security/architecture).

## Frequently asked questions

### Does Saudi PDPL apply to SMS?

Yes. The PDPL governs the processing of personal data, and a mobile number is personal data, so sending A2P SMS or OTP to a Saudi recipient is processing within its scope. It applies even to senders based outside the Kingdom when they process the data of individuals residing in Saudi Arabia. You need a lawful basis, must respect data-subject rights, and must follow the transfer rules for any logs or metadata leaving the country.

### Where must messaging data be stored for Saudi Arabia?

The amended PDPL is not a blanket localization mandate — personal data can be processed outside the Kingdom if the transfer conditions are met, including an adequacy assessment or appropriate safeguards and data minimization. However, in-Kingdom residency is often required by sector rules (notably for banking and fintech), by data-classification and cloud frameworks as sensitivity rises, and by enterprise contracts. Classify your OTP records, DLR logs, and metadata, then let that classification and the customer's sector decide.

### Is customer phone data personal data under PDPL?

Yes. Personal data under the PDPL is any data that identifies a natural person directly or indirectly, and a phone number does exactly that. That means recipient lists, OTP and verification records, delivery receipts tied to a number, and associated timestamps and network metadata are all in scope. Treat them with a lawful basis, minimization, retention limits, and the security and transfer controls the law requires.

## References

- SDAIA — Personal Data Protection Law (PDPL) and Implementing Regulations: [sdaia.gov.sa](https://sdaia.gov.sa/)
- Communications, Space and Technology Commission (CST) — telecom and messaging regulation: [cst.gov.sa](https://www.cst.gov.sa/)
- BroadNet — [Saudi CST sender-ID rules](https://www.broadnet.me/blog/saudi-citc-cst-sender-id-rules) and [Saudi Arabia regulations](https://www.broadnet.me/regulations/saudi-arabia).
- BroadNet — [compliance](https://www.broadnet.me/compliance) and [security architecture](https://www.broadnet.me/security/architecture).