Database DevOps · Test data
PDPL test data compliance: personal data in development, test and analytics copies
PDPL test data compliance is the part of Saudi Arabia's Personal Data Protection Law work that most programmes reach last: the copies of production data that sit in development, testing, user acceptance, analytics, training and vendor environments. Personal data in those copies is still personal data, usually with more people able to read it and fewer controls around it. This guide explains, as general information, what the law means for those copies, sets out five practical controls (catalogue, mask, subset, restrict access, keep records), and shows where Redgate's tooling helps and where it does not.
Published 9 min read
In short, for executives
- The law: the Personal Data Protection Law (PDPL) governs personal data in Saudi Arabia, and the Saudi Data and Artificial Intelligence Authority (SDAIA) oversees it.
- The blind spot: a full restore of production into test, a reporting extract or a file sent to a vendor each creates another place where the same personal data lives.
- What works: know where personal data is, mask it before anyone connects, copy only what a test needs, limit who can reach each copy, and keep a record you can show.
- What a tool does not do: decide which obligations apply to you. That is for your data protection officer and legal team; this page covers the engineering.
RelatedSaudi Data and Artificial Intelligence Authority (SDAIA)
What PDPL test data compliance covers: every copy, not only production
Most PDPL programmes start where the law is most visible: the customer portal, the consent text, the privacy notice, the production database. The copies made from that database get less attention, yet a copy taken for testing holds the same names, national ID and Iqama numbers, mobile numbers and account details as the original. Making the copy, storing it, giving a team access to it and sending part of it to a supplier are all actions a data protection law normally treats as processing.
Read more
SDAIA publishes the law and the regulations issued under it, and the current text is the reference, not a summary, so this guide quotes no article numbers, deadlines or penalties. Two points matter for non-production copies. First, the purpose the data was collected for rarely includes testing a new release, so using real records that way needs a decision someone can defend. Second, the law sets rules for transferring personal data outside the Kingdom, which matters as soon as a test environment, an analytics service or a vendor's team sits abroad.
For how the law maps to IT systems overall, read the PDPL guide for IT teams; for running test data as a practice, read test data management. This page stays with the copies.
Where copies of production data usually end up
Most organisations find more copies than they expected when they first list them. These are the usual places.
| Copy | Who usually has access | Typical risk | Control that fits |
|---|---|---|---|
| Development databases | Developers, often including contractors | Full production restores kept for months | Masked subset, refreshed by the pipeline |
| Test and UAT environments | Testers, business users, vendor testers | Wide access and shared accounts | Masked copy, named accounts, refresh schedule |
| Analytics and reporting extracts | Analysts, BI tools, sometimes cloud services | Columns copied that the report never uses | Only the columns needed; masking or aggregation for the rest |
| Training environments | New staff and trainers | Real customer records shown on screen | Synthetic or fully masked data |
| Vendor and outsourced teams | Third parties, possibly outside the Kingdom | Data leaving your control and possibly the Kingdom | Masked data only, a written agreement, the transfer question settled first |
| Backups and ad hoc exports | Whoever can reach the share or the laptop | Forgotten files with no owner | An inventory, an owner per copy, a deletion date |
Why non-production is the weak point
Production databases usually have the strongest controls in the estate: named access, monitoring, change approval. Non-production environments are built for speed. Access is wider, accounts are shared because that is quicker, and copies multiply because every team wants its own. None of this is careless; it is how delivery works. But the same customer record can then exist in one well-guarded place and five loosely guarded ones, and the loosely guarded ones are where an incident is most likely to start.
The fix is not to stop testing with realistic data; tests need real formats, relationships and edge cases. The fix is to produce that data in a way that no longer exposes the people in it.
Five practical controls for personal data in test environments
These controls work whichever tools you use. The last column says what Redgate's tooling contributes, according to Redgate's own documentation; the decisions in the second column stay with you.
| Control | What it means in practice | Evidence you can show | Where Redgate helps |
|---|---|---|---|
| Catalogue | A confirmed list of the tables and columns holding personal data, including free-text fields, Arabic and English name fields | The classification, dated and approved by the data owners | Redgate Test Data Manager finds and categorises data that looks like personally identifiable information; your data owners confirm it |
| Mask | Real values replaced before anyone connects, the same person masked the same way in every table | The masking rules per column, and a check that original values no longer appear | Deterministic masking that keeps referential integrity, so joins and tests still work |
| Subset | Each environment receives the slice of data its tests need, not a full copy | A subset definition per environment | Builds a smaller, related slice from a chosen starting table with filters |
| Restrict access | Named accounts per environment, vendor access approved and time-limited | An access list per environment and its last review | Provisioning through Redgate Clone gives each team its own copy; the access rules are yours |
| Keep records | Who refreshed what, when, with which rules, and when each copy is deleted | Pipeline run history, rules under version control, a deletion log | A command line for CI/CD pipelines, so refreshes run as recorded jobs rather than by hand |
The detail of each masking technique is on the data masking for test environments page. Where some users of a live or reporting database should see only part of a value, read about dynamic data masking; it hides values at read time and does not replace masking the copies.
Before a vendor or analytics team receives a copy
Third parties are where non-production data is most likely to leave your control. Answer these before the first file or connection:
- Does the task need real personal data at all? Most integration, performance and functional testing works on masked or synthetic data.
- Which columns does the vendor actually need? Send those, masked where possible, and nothing else.
- Where will the data be processed? If the answer is outside the Kingdom, the transfer question goes to your data protection officer before anything is sent.
- Is there a written agreement that covers purpose, security, return or deletion, and who the vendor may share the data with?
- Who on your side approved the access, and when does it end?
- How will you know the copy was deleted at the end of the work?
Bringing test data under control, step by step
-
List the copies.
Every non-production database, extract and export that holds personal data, with an owner and a purpose for each.
-
Classify with the data owners.
Automated discovery proposes the sensitive columns; the people who own the data confirm the list and add what discovery missed.
-
Decide what each environment needs.
Full masked copy, masked subset or synthetic data. Smaller copies refresh faster and expose less.
-
Mask during provisioning.
Rules run as the copy is created, before any developer, tester or vendor can connect.
-
Put refreshes into the pipeline.
A masked environment becomes a scheduled job with a record, not a favour from a DBA.
-
Retire the old copies.
Unmasked copies made before the new process are deleted, and the deletion is recorded.
Where Redgate fits, and where it does not
Interkey implements Redgate's tooling for database delivery. For test data, Redgate Test Data Manager covers the classify, mask, subset and provision steps above, with a command line for CI/CD pipelines alongside a graphical interface, on Windows and Linux. It is documented for mainstream relational engines; supported engines and features vary by version and edition, so yours are confirmed during scoping. Where schema changes already flow through Flyway, masked refreshes can sit in the same pipeline.
Read more
It does not fit in three cases. First, if you expect a tool to decide what the law requires of you: that judgement belongs to your data protection officer and legal team, and the tool applies the rules they approve. Second, if most of your data sits in non-relational platforms: the approach is agreed per platform, and we will say if the tooling is not a fit. Third, if you only need to hide a few columns from some users of one reporting database: your database platform may already offer a built-in option.
Data residency, support from Riyadh, and Interkey's part
Where test and analytics environments run matters as much as what is in them. A masked copy on a server in Riyadh and an unmasked extract in a cloud region abroad are very different positions under the law's rules on transfers. Before any copy is made, we settle with your security and data protection teams which environments sit where and which data may reach them. The observability data residency guide shows the same question for logs and traces.
Read more
Interkey's engineers work from Riyadh, write the classification and runbooks with your data owners in Arabic and English, and provide support after the first masked refresh. We start from your list of copies, not from a product list, and tell you plainly if your current scripts are enough.
Questions Saudi teams ask about PDPL and test data
Does PDPL apply to personal data in our test and development databases?
The law is about personal data, not about which server it sits on, so a copy of customer records in a test database is still personal data. Which obligations apply to your copies, and how, is for your data protection officer and legal team to confirm against the current text that SDAIA publishes. Masking reduces the number of places where real personal data lives.
Can a vendor outside Saudi Arabia test our system with production data?
That is a transfer of personal data outside the Kingdom, which the law sets rules for, so it goes to your data protection officer before anything is sent. Most vendor testing works on masked or synthetic data, which removes the question for the bulk of the work.
Is masked test data still personal data under PDPL?
It depends on how well it is masked. If enough original details remain, such as a rare job title, a small town and an exact date, a person can sometimes be re-identified by combining them. Good rules replace or generalise those combinations as well as the obvious identifiers, and a check after each refresh confirms that original values no longer appear.
Who at SDAIA oversees the Personal Data Protection Law, and where is the official text?
The Saudi Data and Artificial Intelligence Authority (SDAIA) oversees the law. The text and the regulations issued under it are published on SDAIA's website, and that is the version to read with your legal team. We do not quote article numbers on this page, because copying requirements from summaries is how wrong ones spread.
How long does it take to bring test data under control, and what drives the cost?
The duration depends on how many non-production copies exist, how many databases and engines are in scope, and how quickly data owners can confirm the classification, so we estimate it after listing the copies, not before. Cost follows the same scope plus Redgate licensing where it is used, quoted at Redgate's terms alongside Interkey's work.
Can Interkey review our test data practice in Arabic, with support in Riyadh?
Yes. Interkey's engineers work from Riyadh, run the review sessions, write the classification, masking rules and runbooks in Arabic or English, and stay on for support after the first masked refresh.
Next
Related pages
Next step
Book a PDPL test-data review
Tell us roughly how many non-production copies of customer data you have, how they are refreshed today, and whether any vendor or analytics team receives them. We will come back with a first step that shows where personal data sits outside production and what to do first.
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