ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A Saudi PDPL privacy policy is the first document a regulator, a customer or a data subject will ask to see, because Article 12 of the Personal Data Protection Law requires it to exist and to be available before you collect any personal data. Many organizations in the Kingdom still run a translated GDPR notice, which misses several Saudi-specific expectations on wording, timing and consent.
This guide sets out what Article 12 requires, what the Implementing Regulations add on timing and consent, and how to structure a policy that a reviewer can check line by line. For the wider law, start with our Saudi PDPL overview.
Free gap assessment
Could you demonstrate GDPR compliance today?
Score yourself against what a supervisory authority actually asks for, free — the records, not the policy.
Run the free GDPR gap assessment → or View premium report sample
Article 12 obliges a controller to adopt a privacy policy and to make it available to data subjects so they can review it before their data is collected. The policy must describe eight things: the purpose of collection, the content of the personal data to be collected, the method of collection, the means of storage, how the data will be processed, how it will be destroyed, the rights of the data subject, and how those rights can be exercised.
| Element in Article 12 | What a reviewer expects to read |
|---|---|
| Purpose of collection | Each purpose stated specifically, not “business purposes” |
| Content of data collected | Categories of personal data, including any sensitive or credit data |
| Method of collection | Forms, apps, cookies, call recordings, third-party sources |
| Means of storage | Where and how the data is held, and for how long |
| How data is processed | The operations performed, sharing and transfers |
| How data is destroyed | Deletion or anonymisation method and trigger |
| Data subject rights | Each right, described in plain language |
| How to exercise rights | A named channel, and a response timeline |
Treat the list as the minimum skeleton of your Saudi PDPL privacy policy. Each row should map to a heading, so an auditor can tick it off in seconds.
The Implementing Regulations make the timing practical. Where you collect data directly from the person, the information must be provided at the point of collection. Where you obtain data indirectly, for example from a partner or a public source, the regulations describe informing the individual without undue delay, and within 30 days of obtaining the data, together with the source. Exceptions exist where the person already has the information or where providing it would conflict with Saudi law, so record any exception you rely on.
In practice, this means a link on the sign-up form is not enough if a call centre, a branch counter or a paper form also collects data. Every channel needs its own way to present the policy.
Write the policy so an ordinary customer can read it. Offer an Arabic version alongside any English one, keep the two consistent, and state a version date. SDAIA publishes guidance on developing privacy policies, but its page was not reachable when we checked, so compare your draft with the current guidance on the SDAIA site before you finalise it.
The policy is not the consent. Article 5 of the law prohibits processing without the data subject’s consent unless another basis in the law applies, and it requires a separate consent for each purpose. The Implementing Regulations allow consent in any appropriate form, including written, verbal or electronic, but the controller must document it so it can be verified later. Explicit consent is expected for sensitive data, credit data and decisions based solely on automated processing, and individuals may withdraw consent at any time, after which you must stop processing without undue delay.
The design consequence is simple. Do not bundle consent into a single “I agree” box that covers marketing, analytics and profiling together. Link each consent to the specific purpose listed in the policy, and log the date, version and channel. Our PDPL compliance checklist shows where consent records sit among the other core controls.
A policy that does not match reality is worse than a short one. Reviewers compare it against your record of processing activities, your retention schedule and your transfer decisions. If the policy says data is destroyed after two years and the system keeps it for seven, that is a finding.
The same problems recur. Purposes are vague. Sensitive data is collected but never mentioned. The policy describes a website only, ignoring apps, calls and paper forms. Rights are listed without any way to use them. The document has no version date or owner, and nobody updates it when a new system or supplier arrives. Fixing these takes an afternoon and removes most of what a reviewer would flag.
A clear layout makes the document easier to write, review and maintain. One workable order follows the Article 12 list and adds a small amount of context at each end.
Keep each section short. A reviewer, or a customer, should be able to find the answer to one question without reading the whole page.
Consider a hypothetical retail bank in Riyadh. A weak purpose statement reads: “We use your data to provide and improve our services.” A stronger one reads: “We use your identity and contact details to open and maintain your account, to meet anti-money-laundering obligations, and, only if you agree separately, to send you offers about other products.” The second version names the purpose, links to a legal basis, and separates the optional marketing purpose so it can carry its own consent. That is the pattern to repeat for every purpose in the policy.
Ownership matters because the document sits between legal, technology and the business. The privacy lead or data protection officer drafts and maintains it, the business owners of each process confirm that the purposes and data categories are accurate, IT confirms storage and destruction, and a senior manager approves the final text. Record those approvals. If a regulator asks how the statement was produced, an approval trail shows it reflects real processing and not a copied template.
Training closes the loop. Front-line staff who collect data by phone or at a counter should know what the statement says and where to direct a request from an individual, since the most common failure is a policy that promises a channel nobody watches.
Assign an owner, usually the data protection officer or privacy lead, and review the document at least annually and whenever you launch a new product, add a supplier that handles personal data, or change retention. Keep previous versions, because you may need to show what an individual was told on the day they gave consent. Where a change materially affects individuals, notify them rather than simply replacing the page.
If you want the surrounding documents in one place, the Saudi PDPL Toolkit includes privacy notice and policy templates aligned to the law, alongside consent, rights-handling and records templates. Whatever you use, adapt the wording to your real processing rather than filling in blanks. The English-language commentary from firms such as Akin Gump on the PDPL and its Implementing Regulations is a useful second reading, but the official Arabic text prevails.
Yes. Article 12 requires controllers to adopt a privacy policy and make it available to data subjects before collecting their data.
The purpose of collection, the content of the data, the method of collection, storage, processing, destruction, the data subject’s rights and how to exercise them.
No. Consent is a separate requirement under Article 5, given for each purpose, documented, and withdrawable at any time.
The law text we reviewed does not spell out a language rule in the passages checked, but serving Saudi individuals in Arabic is the safe practice, and the two versions should say the same thing.
Review it at least annually, and whenever processing, suppliers, transfers or retention change.
September 30, 2026
