Designing a Saudi PDPL app: Arabic notices, data rights and breach alerts

I read the Personal Data Protection Law (Royal Decree M/19 of 1443H, amended by M/148 of 1444H) and its Implementing Regulation in SDAIA's English texts, then mapped each duty to a screen. That map is the first thing I draw, because it shows how many screens privacy really costs.

The law reaches across borders: SDAIA's data protection page says it covers processing of data about people in the Kingdom by entities outside it. Enforcement is real too. In January 2026 the Saudi Press Agency reported 48 decisions confirming violations in 2025, including marketing sent without consent.

The new part: on 6 October 2026 the Saudi Press Agency announced that SDAIA invited comments on draft amendments to the regulation through the Istitlaa platform, to clarify its procedures and its provisions on storing personal data. That is confirmed. I couldn't open the draft itself, so this guide follows the published regulation. My reading: storage wording is the part most likely to move.

Article 4 of the regulation lists what people must hear when you collect from them: who you are and how to reach you, your data protection officer if you need one, the legal basis and purpose, how long you keep data, their rights, how to withdraw consent, and whether each item is mandatory. No phone screen holds that, so I use two layers:

1. At the form, one line saying what the data is for, with "optional" written into optional labels and a link to the full notice.
2. The full notice, reachable from that line, the privacy centre and the store listing, with headings that match the centre's rows.

SDAIA's Privacy Policy Guideline (August 2024) is practical: icons for clauses, logical headings, a dated update record, language suited to the audience, and saying whether data sits on your servers or a cloud provider's, inside or outside the Kingdom. It isn't binding; I follow it because it shows what SDAIA expects to see.

Article 4(6) also asks you to tell people before using data for a new purpose. I design that "what changed" sheet in the first sprint, because nobody designs it later.

I draw this screen first, in Arabic, because every other privacy moment links back to it.

The request card is the part teams leave out. Without a status and a due date, someone waiting for a copy of their data contacts support, and one request becomes three. Watch the switches as well: they mirror in Arabic, so "on" sits to the left. Hard-code the knob and your Arabic build shows every consent backwards.

Article 4 of the law gives people access, a copy in a readable format, correction and destruction. Article 3 of the regulation adds the clock. My flow for every request:

1. Accept requests where people already are. Article 10 lets people choose from the channels you offer (email, text, app, national address). Offer the privacy centre and an email address, and have support log phone and chat requests, since Article 3 wants every request recorded, oral ones included.
2. Check identity in proportion. A signed-in user is already verified. For destruction or a signed-out request, a fresh sign-in usually does; my Nafath sign-in and PDPL consent guide covers that screen. Skip the ID photo: Article 31 says not to copy official documents unless a law requires it.
3. Confirm and show the due date, 30 days ahead, by the person's chosen channel too.
4. Announce any extension before day 30, with the reason. The regulation allows up to 30 more days for disproportionate effort or repeated requests.
5. Deliver a file people can open. Article 6 says a commonly used electronic format, without data identifying anyone else. I send a readable PDF plus a machine-readable file.
6. Refuse with a reason, never with silence, and link the complaint route (Article 3(2)).

Correction and destruction have extra states. Under Article 7, someone disputing their data can have processing restricted while you check, and any documents you request are destroyed after verification. Under Article 8, destruction reaches the parties you shared data with and your backups, while Article 18 of the law lets you keep what another law requires. So the confirmation says what you destroyed and what you kept, and why.

Giving consent is covered in my Nafath guide. Taking it back matters as much. Article 12 asks you to set up withdrawal before you ask for consent, make it at least as easy as giving it, stop processing without undue delay and ask recipients to destroy the data. On screen, that is the same dated switch the person turned on at sign-up. One line explaining a real consequence is fine; an "Are you sure?" screen is not.

Marketing has its own rules. Article 28 needs consent before advertising where you have no prior interaction with the person, lets them pick the options they agree to, and requires a named sender, a stop as simple as the opt-in, an immediate and free halt, and kept evidence. Article 29 applies the same stop rule to direct marketing. How I build that:

• One switch per channel (text, email, push), off by default.
• The sender's name at the start of every text and email, in both languages.
• A stop instruction in every text, and an unsubscribe link that works without signing in.
• The push permission asked later, in context, because the phone's alert is not marketing consent.

Instalment checkouts add an explicit credit consent; my notes on Saudi checkout screens with mada and Tamara show where it sits.

Article 13(4) of the law says people must learn at collection who receives their data and whether it is processed outside the Kingdom. SDAIA's Transfer Regulation (August 2024) sets the safeguards; your lawyer owns those. The screen owns the sentence.

Most apps send data abroad without meaning to: crash reports, analytics, email, support chat. So I list every SDK and service with what it receives and where, then write the line from that list: "We store your data in the Kingdom; our email provider processes some of it outside." Because the draft amendments touch storage, I keep that sentence in the content system, so a change becomes a copy update and a notice version, not an app release.

The texts I read set no age. They speak of people lacking full or partial legal capacity: a legal guardian exercises their rights (Article 3), may consent only after you verify the guardianship, and must not harm their interests; the person takes over on reaching capacity (Article 13). So a family or education app needs a guardian account, a guardianship check, a notice the child can read (Article 4(7)) and a hand-over flow that resets consents. Ask your lawyer which age applies.

Article 24 of the regulation sets two clocks: SDAIA within 72 hours if the incident could cause harm, and affected people without undue delay, in simple, clear language. Writing that during an incident, in two languages, produces a vague paragraph. I write the template before launch:

The same words go to three places: a banner in the app that stays until read, an email, and a text that points to the app instead of carrying a link, because a link in a breach text looks exactly like the scam it warns about.

One privacy centre can satisfy both stores. Apple's App Review Guidelines (updated 8 June 2026) want the privacy policy linked inside the app, explaining how to revoke consent and request deletion, an easy way to withdraw consent, and in-app account deletion. Apple's account deletion guidance adds that deactivation alone isn't enough. Google Play's deletion requirements want an in-app path plus a web link, and its User Data policy wants a prominent disclosure immediately before a consent request or runtime permission.

Apple's privacy guidelines say a screen before a system alert gets one button and no "Allow". Apple's privacy details and Google's Data safety form must match the app, SDKs included, so I fill them from the same data map. The prompt order is in UAE PDPL consent screens, screen by screen; it works the same in Riyadh.

The official texts are Arabic, so I build the notice on terms from the Arabic Implementing Regulation and keep plainer words for buttons.

Arabic and English share one version number, and the consent record stores which language the person saw. The Saudi locale defaults to Arabic-Indic digits, so I pick one digit style for privacy screens and keep it. Emails and phone numbers stay left to right inside Arabic. Your native Arabic reader approves the text before your lawyer reads it.

This is how I plan PDPL consent into Riyadh app builds: the glossary lives in the design system beside the type tokens, so developers never translate a privacy term alone.

Start with the data map, then the privacy centre, then the breach template. Once each data type has a purpose, a basis, a recipient and an off switch, the notice and the store forms nearly write themselves, and the amendments become a copy change.

I fit this into the first two weeks of my mobile app design process, beside sign-in and payments: a free 30 minute intro call, a written scope and one fixed quote, then weekly Figma sprints with a Slack update every 48 hours. I work three hours ahead of Riyadh, on the same Sunday to Thursday week; read more about me. Planning an app for Saudi users? Start with my Arabic-first app work for Riyadh founders.

Does the Saudi PDPL apply to an app run from outside the Kingdom?

Yes, if it processes data about people in Saudi Arabia. SDAIA's data protection page says the law covers processing of data about individuals in the Kingdom by any entity outside it. So an app built and hosted abroad still needs the notice, rights flows, marketing rules and breach messages. Registration duties are a question for your lawyer.

How long does a Saudi app have to answer a data request?

Article 3 of the Implementing Regulation gives 30 days, without delay. You may extend by up to 30 more days for disproportionate effort or repeated requests, but only after telling the person in advance and giving the reason. Show the due date on the request screen and send any extension notice before day 30.

Is account deletion the same as a PDPL destruction request?

Not quite. Apple and Google require in-app account deletion, and Google also wants a web link. The PDPL's destruction right reaches partners and backups, while Article 18 of the law lets you keep data another law requires. I design both: delete account, and a destruction request whose confirmation says what stays and why.

Do Saudi apps need consent for marketing texts and push notifications?

Where you have no prior interaction with the person, Article 28 of the regulation requires consent before advertising, and Article 29 covers direct marketing. Every message names the sender, and stopping must be free, immediate and as easy as agreeing. The phone's notification permission is separate, so ask for both, in context.

Does a Saudi app have to tell users about a data breach?

Yes, when it may damage their data or conflict with their rights. Article 24 requires notice to SDAIA within 72 hours if harm is possible, and to affected people without undue delay, in simple language: what happened, the risks, what you did, who to contact and how to protect themselves. Write the template before launch.

What changed in the PDPL rules in October 2026?

On 6 October 2026, the Saudi Press Agency reported that SDAIA invited public comments on draft amendments to the Implementing Regulation through the Istitlaa platform, to clarify procedures and the rules on storing personal data. It is a draft, not law. Design to the current regulation and keep storage and transfer wording editable.

I read every source on 13 October 2026, the SDAIA PDFs in full, checking terms against the Arabic regulation. Data is thin in two places: the Istitlaa draft and SDAIA's governance platform refused connections from my location, so the draft rests on SPA's announcement; and the exact grace period end date (widely given as 14 September 2024) sits in an SDAIA guide I couldn't open, so I say September 2024.

• SDAIA, Personal Data Protection Law, English text, read 13 October 2026: sdaia.gov.sa
• SDAIA, Implementing Regulation, English text, read 13 October 2026: sdaia.gov.sa
• SDAIA, Implementing Regulation, Arabic text, read 13 October 2026: sdaia.gov.sa
• SDAIA, Privacy Policy Guideline, August 2024, read 13 October 2026: sdaia.gov.sa
• SDAIA, Transfer Regulation, version 2.0, August 2024, read 13 October 2026: sdaia.gov.sa
• SDAIA, Data Protection page, read 13 October 2026: sdaia.gov.sa
• Saudi Press Agency, consultation on draft amendments (Arabic), 6 October 2026, read 13 October 2026: spa.gov.sa
• Saudi Press Agency, 48 PDPL violation decisions in 2025, 16 January 2026, read 13 October 2026: spa.gov.sa
• Saudi Press Agency, committees enforcing after the grace period, 27 April 2025, read 13 October 2026: spa.gov.sa
• Apple, App Review Guidelines, updated 8 June 2026, read 13 October 2026: developer.apple.com
• Apple, Offering account deletion in your app, read 13 October 2026: developer.apple.com
• Apple, Human Interface Guidelines, Privacy, read 13 October 2026: developer.apple.com
• Apple, App privacy details, read 13 October 2026: developer.apple.com
• Google Play, account deletion requirements, read 13 October 2026: support.google.com
• Google Play, User Data policy, read 13 October 2026: support.google.com
• Google Play, Data safety section, read 13 October 2026: support.google.com