Resources · Compliance
PDPL compliance in Saudi Arabia: a technical guide for IT systems
PDPL compliance in Saudi Arabia is legal and technical work at once. Your legal team and data protection officer read the Personal Data Protection Law and decide the obligations; IT shows they are met: where personal data sits, who can reach it, whether copies reach test environments, whether any leaves the Kingdom, and how fast a breach would be detected. This guide covers the technical side, where Redgate and Datadog help, and where tools are not enough.
Published 9 min read
In short, for executives
- What it is: the Saudi law governing personal data, overseen by the Saudi Data and AI Authority (SDAIA), which issues its Implementing Regulations and its transfer regulation.
- What falls to IT: finding personal data, controlling access, keeping it out of test, controlling what leaves the Kingdom, and detecting breaches in time.
- Where tools help: masking in non-production, an in-Kingdom cloud region, access logs and alerts.
- What tools do not do: decide the lawful basis, write the privacy notice, or make you compliant.
What the Personal Data Protection Law is, and who oversees it
The Personal Data Protection Law governs processing personal data in the Kingdom, from collection to destruction. It is overseen by the Saudi Data and AI Authority (SDAIA), which publishes the law's Implementing Regulations and the Regulation on Personal Data Transfer outside the Kingdom, with services on the National Data Governance Platform. The law's text is on the Bureau of Experts at the Council of Ministers site.
Read more
The law gives the person the data is about rights, including knowing what is collected and why, and seeing and correcting it. It obliges the organisation to protect the data, report breaches and meet conditions for transfers outside the Kingdom.
This guide does not repeat article numbers or deadlines: copying them from summaries is how wrong requirements spread, and the texts are updated. Read the current text with your legal team, then use this guide to turn each obligation into controls.
RelatedSaudi Data and AI Authority (SDAIA)National Data Governance PlatformBureau of Experts at the Council of Ministers
PDPL compliance in Saudi Arabia: what the law means for IT systems
For IT, PDPL compliance usually comes down to six questions. Any you cannot answer with evidence is the starting point, not a product list:
- Where does personal data sit? Which databases, columns, files, backups and logs. It often hides in free-text fields and error logs.
- Who sees it? Which roles reach each class, who holds administrator rights, and whether they are reviewed.
- Do copies go into test and development? A restored production copy carries the same data, with weaker protection and more people around it.
- Does any of it leave the Kingdom? Through a cloud service, SaaS platform, backup or monitoring tool.
- How long would it take you to detect a breach? Reporting has a deadline, which cannot be met for an incident nobody noticed.
- Is there a record of processing activities? Each activity's data, purpose, systems and access. Legal writes the purpose; IT writes the systems.
PDPL requirements for IT systems: obligation, question and control
The first column names areas of work in plain words, not article titles; your legal team maps each to the text. The last column is what tools produce, not what is enough.
| Area of obligation | Technical question | Control | Where tools help |
|---|---|---|---|
| Knowing the data and its purposes | Where does personal data sit in each system? | An inventory of sensitive columns and files, linked to the record of processing activities | Automatic classification in Redgate Test Data Manager proposes sensitive columns; the data owner reviews them |
| Protecting the data | Who reaches each class, and with what rights? | Least privilege, and periodic review of administrator accounts | Sign-in logs from the database and identity provider collected in Datadog, with a dashboard of privileged access |
| Non-production environments | Is there real data in test and development? | Masking before the copy leaves production, or generated data | Deterministic masking and subsetting in Redgate Test Data Manager, keeping the relationships between tables |
| Transfer outside the Kingdom | What leaves, to where, and why? | A written decision per class of data, and an in-Kingdom region for what must stay | The Google Cloud region in Dammam (me-central2), and masking sensitive values before logs are sent |
| Breach reporting | How long until you detect an incident and know its scope? | Alerts on unusual access, and a written escalation path | Detection rules and monitors in Datadog, and a log showing what the account reached |
| Accountability | Who changed a permission or a setting, and when? | An audit log that the people being audited cannot edit | Datadog Audit Trail records who uses Datadog and what they do |
Test copies: the most common gap, and the easiest to close
In most organisations whose data we review, the largest store of personal data outside production is test, development and training. The copy is restored whole because it is quicker, then stays for years, open to developers, testers and suppliers who need no real customer's name or ID number.
The fix is to mask the data before it leaves production: names, IDs, mobiles and emails become realistic values tied to no real person, with relationships between tables intact. Interkey implements Redgate's tooling for database delivery, including Redgate Test Data Manager, which Redgate's documentation describes as classifying sensitive columns automatically, masking them deterministically, cutting a smaller representative subset, and running from a command line inside a CI/CD pipeline. The guide to PDPL and test data sets out those steps in detail, and the data masking guide compares the methods.
Support staff who read production data without needing every value need dynamic masking, which hides values by role without changing stored data. The guide to dynamic data masking covers when it fits and when it does not.
RelatedPDPL and test datadata masking guidedynamic data masking
Data residency and transfers outside the Kingdom
The transfer regulation sets when data may leave the Kingdom and on what conditions; your legal team decides per class. IT's part is to know every path by which data actually leaves, because most are not on the diagram: a backup abroad, an HR or customer-service SaaS platform, a monitoring tool sending logs with names and mobile numbers.
Read more
For data that must stay, Google Cloud runs a region in Dammam (me-central2). AWS has announced a Saudi Region; until it appears in AWS's list of available Regions, a plan should not depend on it. Your own data centres remain an option. Interkey is a Google Cloud partner and an AWS partner. The guide to data residency in Saudi Arabia sets out the decision per class of data.
Breach detection and access logs: what you need before an incident
The law requires breaches to be reported by a deadline in the text. The technical problem comes first: you cannot report an incident nobody detected, nor scope it without a log of what the compromised account read.
So you need, before any incident: access logs collected from databases, the identity provider and sensitive applications; alerts on unusual access that a named person answers; and an audit log of the monitoring platform. In Datadog, alerts come from the logs operations already uses, and Datadog Audit Trail records who changed a rule, an alert or a retention setting.
Read more
Logs can carry personal data too. As of November 2026 no Datadog site is in the Middle East, so what must stay is masked or dropped inside your network before sending. Interkey sells Datadog licences in Saudi Arabia, implements the platform and provides technical support.
PDPL vs GDPR: what carries over from an existing programme
Many organisations in the Kingdom already run a GDPR programme. Most technical work carries over; the legal analysis does not.
| Area | What is reused | What to check again for the PDPL |
|---|---|---|
| Data inventory | System maps and the list of sensitive columns | That the inventory covers every system processing data in the Kingdom |
| Masking and test data | Masking rules and the refresh pipeline | Almost nothing: the technical control is the same |
| Access control and logs | Roles, reviews and access dashboards | Retention periods and who is notified, under the Saudi text |
| Cross-border transfer | The list of paths by which data leaves | All the conditions: they are in the Saudi transfer regulation, not the European one |
| Breach reporting | The detection and escalation path | Which authority is notified, the deadline, and what the report contains |
The same holds for the National Cybersecurity Authority's controls: much of this work is shared, as the guide to NCA ECC explains.
What IT hands the data protection officer
The regulations set when a data protection officer must be appointed; your legal team knows if that applies. Either way, the role needs these from IT:
- An inventory of systems that hold personal data, with the owner of each, and dated.
- A list of sensitive columns and files in each system, including free-text fields and error logs.
- A map of the paths by which data leaves the Kingdom, and what leaves on each.
- A description of test and development environments, and whether they hold real or masked data.
- A list of privileged accounts, and the date they were last reviewed.
- A written incident path, from the first alert to informing the data protection officer, naming who handles each step.
- Retention periods per class, and how data is deleted when they end.
How a PDPL data review with Interkey runs
Interkey's team works from Riyadh, with engineers who write documents and meet your teams in Arabic and English, and provides technical support after go-live. We work alongside your legal team and data protection officer, not in their place: they decide the obligation; we show what your systems do and what it takes to match it. The review is not a legal opinion or a compliance certificate, and if your current tools are enough, we say so.
-
List the systems.
The systems that hold personal data, the owner of each, and their non-production environments.
-
Find the data.
Classify the sensitive columns, review the result with the data owner, and search free-text fields and logs.
-
Map the paths.
Who reaches the data, where it is copied, and what leaves the Kingdom.
-
List the gaps.
What cannot be shown today, ranked by risk, so your team decides where to start.
-
Implement.
Masking in the refresh pipeline, access logs and alerts collected in one place, and moving what must stay to an in-Kingdom region.
-
Hand over.
Documents and runbooks for your team and the data protection officer, with us staying on for technical support.
Questions IT teams ask about the PDPL
Which authority oversees the PDPL in Saudi Arabia?
The Saudi Data and AI Authority (SDAIA), which publishes the Implementing Regulations and the transfer regulation. The law's text is on the Bureau of Experts site. Read the current text there, not in summaries.
Is real customer data in a test environment a breach of the PDPL?
The legal answer is for your legal team. Technically, a production copy in test is personal data with weaker protection, and a leak from it is a personal data leak. Masking before the copy leaves production removes most of the risk.
Does all our personal data have to stay inside Saudi Arabia?
Not necessarily all of it: the transfer regulation sets the conditions, and your legal team decides per class. What must stay can use the Google Cloud region in Dammam or your own in-Kingdom infrastructure, with sensitive values masked before logs go to an outside platform.
How long does a PDPL data review take, and what drives its cost?
It depends on how many systems hold personal data, their non-production environments, and whether each has an owner who can answer, so we estimate after listing the systems. Implementation cost follows the databases to mask, log volumes and licences, quoted in one proposal with support.
How does the PDPL differ from the GDPR for a technology team?
The technical work is close: inventory, access control, masking, logging and breach detection, so most of a GDPR programme is reused. Transfer conditions, the authority to notify and deadlines come from the Saudi text.
Do Redgate and Datadog make us PDPL compliant?
No. Compliance is decisions you make: lawful basis, notice, retention, requests. Redgate helps mask test data; Datadog gives access logs, alerts and an audit trail. The policy, and who answers alerts, stay with you.
Next
Related pages
Next step
Book a PDPL data review
Tell us which systems hold personal data, how test environments are built, and what leaves the Kingdom if you know. We will come back with a first step showing what can be proven today and what is missing.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia