Type: Blog post (cluster supporting /cybersecurity-saudi-arabia/ pillar) Slug: pdpl-data-subject-access-request-dsar-saudi-arabia-playbook Yoast title: PDPL DSAR Operational Playbook Saudi Arabia | 30-Day Response | EIE Yoast meta: Operational playbook for handling Saudi PDPL Data Subject Access Requests. 30-day response process, search across systems, legal review, sample templates. Focus keyphrase: pdpl dsar saudi arabia Categories: Cybersecurity
—
The Personal Data Protection Law (PDPL) is in force in Saudi Arabia. Most KSA companies have published a privacy policy and added cookie consent banners. Far fewer have actually operationalized the data subject rights process — the workflow that fires when a Saudi customer submits a Data Subject Access Request (DSAR) tomorrow.
The regulatory expectation is operational maturity, not policy presence. SDAIA (Saudi Data and AI Authority) — the PDPL regulator — measures organizations on response timelines, evidence trails, and procedural discipline. Saying “we have a privacy policy” is not a defense if a 30-day DSAR clock expires without a documented response.
This guide presents a working operational playbook for handling Saudi PDPL DSARs. It assumes your organization processes Saudi personal data in the course of operations (customer records, employee data, supplier contacts, website visitor data). It assumes you’ve published a privacy notice and have a designated DPO or equivalent contact. It focuses on what happens AFTER the request arrives.
What constitutes a valid DSAR under PDPL
A Data Subject Access Request is the data subject’s exercise of their rights under PDPL. The categories of rights:
Right of access. The data subject asks: “what personal data do you hold about me, and what are you doing with it?”
Right of correction. The data subject identifies inaccurate data and requests correction.
Right of erasure. The data subject requests deletion of their personal data (subject to legitimate retention requirements).
Right of objection. The data subject objects to specific processing (e.g., marketing).
Right to data portability. The data subject requests their data in a structured, machine-readable format.
Right to know about automated decision-making. The data subject asks about automated decisions affecting them.
For the request to be valid: – The data subject must be identifiable (i.e., the requester can be matched to specific data records) – The request must come from the data subject (or their authorized representative) – The request must be sufficiently specific to allow a response
A vague request like “send me everything you have” is technically valid but the organization can ask clarifying questions to scope the response appropriately.
The 30-day response timeline
PDPL gives organizations 30 days from receipt of a valid DSAR to provide a response. The 30 days is not 30 business days — it is calendar days. Saudi public holidays do not extend the clock.
For complex requests, a 30-day extension is possible if you notify the data subject within the original 30 days, explain why the extension is needed, and provide the response within the extended period (60 days total).
If you fail to respond within the timeline, the data subject can escalate to SDAIA. Late responses are themselves a PDPL violation, separate from any underlying violation about the data processing itself.
The DSAR workflow — step by step
This is the working playbook. Each step should have a documented owner, expected duration, and output.
Step 1 — Receipt and acknowledgment (Day 0-1)
When a DSAR is received via any channel (email, web form, postal letter, in-person request, social media DM), the following must happen within 24 hours:
– Log the request in a central DSAR tracker (date received, channel, requester details, scope) – Send acknowledgment to the requester confirming receipt – Open an internal ticket assigned to DPO or designated DSAR handler
Output of Step 1: Logged request + acknowledgment sent.
Step 2 — Identity verification (Day 1-3)
You must verify the requester is who they claim to be. The level of verification should match the sensitivity of the data:
– For routine customer DSARs: existing authentication methods (account login, contact info match) – For employee DSARs: HR verification – For sensitive data (health, biometric, financial): additional verification (government ID copy, video call)
If verification fails or is incomplete: request clarification from the data subject. The 30-day clock can pause during verification but must resume once verification is complete.
Output of Step 2: Verified requester identity + scope clarification if needed.
Step 3 — Search across systems (Day 3-15)
This is the operationally heavy step. The organization must search every system that might hold the data subject’s data:
– Customer database / CRM – Marketing automation platforms – HR systems (for employee DSARs) – Email archives – Accounting / billing systems – Surveillance / CCTV systems (if data subject identifiable in footage) – Call recording systems – Cookies / website analytics – Help desk / ticket systems – Backup tapes (if data was deleted from primary but retained in backup)
Most KSA organizations don’t have a unified search-across-systems capability. The work is manual — each system queried separately, results consolidated.
For organizations preparing for first DSAR: build a system inventory NOW that maps personal data categories to systems. The first DSAR is significantly easier when you know which 12 systems might have data for any given individual.
Output of Step 3: Compiled set of all personal data held about the data subject, by system.
Step 4 — Legal review (Day 15-20)
Not everything goes to the data subject as-is. Legal review evaluates:
– Personal data of third parties commingled with the data subject’s data (typically redacted) – Data covered by legal privilege – Data covered by other regulatory requirements (anti-money laundering, financial regulations) – Data that could reveal trade secrets or commercially sensitive information – Information that would prejudice ongoing investigations or legal proceedings
The legal review determines what is disclosed, what is redacted, what is withheld with reasoning documented.
Output of Step 4: Approved set of data for response, with documented reasoning for any withholdings.
Step 5 — Compile response (Day 20-25)
The response document includes:
– Confirmation of the personal data held – The purposes for which it is processed – The categories of recipients (who else gets the data) – The retention period (or criteria for determining it) – The data subject’s rights and how to exercise them – The right to complain to SDAIA – The source of the data (if not collected from the data subject directly) – Information about any automated decision-making, if applicable
Format: structured document (PDF), data in tables organized by source system. For data portability requests, structured machine-readable format (CSV, JSON).
Output of Step 5: Complete response document ready for review.
Step 6 — Deliver response (Day 25-30)
Final review by DPO, then delivery to data subject via secure channel:
– Encrypted email – Secure portal with one-time download link – Physical mail with tracking (for non-digital recipients)
Record delivery confirmation. Update DSAR tracker to “completed.”
Output of Step 6: Response delivered, tracker updated, evidence retained.
Step 7 — Retention of evidence
Retain the DSAR record (request, verification evidence, response, delivery confirmation) for the period prescribed by your organization’s retention schedule — typically 3-7 years. This is needed if the data subject later complains to SDAIA or if litigation arises.
Sample DSAR response template
Below is a working template. Customize for your organization but maintain the structure for SDAIA compliance.
“` [Date] [Data subject name / contact information]
Subject: Response to your Data Subject Access Request
Dear [Name],
This responds to your data subject access request received on 2026 under the Saudi Personal Data Protection Law (PDPL).
We have completed our search of our systems and provide the following:
1. PERSONAL DATA WE HOLD ABOUT YOU [Table — system / data categories / data fields / source]
2. PROCESSING PURPOSES We process your personal data for the following purposes: – [purpose 1, with lawful basis] – [purpose 2, with lawful basis] – [etc.]
3. RECIPIENTS OF YOUR DATA Your data is shared with: – [internal recipients] – [external recipients with category] – [any cross-border transfers, with country and safeguards]
4. RETENTION PERIODS We retain your data for the following periods: – [category 1]: [retention period or criteria] – [category 2]: [retention period or criteria]
5. SOURCE OF YOUR DATA We collected your data from: – [self-provided by you, or third-party sources with category]
6. YOUR RIGHTS Under PDPL you have the right to: – Access your personal data (this request) – Correct inaccurate data – Request deletion (subject to retention requirements) – Object to specific processing – Withdraw consent where consent is the lawful basis – Lodge a complaint with SDAIA
7. AUTOMATED DECISION-MAKING [Statement about any automated decisions affecting the data subject]
8. WITHHELD DATA We have withheld the following categories for the reasons stated: – [data category]: [reason — third party rights, legal privilege, etc.]
If you wish to exercise other rights or have questions about this response, contact our Data Protection Officer at [contact].
You also have the right to lodge a complaint with the Saudi Data and AI Authority (SDAIA) if you believe your rights are not being respected.
Sincerely, [Name, Title] Data Protection Officer [Organization] “`
Edge cases — what to do when
The data subject sends an incomplete or ambiguous request. Ask clarifying questions within 24-48 hours of receipt. The 30-day clock can pause until you have enough information to respond.
Request includes personnel data with HR sensitivity. HR data requests follow similar process but verification is through HR rather than customer service. Performance reviews, disciplinary records, and similar sensitive data are typically released to the employee (it’s their data) but third-party information (e.g., comments from other employees in 360 reviews) is redacted.
Request includes biometric data (fingerprint, face) from access control systems. Yes, this is personal data under PDPL. Provide the underlying data category descriptions; the actual biometric template (the binary fingerprint hash) is typically not human-readable but you should disclose that you hold it.
Request includes CCTV footage. If the data subject is identifiable in CCTV footage, the footage is their personal data. Practical approach: provide a description of when they appear (date, time, location) plus a still image if requested. Full video footage release is often complex due to third parties in frame.
Request includes call recording. If you record calls, those recordings are personal data. Provide a list of call recordings (date, time, length, purpose) and offer access. Other parties in the call (e.g., agents) may be redacted from any disclosure.
Data has been deleted from primary systems but exists in backup. You must disclose that backups exist and may contain data. The 30-day timeline may not require restoring from backup, but you should be transparent that older data exists in backups with a defined retention.
The data subject requests data portability for very large datasets. Provide in standard format (CSV / JSON). For exceptionally large datasets, you may discuss alternative delivery methods with the data subject (e.g., USB drive, secure cloud transfer).
The data subject is deceased. PDPL rights do not extend to deceased persons in the same way. Estate representatives may have rights under separate legal frameworks. Refer to legal counsel.
The data subject is a minor. Parental / guardian consent considerations apply. Verify the authority of the parent / guardian to request data on behalf of the minor.
Common DSAR mistakes that produce SDAIA findings
Mistake 1: No central DSAR tracker. Each request handled in isolation. No way to demonstrate cadence or track timelines. SDAIA wants to see organized records.
Mistake 2: Missing 30-day timeline. The most common operational failure. Often happens when verification or search takes longer than budgeted.
Mistake 3: Incomplete search across systems. Organization searches the customer database and stops. Marketing automation, surveillance, call recordings, third-party processors all missed.
Mistake 4: No documented reasoning for withholdings. Legal review withholds something but doesn’t document why. SDAIA reviews withholding patterns.
Mistake 5: Delivering response insecurely. Email containing personal data sent unencrypted to a public email address. PDPL requires secure delivery channels.
Mistake 6: Treating DSAR as one-off. Each new DSAR re-invents the wheel because there’s no playbook, no system inventory, no tracker, no defined steps.
Mistake 7: No DPO contact information published. Privacy policy doesn’t include DPO contact details, so requests come to general contact channels that don’t know how to route them.
Mistake 8: Failing to acknowledge receipt. The data subject doesn’t know if you received the request. Acknowledgment within 24 hours is best practice and reduces follow-up requests.
Preparing your organization — what to do BEFORE the first DSAR
The above playbook works if it’s instrumented in advance. If you operationalize after your first DSAR, you’re already behind. Recommended preparation:
Build a system inventory mapping each system to personal data categories it holds. Update annually.
Designate a DPO (or designated PDPL responsible person). Publish contact info.
Build a DSAR tracker — even a structured spreadsheet works for low volume. Captures: date received, channel, requester, scope, status, target response date, delivery date.
Document the workflow — the playbook above adapted to your organization, with named owners for each step.
Run a dry-run — internally generate a fake DSAR and execute the playbook. Measure timing. Identify gaps.
Train customer-facing staff to recognize DSARs (often disguised as general support requests) and route them correctly.
Update privacy policy to reference DSAR submission method explicitly.
Configure secure delivery — encrypted email setup, or a portal for sensitive deliveries.
How EIE supports PDPL operational compliance
Elite Ideas Establishment helps KSA enterprises operationalize PDPL beyond the policy layer:
– DSAR readiness assessment — gap analysis against operational requirements – DSAR playbook authoring — customized to your organization, system landscape, vertical – System inventory mapping — what personal data lives where – DPO support — interim or fractional DPO function for organizations without one – Annual mock DSAR — independent test of the operational readiness – Breach notification capability — 72-hour PDPL notification protocol
For organizations preparing for first PDPL audits or responding to first DSARs, EIE provides the structure and external perspective to operationalize what was previously policy theatre.
Frequently asked questions
Does PDPL apply to my organization if we only have a few customers? PDPL applies regardless of size. Specific obligations scale with the amount and sensitivity of data processed, but the framework applies broadly to any organization processing Saudi personal data.
Can we charge a fee for DSAR responses? PDPL generally requires DSAR responses without charge for the first request. Repeated or excessive requests may justify a reasonable fee, with documentation.
What if our cloud / SaaS vendors hold the data? You remain the controller of the data. The cloud vendor is a processor. Your DSAR response must include data held by your processors. Build the DSAR process with your processors in advance (data processing agreements should include DSAR support clauses).
How long should DSAR evidence be retained? Typically 3-7 years depending on your organization’s retention schedule. The evidence supports defending against any subsequent SDAIA complaint or related legal action.
Can DSAR responses be partial? Yes — if a portion is withheld for valid legal reasons, document the reasoning and provide what can be provided. Don’t withhold the entire response.
What happens if SDAIA receives a complaint about our DSAR handling? SDAIA investigates, may request documentation, may require corrective action. Documented evidence of process discipline is the strongest defense.
Do we need separate DSAR processes for different categories of data subjects (customers vs employees)? The core workflow is the same. Specific verification methods, source systems, and legal review considerations differ by data subject category.
Are there template DSAR submission forms? Some organizations publish web forms making submission easy. Others rely on email or postal channels. Web forms speed receipt and acknowledgment but require care in security and accessibility.
Talk to EIE about PDPL operational compliance
PDPL compliance isn’t a policy on the website. It’s a workflow that fires when the request arrives, tracks to a documented response within 30 days, and produces an evidence trail for SDAIA scrutiny.
If your organization has the policy but not the playbook, EIE provides the operational layer.
Phone: +966 12 6522 996 Email: info@eliteideas.net Website: eliteideas.net
For deeper context on KSA cybersecurity broadly — including NCA controls, SAMA framework, managed SOC, and penetration testing — see our [Cybersecurity in Saudi Arabia pillar](https://eliteideas.net/cybersecurity-saudi-arabia/).