A privacy policy alone does not let a visitor do anything. Under Saudi Arabia's Personal Data Protection Law (PDPL), the website-facing work is two artefacts: a data-subject request page where a person can exercise their rights, and consent records that prove what each person agreed to, when and for what. This guide is implementation education, not legal advice and not a compliance guarantee — judgement calls belong to your counsel or data protection officer (DPO), checked against the official PDPL text and its regulations as published by the Saudi Data and AI Authority (SDAIA).
The short answer: two artefacts, what each must do, and the records behind them (table)
| Artefact | What the visitor gets | What you must be able to produce |
|---|---|---|
| Data-subject request page | A public page, no account needed, to request access, a copy, correction or destruction | The request log: who asked, what, when, identity check used, response and date |
| Consent records | A clear choice at each collection point, and withdrawal as easy as joining | One record per consent: who, when, purpose, wording shown, method, and any withdrawal |
Everything below is the build detail behind those two rows. Two neighbouring duties are covered elsewhere, not here: what a Saudi store must display and company-website legal display — commercial registration, Maroof and Saudi Business Center details.
The rights your visitors hold — stated from the PDPL text, not from vendor summaries
Vendor explainers paraphrase the PDPL, and their summaries diverge — some even extend the law to residents of other countries. Work from the official text and SDAIA's own presentation instead. As SDAIA presents them, data subjects have the right to be informed of the justification and purpose for collecting their data; to obtain a copy of it; to request correction, completion or updating; and to request destruction, subject to the law's requirements. SDAIA's own privacy page routes each right to its DPO contact, provides the copy free of charge within thirty days, and gives the same period for a correction outcome.
Where processing rests on consent, the person can also withdraw it — so the request page and the consent system must connect: a withdrawal is a request, needing the same acknowledgement, clock and log as any other.
Artefact 1 — The request page: request types it must accept (access, copy, correction, destruction)
Give the page a stable URL, link it from the footer and the privacy notice, and publish it in Arabic and English. It must accept, as separate, clearly labelled request types: access to the personal data you hold; a copy in a readable, clear format; correction, completion or updating; and destruction. Add a route for consent withdrawal and marketing opt-out, so nobody misuses a correction form to stop emails.
Do not bury the page behind a login. Many requesters are not customers: a job applicant, a newsletter subscriber or a checkout guest holds rights too. A data request form usable without creating an account — the one design point the closest vendor page in the search results gets right — serves all of them.
Design the request flow: no account wall, proportionate identity checks, Arabic and English
Ask only for what handling the request requires: name, a contact channel for the reply, the request type, and enough detail to find the record. Identity verification must be proportionate: confirming control of the email address or phone number already on the record suits most requests, while demanding identity documents to answer a marketing opt-out is disproportionate and collects more personal data. Reserve stronger checks for sensitive disclosures, and say on the page what you will ask for and why.
Build the flow bilingual from the start: Arabic and English labels, a right-to-left layout that works properly, and confirmations in the language the visitor used. Our work on web development in Saudi Arabia treats that bilingual build as standard, not an add-on.
Behind the page: acknowledgement, the response clock, and the request log
Behind the form, every submission should trigger an immediate acknowledgement with a reference number, start the response clock, and land in a queue with a named owner — not a shared inbox nobody monitors. SDAIA's own model works to thirty days for a copy and for a correction outcome; confirm the period for each request type in the official text, publish yours, and set reminders well before it expires.
Log every request: date received, requester, type, identity check used, handler, actions taken, date answered and outcome. Record refusals and their reasons too, and tell the requester their route to complain, as SDAIA's own page does.
Artefact 2 — Consent records: the fields that make consent provable
A banner click nobody recorded proves nothing. For each consent — cookie, marketing, form, checkout — store one record holding: who consented, when, for what purpose, in what words (the exact notice and options shown, with its version), by what method, and the status now, including any withdrawal date. Keep the wording versions: earlier records are only interpretable against the text the person actually saw, and a purpose change needs fresh consent, not a quiet edit.
Apply the same discipline everywhere consent is taken, not just cookies: can you produce, for this person, evidence of a specific agreement? If the answer lives in an analytics setting or a former employee's inbox, you do not have a consent record — you have a hope.
Withdrawal parity: leaving must be as easy as joining, everywhere consent was taken
The Implementing Regulation, Article 12, as published on SDAIA's platform, requires withdrawal procedures to be established before consent is requested, and withdrawal to be as easy as, or easier than, obtaining it; on withdrawal, processing based on that consent stops without undue delay. Design to that literally: if joining took one tap on a banner, leaving cannot take a phone call in office hours. Put withdrawal where consent was given — banner settings, account preferences, an unsubscribe that works without logging in — and write it into the same consent record.
Connect the artefacts: privacy notice, DPO contact and your record of processing
The privacy notice is the map that joins the artefacts: it identifies the controller, states the purposes and legal bases, names who data is shared with and how long it is kept, and points to the request page and the DPO contact — published on the website itself, as SDAIA does, not only inside a PDF. Keep your record of processing activities current for every website touchpoint, because the request page can only answer accurately if you know where a person's data lives. For the regional frame, see our overview of GCC data protection laws; for wider build context, our guide to web development in Saudi Arabia, its costs and local rules.
What to hand your developer or platform: the build checklist
Specify: a bilingual request page at a stable URL, linked from footer and privacy notice; the four request types plus withdrawal and opt-out; proportionate identity checks per type; automatic acknowledgement with a reference number; a request queue with a named owner, the published response period and reminders; a request log with the fields above; a consent store capturing who, when, purpose, wording version, method and status; withdrawal at parity with sign-up; and DPO contact details on the site. Verify it after launch with a test request and a test withdrawal. Good web design in Saudi Arabia makes the rights route as findable as the checkout.
Common mistakes: the banner nobody recorded and the inbox nobody owns
The recurring failures are operational, not legal. A consent banner deployed without its logging switched on. Requests sent to a generic inbox current staff never check. Identity demands copied from a bank's process, frightening off legitimate requesters. A privacy notice promising a response period nobody staffed. Withdrawal hidden three menus deep while sign-up was one tap. Consent wording edited in place, destroying the version history that made older records meaningful. Each is fixed by the artefacts above, not by a longer policy document.
FAQ
Do I need a data-subject request page if I already publish a privacy policy?
Yes. The policy explains how you process data; the request page is how a person exercises the rights the PDPL gives them — access, a copy, correction and destruction. SDAIA's own site models the difference: its policy states the rights and routes each one to a working contact.
Must visitors create an account to submit a request?
No. Many data subjects — applicants, subscribers, guest buyers — have no account with you. A public form with proportionate identity checks serves them; an account wall pushes requests into unstructured email, where they lose their acknowledgement, clock and log.
How quickly must we respond to a request?
Work to the period in the official PDPL text and regulations for each request type, and publish it. As a model, SDAIA's own privacy page provides a copy free of charge within thirty days and reviews a correction, notifying the requester, within the same period. Confirm the exact provisions with your DPO or counsel.
What exactly should a consent record contain?
Who consented, when, for what purpose, the exact wording and options shown (with its version), the method used, and the current status including any withdrawal. Without those fields for a given person and purpose, the consent is not provable, however clear the banner looked.
Is this article legal advice for our company?
No. It is implementation education based on the official PDPL text and SDAIA's published model, checked at drafting. It does not assess your specific processing, sector rules or risk. Have your counsel or DPO confirm the provisions and periods that apply to you.
Get the PDPL artefacts built into your website properly (CTA)
If your PDPL work is still a policy page and a banner, the two artefacts are the practical next step: a bilingual request page with a staffed workflow behind it, and consent records that survive being asked for. Start from our Saudi Arabia hub, tell us which collection points your site runs — forms, checkout, marketing, analytics — and we will scope the build. WebStackRank provides an itemised proposal within 24 business hours.
