Most Saudi companies have a privacy policy. Far fewer can actually answer the email that says: “send me everything you hold about me.” Here is the playbook.
The Saudi Personal Data Protection Law (PDPL) is in force, supervised by the Saudi Data and Artificial Intelligence Authority (SDAIA), and its most operational obligation is the one least prepared for: the data subject access request (DSAR). Any individual whose personal data you process — a customer, an employee, a hotel guest, a job applicant — can ask what you hold about them and exercise rights over it. Under the Implementing Regulations, a controller responds within 30 days of receiving the request. That period can be extended once by a further 30 days where the request requires unusual additional effort or where the same person has made multiple requests — provided the data subject is told about the extension and its reasons before the first period ends. Plan the operation around the first 30 days and treat the extension as an exception to be justified, not a buffer.
The gap we find in Saudi organisations is consistent: the policy page exists, the playbook does not. Nobody owns the request; nobody knows which systems to search; the deadline burns while legal and IT discover the problem is real. This article is the playbook — written for operations and IT leaders, tested against how Saudi mid-market environments actually store data.
Scope note: practical guidance, not legal advice. PDPL obligations depend on your processing activities and the current Implementing Regulations; confirm specifics against the official texts (sdaia.gov.sa) and your counsel.
What rights you must be able to serve
PDPL grants data subjects rights you need operational answers for: to be informed about processing; to access their personal data; to request correction of inaccurate data; to request destruction of data no longer needed, subject to legal retention duties; and to withdraw consent where consent is the processing basis. Each right is a workflow, and access is the one that exercises every muscle — if you can serve a DSAR well, the others follow.
The response-window playbook
| Days | Step | What happens | Owner |
|---|---|---|---|
| 0–2 | Intake & log | Request enters through any channel (email, form, WhatsApp, branch). Log it same-day in the DSAR register: date received, channel, requester, scope. The clock starts at receipt, not at recognition. | DSAR owner |
| 2–5 | Verify identity | Confirm the requester is the data subject (or authorised agent) using the minimum data needed — match against what you already hold. Never demand new ID documents you don’t need; over-collection during verification is itself a PDPL problem. | DSAR owner |
| 3–7 | Classify & scope | What is being asked: access, correction, deletion, withdrawal? Which relationship: customer, employee, guest, applicant? Confirm scope back to the requester if ambiguous — a clarified scope is a smaller search. | DSAR owner + legal |
| 5–18 | Search the data map | Run the system checklist (below) against the subject’s identifiers. Export findings with source, date range and format noted. | IT + system owners |
| 15–22 | Legal review & exemptions | Remove or withhold what the law permits or requires: third parties’ personal data, legally privileged material, data under statutory retention. Document every withholding decision and its basis. | Legal |
| 20–26 | Redact & assemble | Produce the response pack: what you hold, why you process it (lawful basis), where it came from, who it is shared with, retention periods — plus the data itself in an intelligible format. | DSAR owner |
| 26–30 | Respond & record | Deliver securely, record delivery in the register, and file the full decision trail. If a correction or deletion was requested, confirm the action and its propagation to processors. | DSAR owner |
Two rules protect the deadline: the register is updated the day anything happens (auditability is half the compliance), and an escalation trigger fires at day 15 if the search is incomplete — not at day 28.
Where personal data hides — the search checklist
The search is where DSARs fail. In a typical Saudi mid-market organisation, one person’s data can live in a dozen systems, and the playbook must name them in advance:
- CRM / sales tools — contacts, deals, notes, call logs (HubSpot, Salesforce, spreadsheets)
- Email — the highest-volume and least structured store; search by the subject’s addresses
- ERP / billing — invoices, statements, payment references
- HR systems — if the subject is or was an employee or applicant: files, payroll, Qiwa/GOSI records handled under their own retention rules
- Support channels — ticketing, WhatsApp Business threads, live chat transcripts
- Call recordings — contact-centre and PBX recording platforms, with dates
- CCTV — if the request covers premises visits: retention windows usually decide this
- Marketing — newsletter lists, consent records, event registrations
- Documents & shares — contracts, proposals, scanned IDs in folders
- Backups & archives — state your restore-and-search policy; blanket “it’s in backups” answers do not survive scrutiny
- Processors — vendors handling data on your behalf: your contracts must let you pull their part of the answer
Organisations that maintain a records-of-processing map (system → data categories → lawful basis → retention → processor) turn a multi-week search into a matter of days. Building that map is the single best DSAR preparation there is.
The adjacent duty: breach notification
Under the Implementing Regulations, a breach that may cause harm to personal data or to the data subjects’ rights or interests must be notified to SDAIA within 72 hours of becoming aware of it, and the affected individuals informed without undue delay where the breach may damage their data or conflict with their rights — and the same operational muscles serve both duties. If your DSAR playbook knows where data lives, your breach response knows what was exposed. Build them as one capability.
Response skeletons
Acknowledgment (day 0–2): “We confirm receipt of your request dated [date] concerning your personal data. To protect your information we will first verify your identity, and will respond within the period required by the Personal Data Protection Law. Reference: [DSAR-ID].”
Response cover (day 26–30): identity of the controller and contact point · confirmation of processing · categories of data held and their sources · purposes and lawful bases · recipients or categories of recipients · retention criteria · the data itself, enclosed in intelligible format · a note on any material withheld and the legal basis · how to seek correction or escalate.
Both skeletons should exist in Arabic and English — requests will arrive in both.
Readiness checklist
You are DSAR-ready when: a named owner and deputy exist; the register template exists and is tested; identity-verification rules are written; the data map is current within six months; system owners know their search procedures; legal review has a named counsel path; response templates exist in AR + EN; the escalation trigger is defined; processors are contractually bound to assist; and you have run one full drill on a fictitious request and hit the deadline. The drill is the difference between a playbook and a document.
Where EIE fits
Elite Ideas Establishment builds the technical layer of PDPL readiness for Saudi organisations: the records-of-processing data map across your systems, search and export procedures for each platform (CRM, email, PBX and call recording, CCTV, file stores), secure response handling, and the monitoring that keeps you ready for PDPL’s breach-notification window — alongside our NCA and SAMA compliance engineering, from our Jeddah headquarters, serving organisations Kingdom-wide. Talk to our team →
Frequently asked questions
How long do we have to answer a PDPL data subject access request?
Under the Implementing Regulations, 30 days from receipt, extendable once by a further 30 days for requests needing unusual effort or where the same person has made multiple requests, with the data subject notified of the extension and its reasons. Log receipt the day it arrives — the clock does not wait for the request to reach the right department.
Can we charge a fee for responding to a DSAR?
The working assumption should be no fee for a reasonable request. Repetitive or manifestly excessive requests are handled through the mechanisms the regulations allow — with legal advice, and with every decision documented.
Does PDPL apply to employee data or only customers?
PDPL protects personal data of individuals generally — employees, applicants, customers, guests and visitors alike. HR data adds its own retention obligations, which your deletion decisions must respect.
What if some of the data also contains other people’s information?
Third parties’ personal data is protected too: redact it or withhold those records, and document the basis. This is the most common legal-review action in real DSARs.
Sources and further reading: Saudi Data and Artificial Intelligence Authority — Personal Data Protection Law and its Implementing Regulations. The regulations are updated; verify current requirements before relying on specifics.
Related: Cybersecurity & Compliance services · NCA implementation guide · SAMA CSF checklist