A Developer's Guide to Saudi PDPL Compliance

The Personal Data Protection Law (PDPL) is no longer a preparatory phase — the compliance grace period ended in September 2024, and enforcement has been active since, supervised by the Saudi Data and AI Authority (SDAIA).

This guide is aimed at developers and digital product owners: what actually needs to change in your product.

Working across more than one Gulf market? This guide covers Saudi Arabia in depth. For how the Saudi, UAE, and Qatari regimes compare — and which one governs you — start with the Gulf regulatory compliance guide.

Important note: this is technical guidance, not legal advice. The law and its implementing regulations evolve, and requirements vary by sector and data type. Consult a qualified legal advisor before relying on any interpretation here.

Who does it apply to?

The law applies to processing personal data of individuals inside the Kingdom — regardless of where your company or servers are located. If you have Saudi users, it concerns you.

Personal data is broader than many assume: name, email, phone, geolocation, device identifier, IP address, and any data enabling identification of a person.

Sensitive data carries stricter requirements: health data, financial data, biometric data, and data relating to minors.

1. Consent — the lawful basis for processing

Consent is the default basis for processing data. But not any consent suffices.

What does not count as valid consent:

• Pre-ticked checkboxes — not acceptable.
• Consent buried in terms of service — not explicit consent to processing.
• Blanket consent to everything — you need granularity by purpose.
• Conditioning the service on unnecessary consent — forcing users to accept marketing to use the service.

What to build into the product:

□ A separate checkbox per purpose (service / marketing / analytics)
□ Not pre-ticked
□ Clear text explaining the purpose in plain language
□ Withdrawal as easy as granting
□ Timestamped consent record (when, and against which policy version)

That last item is always overlooked: you must be able to prove when a user consented and to what. Record the timestamp and policy version with every consent.

For marketing specifically: explicit, separate opt-in consent is required. Marketing messages without consent are a clear violation.

2. User rights — what your product must provide

The law grants data subjects rights, and you must provide a mechanism to exercise them:

Building these into the product is far cheaper than handling them manually on every request. A simple "my data" page solves most of it.

A note on deletion: "delete account" must genuinely delete rather than hide. And watch backups and logs — data removed from the database but remaining in logs has not been deleted.

3. Breach notification within 72 hours

When a breach occurs that may harm data subjects, SDAIA must be notified within 72 hours of becoming aware of it.

What this means technically:

• You need monitoring that detects the breach at all. You cannot notify within 72 hours about a breach you discover two months later.
• You need sufficient logging to determine what leaked, when, and who was affected.
• You need a written procedure — who is notified internally? Who decides? Who contacts the authority?

Write that procedure before you need it. A breach is not the moment to improvise process.

4. Transferring data outside the Kingdom

The law places restrictions on transferring personal data outside Saudi Arabia, requiring specific safeguards when transferring.

What this means for a developer:

• Hosting — where is your database actually stored? See our hosting comparison guide.
• Third-party services — analytics, notifications, email, AI providers; each may move data outside the Kingdom.
• Backups — many default configurations replicate data to other regions for resilience. That is a transfer.
• Logs — they may contain personal data and be stored in an external service.

A consistently overlooked point: verifying your primary data location isn't enough. Backups, logs, and integrations transfer data too, and many default configurations distribute them geographically without you noticing.

5. Development and testing environments

Using real Saudi user data in a development or testing environment is treated as a violation.

This is an extremely common practice — a copy of the production database on a developer's machine or a staging server — and it is a clear breach.

The alternative:

• Generated data for testing.
• Anonymisation if you need realistic data structure.
• Masking sensitive fields whenever copying any production data.

6. Privacy policy

It must be published in Arabic and English, and include:

• Categories of data collected.
• The purpose for each category.
• Retention periods.
• Data subject rights and how to exercise them.
• A privacy contact point.
• Whether data is transferred outside the Kingdom and the safeguards applied.

A policy copied from a foreign template is insufficient — it must reflect what your product actually does. A policy describing practices you don't follow is worse than none.

7. Special cases

Minors. Data from those under the age of majority requires guardian consent, which means a guardianship verification mechanism rather than a checkbox. See our educational apps guide.

Health data. Sensitive by nature, with additional requirements from health authorities. See our clinic apps guide.

Artificial intelligence. Passing user data to an external language model is both a transfer and processing. Verify the provider's policy on using inputs for training. See our AI model selection guide.

Technical checklist

• Separate consent per purpose, not pre-ticked, withdrawable.
• Timestamped consent records with policy version.
• A page letting users view, correct, export, and delete their data.
• Deletion covers backups and logs.
• Privacy policy in Arabic and English reflecting reality.
• Documented knowledge of where data is stored — including backups and logs.
• Every third-party service reviewed for data transfer.
• Development environments contain no real production data.
• Data encrypted in transit and at rest.
• Access controls — who on your team can see what.
• Monitoring that detects breaches, and a written 72-hour notification procedure.
• A retention policy — don't keep data without a purpose.

Who is accountable — you or your developer?

This question surfaces after an incident, which is the worst time to discover the answer.

Data protection law distinguishes the controller — the entity deciding why and how personal data is processed — from the processor, which handles data on the controller's instructions. In a typical project, you are the controller and your development agency is a processor.

The practical consequence: regulatory accountability sits with you. "Our developer configured it that way" is not a defence. You can contract obligations onto a vendor, but you cannot contract away your own accountability to the regulator.

What this means before signing:

• Put a data processing agreement in place — what the vendor may do with data, security obligations, and what happens at contract end.
• Require notification to you within 24 hours of any suspected breach. You have a 72-hour window overall; a vendor sitting on the news for two days consumes it.
• Establish deletion obligations — real production data on a developer's laptop after handover is a live exposure.
• Map sub-processors. Your vendor's chosen analytics, hosting, and error-tracking services are processing your users' data too, and they inherit the same requirements.

The most common real-world failure is not an attack. It is a copy of the production database sitting in a developer's local environment or a test server, long after anyone remembers it exists. Section 5 above covers why production data does not belong in development environments.

What non-compliance costs

Compliance work competes for budget against features, so it is worth being specific about the downside.

Regulatory penalties. SDAIA is the supervisory authority, and the law provides for warnings, fines, and — for the most serious violations, particularly unlawful disclosure of sensitive data — criminal liability. Penalty ceilings and enforcement practice change over time; verify current figures with a qualified local advisor rather than relying on any figure quoted in an article, including this one.

The costs that arrive first. In practice, most organisations feel these before any fine:

• Rework. Retrofitting consent flows, deletion capability, and audit logging into a shipped product costs several times what building them in would have.
• Lost enterprise deals. Government and large corporate buyers increasingly require compliance evidence during procurement. Failing that check removes you from the process silently.
• App store removal. Both stores enforce their own privacy requirements, and a listing can be pulled over a non-compliant privacy policy or undeclared data collection.
• Reputational damage. Breach notification is a legal duty, meaning your users learn about the incident by design.

The proportionate approach: the requirements scale with sensitivity. A brochure site collecting a contact form is not in the same position as a health app. Match the effort to the data — but do the mapping first, because plenty of teams discover they hold more personal data than they assumed.

This guide is written for developers and product owners planning compliance work. It is not legal advice. For regulated sectors — health, finance, government — engage a qualified Saudi data protection advisor before launch, not after.

Related reading

• API security — the technical implementation of these controls.
• Hosting and data residency — where your data actually lives.
• Fintech and SAMA — if your product is financial.
• Health apps in the UAE — for comparison with the UAE framework.

Frequently asked questions

Does the law apply to a company outside Saudi Arabia?

Yes, if you process data of individuals inside the Kingdom. Your company's or servers' location doesn't exempt you — the criterion is who you serve.

What does baseline compliance cost?

For a mid-size product: $2,000–$6,000 for technical implementation (consent mechanisms, rights page, transfer review, encryption) plus legal review cost. The figure is far lower when accounted for at design time, and far higher when added after launch.

What is the penalty for non-compliance?

The law provides for administrative penalties that can reach substantial amounts, with stricter penalties for intentional disclosure of sensitive data. More importantly, the authority has issued actual decisions against violators — enforcement is not theoretical.

Do I need to appoint a data protection officer?

It depends on your activity and processing scale. Some cases require it explicitly. Even where not mandatory, designating an internal owner is sound practice — and you must at minimum provide a privacy contact point.

Can I use Google Analytics?

It needs review: what data is sent? Where is it processed? Did you obtain separate analytics consent? Many tools are used with default settings that collect more than necessary. Review the settings and obtain explicit consent.

What about data collected before enforcement?

This point needs specific legal advice for your situation. In practice, many organisations re-request consent on compliant terms and delete anything they have no legitimate purpose to retain.

Conclusion

The law has been actively enforced since September 2024 — it is not a preparatory phase.

Build into your product: separate withdrawable consent, a user rights page, and a timestamped consent record.

Verify where your data actually lives — including backups, logs, and third-party services, not the database alone.

And never use real production data in development environments — a common and clear violation.

And consult a legal advisor — this technical guide is no substitute.

Building a product that processes Saudi data? Get in touch — we account for these requirements at design time rather than after launch. See our services.