What is the PDPL, and does it apply to your website?
The PDPL is Saudi Arabia's Personal Data Protection Law, and if your website or app collects names, phone numbers, emails, addresses, IDs or tracking data about people in the Kingdom, you should assume it applies and ask your lawyer to confirm the details. The Saudi Data and AI Authority (SDAIA) administers it through the National Data Governance Platform.
The law says it takes effect 720 days after publication (Article 43), and it has an Implementing Regulation and a separate regulation on transferring personal data outside the Kingdom. Enforcement has applied since September 2024. For a website owner, the practical question is not whether the law exists but which parts of your site handle personal data, and whether each part behaves the way the law and your privacy notice say it does.
PDPL compliance for websites is therefore mostly an inventory job followed by a handful of fixes. Contact forms, WhatsApp buttons, booking tools, checkout, newsletter sign-ups, analytics, ad pixels, chat widgets and embedded maps all touch personal data in some way.
- Contact and quote forms: names, phones, emails, messages.
- Checkout and accounts: addresses, order history, sometimes national ID.
- Analytics and ad pixels: device identifiers, behaviour, sometimes form data.
- Chat, booking and CRM tools: conversations and appointment details.
What must a Saudi website change for PDPL compliance?
Most sites need six changes: a privacy notice, working consent, a request workflow, a hosting and transfer decision, a breach log, and less data collected. The rest of this guide takes each one in turn, from the developer's side.
The order matters. Start with an audit, because you cannot write an accurate notice or consent banner until you know what the site actually collects. Many owners are surprised by what turns up: an old plugin still sending form data somewhere, an ad pixel capturing email addresses, or a test database copied to a developer's laptop years ago.
- 1. Audit: list every place personal data enters, is stored or leaves the site.
- 2. Notice: place the privacy notice your lawyer writes where people give data.
- 3. Consent: keep non-essential tracking off until the visitor agrees.
- 4. Requests: let people access, copy, correct and delete their data within 30 days.
- 5. Hosting and transfers: decide where data lives and which transfers abroad you accept.
- 6. Breach log: record incidents so the 72-hour notice is possible.
- 7. Minimise: collect less, keep it for less time, share it with fewer tools.
Each item is a piece of engineering with a clear finish line. None of them needs a full website rebuild unless your platform is so old it cannot be changed safely.
What should a PDPL privacy notice cover, and where does it go on the site?
Article 12 of the PDPL requires a privacy policy made available to people before their data is collected, covering the purpose, what data is collected, how it is collected, stored, processed and destroyed, and the person's rights. Your lawyer writes that text; our job is to put it where it will actually be seen.
The Implementing Regulation adds detail on what people must be told, including the organisation's identity and contact details, the data protection officer's contact where one is appointed, the purpose and legal basis, retention periods, rights and how to exercise them, and how to withdraw consent. SDAIA also publishes a guide on preparing privacy policies in its knowledge centre.
On a website that means a permanent footer link in both languages, a short line with a link next to every form and checkout, the notice shown during app sign-up, and a version date so you can prove which text a person saw. When the notice changes, the site keeps the old versions.
Short notice at the form
One or two sentences under each form saying what the data is for, with a link to the full notice. Visitors read this; they rarely open the full page.
Version history
Each notice version stored with its date, and consent records point to the version shown. That is a small database table that saves a lot of argument later.
Does the PDPL require a cookie consent banner?
The law does not use the word "cookie", and SDAIA's handbook we reviewed does not single cookies out. But tracking that processes personal data is still processing, and the Implementing Regulation requires consent to be freely given, specific, clear and documented where consent is your legal basis. The practical, low-risk build is a banner that keeps non-essential tags off until the visitor agrees.
A real consent banner does three things a cosmetic one does not. It actually blocks analytics and advertising scripts before a choice is made. It records the choice with a timestamp and the notice version. And it lets people withdraw as easily as they agreed, through a link that stays on every page.
For Google tags, Google's consent mode defines four signals, ad_storage, analytics_storage, ad_user_data and ad_personalization, and a basic mode in which tags stay blocked until the visitor interacts with the banner. We wire the banner to those signals and to any non-Google pixels separately.
- Necessary: session, cart, security and language cookies; on without consent.
- Analytics: off until accepted, unless your counsel decides otherwise.
- Advertising and remarketing: off until accepted.
- Embedded videos and maps: loaded on click where they set tracking cookies.
Explicit consent is required for some data, including sensitive data and credit data, per Article 11 of the Implementing Regulation. If your forms collect health, religious or financial details, flag that to your lawyer before we design the screen.
How should a website handle PDPL data subject requests?
Give people a simple way to ask, check who they are, track the request against a 30-day clock, and answer with data they can read. The Implementing Regulation sets 30 days to carry out a request, with a further 30 days in cases that need unusual effort, so an email inbox and good intentions are not enough once volume grows.
Article 4 of the law lists the rights: to be informed, to access personal data, to receive it in a readable and clear format, to have it corrected, completed or updated, and to have data destroyed when it is no longer needed. Each maps to a feature. Access and copy need an export. Correction needs an edit path. Destruction needs deletion that reaches the database, the CRM, the email tool and, on schedule, backups.
Identity checks matter because a request is also an attack surface. A one-time code to the phone or email already on the account is usually proportionate; asking for a national ID copy often is not.
What we build
A bilingual request form, OTP verification, an admin queue with the due date shown, one-click export to a readable file, a deletion job across connected tools, and a log of every step.
What stays manual
Deciding whether an exception applies to a request. That is a legal call, so the queue has a 'needs legal review' status rather than an automatic refusal.
Does PDPL require Saudi hosting? Cross-border transfer and data location
The PDPL does not simply ban hosting abroad; it regulates transfers outside the Kingdom. Article 29 allows transfers in set circumstances where they do not harm national security and where the level of protection is not reduced, and SDAIA has issued a separate regulation on transfers plus standard contractual clauses and a transfer risk-assessment guideline. Your lawyer decides whether your current setup fits.
The technical job is to make the transfers visible. A typical Saudi website sends personal data to several countries without anyone deciding it: the host, the backup location, the email service, the analytics platform, the chat widget, the CRM. We produce a one-page map of each flow, the provider, the region and the data involved.
If you decide to keep data in the Kingdom, local cloud regions exist. Google Cloud's Dammam region, for example, is accessed by KSA-based customers through its local partner CNTXT, according to Google Cloud's documentation. Moving the database is a planned migration with downtime measured in minutes, but third-party tools may still send data abroad, so the map matters more than the host.
- Database and file storage: which provider, which region.
- Backups: often a different region from the main server.
- Email and SMS: where messages and contact lists are processed.
- Analytics, pixels and chat widgets: usually outside the Kingdom.
How do you log a breach so you can notify SDAIA within 72 hours?
Keep a timestamped incident log and alerting that tells a named person quickly. Article 24 of the Implementing Regulation requires the controller to notify the competent authority within 72 hours of becoming aware of a personal data breach, and to tell affected people without undue delay where the breach may harm them. The clock starts at awareness, so detection and logging are part of compliance.
SDAIA's National Data Governance Platform lists a service for notifying personal data breaches. The notice itself is your team's and your lawyer's job. What the website can do is make sure you notice incidents, record what happened, and have the facts ready: what data, how many records, when it started, what you did.
We add alerts for the signals that usually come first: repeated failed logins on admin accounts, unusual bulk exports, new admin users, changes to payment or form scripts, and database access from unfamiliar locations.
- Time the incident was noticed and by whom.
- Systems and categories of personal data involved.
- Estimated number of people affected.
- Containment steps taken, with times.
- Who decided on notification, and when the notice was sent.
The log is internal and access-controlled. We build the tooling; decisions on notifying the authority and individuals stay with you and your counsel.
Form and analytics minimisation: collecting less on your website
Collect only what you use, keep it only as long as you need it, and send it to as few tools as possible. SDAIA publishes guidelines on determining the minimum personal data and on destroying data, and minimisation is also the cheapest compliance measure: data you never collect cannot leak.
On forms, that means asking whether each field earns its place. A quote form rarely needs a date of birth; a newsletter rarely needs a phone number. Optional fields should look optional. Free-text boxes invite people to share things you did not ask for, so a short hint helps.
On analytics, check what each tag actually sends. Some pixels capture form values or URLs containing emails. Per Google's documentation, Google Analytics 4 does not log or store IP addresses, but that does not cover every other script on your pages. We test each tag with a network inspector and remove what does not need to be there.
- Remove unused form fields and old plugins.
- Stop passing form contents or emails into ad pixels.
- Set retention: delete stale enquiries and abandoned accounts on a schedule.
- Mask personal data in logs and error reports.
- Restrict staff access by role, and log exports.
Records of processing and the DPO: what the website contributes
Article 31 of the PDPL requires controllers to keep a record of processing activities, and the Implementing Regulation lists what it holds, including purposes, categories of data, retention periods, recipients, transfers outside the Kingdom and security measures. The website audit gives you most of the raw material for the website part of that record.
SDAIA's handbook notes that not every organisation must appoint a data protection officer; the Implementing Regulation sets the cases, and SDAIA publishes rules on appointing one. Whether you need a DPO is a question for your lawyer. If you have one, their contact details belong in the privacy notice and the request workflow should route to them.
We hand over the technical inventory in a format your DPO or lawyer can drop straight into the record: each system, the data it holds, where it runs, who can access it and how long records are kept.
PDPL compliance for online stores, booking sites and apps
Stores, booking sites and apps hold more personal data than brochure sites, so PDPL compliance for websites of this kind goes deeper: account deletion, order data retention, and marketing consent separate from order messages.
The Implementing Regulation requires a way for people to stop receiving marketing that is as easy as signing up (Article 29). So an unsubscribe link in every email, a STOP option on WhatsApp broadcasts, and an account setting for marketing preferences. Order confirmations and delivery updates are a different purpose and should not be tied to marketing consent.
Apps need an in-app account deletion path and accurate privacy labels on Google Play and the App Store. Marketplaces share buyer data with vendors, which needs tight limits; our multi vendor marketplace development page covers vendor access in detail. Store owners on Zid can see our note on integrations in the Zid store developer guide.
- Marketing opt-in separate from order updates, with easy opt-out.
- Account deletion in the site and the app.
- Retention rules for orders, balanced against tax record-keeping your accountant advises.
- Vendor, courier and support-tool access limited to what each needs.
What happens if a website ignores the PDPL?
The law sets real penalties, which is why it is worth doing properly rather than adding a banner and hoping. Article 36 allows warnings or fines of up to 5 million riyals for violations, which can be doubled for repeat offences, and Article 35 sets up to two years' imprisonment and fines of up to 3 million riyals for disclosing sensitive data with intent to harm.
We mention penalties only for context. The more common cost of ignoring PDPL compliance for websites is practical: a customer asks for their data and nobody knows where it is; a breach goes unnoticed for weeks; an enterprise client's procurement team sends a questionnaire you cannot answer. Each of those is avoided by the same engineering.
None of this is legal advice. Your lawyer will judge your exposure; we build the controls that make their advice real on your site.
How much does PDPL website compliance cost?
With us, technical fixes on an existing site start from US$150, request and breach workflows from US$600, and privacy controls inside a larger custom platform from US$900. Consultancies and agencies quote very differently, and much of the gap is whether legal work, engineering or both are included.
The cost drivers are easy to list. The number of tools holding personal data sets the audit size. A site with an app, a CRM and an email platform needs deletion and export across all of them. An old CMS with abandoned plugins may need a platform update before any fix is safe. And a hosting move adds a migration.
- Number of forms, tools and integrations that hold personal data.
- Website only, or website plus mobile app.
- Automated request handling versus a guided manual process.
- Hosting move inside the Kingdom, or staying put with documented transfers.
- Age and condition of the CMS or codebase.
We quote in USD, itemised, in about two working days. Legal review is separate and paid to your own counsel.
Working with a team in India on PDPL fixes for a Saudi site
The time difference is small: India is two and a half hours ahead of Saudi Arabia, so most of your Sunday-to-Thursday day overlaps with ours, and we answer WhatsApp every day. Calls are on Google Meet or Zoom, and each one ends with a written list of decisions.
Because this work touches personal data, access is set up carefully. We work in staging copies with personal data masked wherever possible, use accounts you create with limited roles, and never keep copies of your database. If you decide on in-Kingdom hosting, the production environment sits in your cloud account in that region.
Quotes and invoices are in US dollars from India, paid by Wise, bank wire or PayPal. There is no Saudi office or on-site visit. We sign your NDA, and your lawyer's written decisions become the acceptance criteria for our work.
Your first two weeks
Days 1–3: kickoff call, limited access granted, audit of forms, tags and tools. Days 4–6: audit report and transfer map sent to you and your lawyer. Days 7–10: consent banner and notice links built on staging, request form drafted, and a list of decisions your counsel needs to make.
What we will not do
Draft legal text, interpret the law for your business, register you with SDAIA, act as your DPO or certify compliance. We will tell you when a question needs your lawyer.
Worked example: a hypothetical fitness studio with a booking site and app
Picture a Riyadh fitness studio group with three branches, a booking website, a Flutter app, a CRM and WhatsApp reminders. This is a made-up scenario showing how PDPL website work would run, not a past project.
The audit finds seven tools holding member data, an ad pixel receiving email addresses from the sign-up form, health questions stored in plain text next to bookings, and backups in a region nobody chose. The lawyer decides the health questions need explicit consent and a shorter retention period, and that analytics can wait for consent.
The build: a bilingual consent banner wired to consent mode, the pixel stripped of form data, health answers moved to a separate, access-restricted table with explicit consent recorded, a request form with OTP and a 30-day queue, account deletion in the app, marketing opt-out on WhatsApp, and an incident log with admin-login alerts. Quoted from US$150 for the site fixes and from US$600 for the request and incident workflows, with app changes scoped alongside.
PDPL compliance checklist for websites and apps
Use this list as a working checklist with your lawyer and developer. Each line is something you can open the site and verify, which is the point: compliance you cannot see on the page usually is not there.
- Inventory of every form, tag, plugin and tool that touches personal data.
- Privacy notice written by counsel, linked in the footer and beside every form, in Arabic and English.
- Consent banner that blocks non-essential tags until accepted, with withdrawal on every page.
- Consent records with timestamp and notice version.
- Data request form, identity check and a queue that shows the 30-day due date.
- Export and deletion that reach every connected tool.
- Transfer map of providers and regions, reviewed by counsel.
- Incident log, admin alerts and a named person for the 72-hour decision.
- Unused fields removed, retention schedules running, logs masked.
- Marketing opt-out as easy as opt-in; app account deletion working.
After launch, re-run the tag check whenever marketing adds a new pixel. Most sites drift out of shape within months because someone pastes a new script into the header.
Keeping a website PDPL-ready after the fixes
PDPL compliance for websites is not a one-off project, because websites change weekly. New campaigns bring new pixels, new forms appear for events, and plugins update. A light monthly check keeps the controls working.
After our work you get two months of free maintenance, during which we re-check tags after changes and keep the request and incident tools running. After that, maintenance starts from US$120/mo a month. If you also want search growth, monthly SEO starts from US$150/mo; privacy and SEO work well together, because a lean, fast site with fewer scripts also scores better on Core Web Vitals.
For AI search, clear public pages about how you handle data, in plain Arabic and English, help assistants answer customers' privacy questions accurately. Our SEO services for Saudi businesses cover that content side.