PDPL Data Subject Rights: What Saudi Organisations Owe

Saudi Arabia's Personal Data Protection Law grants individuals a set of enforceable rights over their personal data — and places the burden of operationalising those rights squarely on the controller. The Implementing Regulations published by SDAIA add procedural detail that turns each right into a measurable obligation. For compliance teams in Saudi banks, government entities, healthcare providers and energy operators, the question is no longer whether these rights apply but whether the organisation can respond to them within the statutory window, every time, with evidence.

This post breaks down each right, explains the practical obligations it creates, and outlines the operational model that keeps a PDPL programme running without firefighting.

The rights at a glance

PDPL establishes six core rights for data subjects:

1. Right to be informed — Individuals must be told, before or at the point of collection, what data is being collected, why, on what legal basis, who the controller is, and who will receive their data.
2. Right of access — Data subjects can request a copy of all personal data the controller holds about them, delivered in a readable and commonly used electronic format.
3. Right to correction — If data is inaccurate or incomplete, the individual can request that the controller correct or complete it.
4. Right to destruction — When data is no longer necessary for the purpose it was collected, or when it has been processed unlawfully, the data subject can request its deletion.
5. Right to restrict processing — During a dispute about accuracy or lawfulness, the data subject can request that processing be paused while the matter is resolved.
6. Right to object — In defined circumstances, data subjects can object to processing — particularly where the controller relies on legitimate interests or where processing is used for direct marketing.

Each right comes with conditions, exceptions and operational implications. The sections below address the ones that trip organisations up most often.

The 30-day response clock

Controllers must respond to a data subject request within 30 calendar days of receipt. The Implementing Regulations allow an extension of an additional 30 days where the request is complex or where the controller has received a high volume of requests — but the controller must notify the data subject of the extension and the reason before the original 30-day deadline expires.

This means your intake process needs to capture the date of receipt with precision. A request that sits unread in a shared mailbox for a week has already consumed a quarter of the response window. Organisations that run data subject requests through structured workflow — with automatic timestamping, owner assignment and escalation rules — consistently outperform those that rely on email.

Right to be informed — the privacy notice obligation

The right to be informed is the most proactive of the six. It does not wait for a request; it fires at the moment of collection. Controllers must provide a privacy notice in specific, clear and explicit language. The notice must include:

• The identity and contact details of the controller.
• The contact details of the DPO (if appointed).
• The purposes of processing.
• The legal basis for processing.
• The categories of recipients.
• Whether data will be transferred outside Saudi Arabia.
• The retention period or the criteria used to determine it.
• The data subject's rights under PDPL.

A generic, copy-pasted privacy policy from another jurisdiction will not satisfy this. The notice must reflect the actual processing activities of the Saudi entity, must be written in Arabic (with an English version where appropriate), and must be accessible at the point of collection — not buried in a terms page that no one reads.

Right of access — format and scope

When a data subject exercises their right of access, the controller must provide all personal data held about that individual. The response must be in a readable and clear format and in a commonly used electronic format where the request is made electronically.

The practical challenge is not the format — it is the discovery. Organisations that hold personal data across multiple systems (HR, CRM, finance, ticketing, marketing automation) must be able to locate and compile all records relating to one individual. Without a central data inventory or a unified search capability, this becomes a manual exercise that burns through the 30-day window.

Controllers are not required to disclose the identities of other data subjects whose data appears in the same records. Redaction is expected where producing the requested data would reveal personal data of a third party.

Right to destruction — when deletion is not straightforward

The right to destruction applies when:

• The data is no longer necessary for the purpose for which it was collected.
• The data subject withdraws consent (and there is no other legal basis).
• The data has been processed unlawfully.
• Deletion is required to comply with a legal obligation.

In practice, destruction requests collide with retention obligations. A Saudi bank cannot delete customer identification data that it is required to retain under SAMA's anti-money-laundering regulations. A healthcare provider cannot destroy patient records that must be kept for the statutory retention period under Ministry of Health regulations.

The controller must be able to distinguish between data it is legally obliged to retain and data it merely continues to hold out of convenience. Where partial destruction is the answer — deleting marketing data while retaining regulatory records — the controller must document the reasoning and communicate clearly to the data subject which data has been destroyed and which has been retained, and why.

Right to object — legitimate interests and direct marketing

The right to object is most frequently exercised in two contexts: where the controller processes data on the basis of legitimate interests, and where data is used for direct marketing.

Where a data subject objects to processing based on legitimate interests, the controller must stop processing unless it can demonstrate compelling grounds that override the interests of the data subject. This is not a rubber-stamp exercise. The controller must conduct a documented balancing test — weighing the purpose and necessity of the processing against the impact on the individual — and be able to produce that assessment if challenged by SDAIA.

For direct marketing, the right to object is absolute. If a data subject says stop, you stop. There is no balancing test and no override.

Operationalising rights at scale

Running data subject rights as a manual process works when you receive one request a quarter. It breaks when you receive ten a week — which is the trajectory for any Saudi organisation with a large customer base or a significant employee population.

The operational model that scales looks like this:

• Intake portal — A published channel (web form, dedicated email) that timestamps receipt, confirms the request type, and assigns a case number.
• Identity verification — A defined process to verify the requester's identity before disclosing data. This must be proportionate — not so burdensome that it deters legitimate requests, but robust enough to prevent social engineering.
• Routing and ownership — Automatic routing to the team that holds the relevant data, with clear ownership and an escalation path if the owner does not act within a defined internal SLA.
• Response assembly — Tooling that can pull data from multiple systems, apply redactions, and compile a response package.
• Clock management — Automated tracking of the 30-day deadline with alerts at defined thresholds (e.g. 15 days, 25 days).
• Evidence logging — Every step recorded in an audit trail that can be produced for SDAIA or for internal audit on demand.

Common mistakes

• No published channel. If data subjects cannot find out how to submit a request, you have a gap before the first request ever arrives.
• No identity verification. Disclosing personal data to someone who is not the data subject is a breach, not a compliance win.
• Treating all requests as access requests. A request to delete is not a request to access. Route them differently.
• Ignoring the clock. A late response is a compliance failure — even if the response itself is substantively correct.
• No audit trail. If you cannot prove you responded in time, the burden of proof is against you.

How GRC Vantage helps

GRC Vantage's compliance module includes a pre-built data subject rights workflow that covers intake, verification, routing, response assembly and audit logging. Every request is tracked against the 30-day clock with automatic escalation, and the evidence trail maps directly to your PDPL control library. The platform runs inside Saudi Arabia from our Riyadh and Dammam offices, keeping the data about data subject requests itself within the Kingdom.

For the full PDPL implementation roadmap, see our PDPL Saudi Arabia checklist. If you are building a PDPL programme, book a demo and we will walk through the data subject rights workflow in detail.