Azure migration · field note
Saudi Data Residency and Azure: What Does PDPL Actually Require?
Choosing a Saudi region answers a location question. You still need to understand the data you collect, who can access it, and where every copy goes.
“We will host it in Saudi Arabia, so the data issue is solved.” It is an understandable shortcut. It also leaves several important questions unanswered.
Where are the backups? Does an external support tool receive customer details? Can a supplier download records? What happens when a customer asks for their information to be corrected or deleted?
Saudi Arabia East may help organisations meet a local hosting requirement. A PDPL assessment still needs to cover the way the business collects, uses, shares, protects, and keeps personal data.
01 / Define the question
Separate data location from data protection
Data residency concerns where data is stored. Data processing includes what happens to it: collection, use, disclosure, analysis, and other operations. A system can store its main database in one country while sending information elsewhere for another purpose.
The Personal Data Protection Law, or PDPL, deals with personal data and the responsibilities attached to processing it. An Azure resource location is one fact in that wider review.
Start by asking what the requirement actually says. Is it a law, a sector rule, a government data classification requirement, a signed contract, or a customer's preference? Those have different owners and may call for different controls.
Write the requirement in plain language and keep its source. “Saudi compliant” is too vague to design against or verify.
02 / The organisation's duties
What does PDPL cover beyond hosting?
SDAIA's official guidance describes personal data broadly: information that identifies an individual directly or indirectly. Names, contact details, identification numbers, financial information, and identifiable images can all matter to an application review.
The organisation deciding why and how that data is processed is the controller. A supplier processing it on the controller's behalf may be a processor. Identify those roles for the actual service arrangement.
- Purpose and lawful processing: why the data is needed and the applicable basis for using it.
- Transparency and rights: what people are told and how their requests are handled.
- Minimum necessary data: whether the system collects more than the purpose requires.
- Protection and access: who can use the information and how it is secured.
- Retention and disposal: when the information should be removed or handled under another applicable obligation.
Local hosting does not carry out those tasks for you. A database in Saudi Arabia can still have excessive permissions, unnecessary fields, or an unmanaged retention policy.
03 / Cross-border data
Does every copy have to stay inside Saudi Arabia?
Do not assume a single answer applies to every business and every kind of data. Saudi Arabia has a regulation for personal-data transfers outside the Kingdom. It sets out conditions and safeguards, including rules affecting onward transfers and risk assessment.
The existence of that framework does not make every transfer acceptable. The relevant team must assess the purpose, destination, parties, safeguards, and applicable requirements. Certain circumstances require a transfer risk assessment.
Also check whether sector rules, government requirements, data classifications, or contracts impose additional restrictions. The PDPL should not be used as a substitute for reviewing those obligations.
For Azure planning, the useful engineering task is to expose the transfer paths clearly. The privacy or legal owner can then determine which arrangements are permitted and what conditions must be met.
04 / Follow the information
Map every copy and access path
Start with one real user journey. A person submits a support request. Their details enter the application, appear in a log, are sent to an email service, and become part of a backup. Each step belongs in the review.
| Data or access path | What to establish |
|---|---|
| Production database and files | Content, region, permissions, encryption, and retention. |
| Backups and replicas | Primary and secondary locations, restore destination, and deletion rules. |
| Logs and monitoring | Personal fields recorded, receiving workspace, access, and retention. |
| Support and administrators | Who can access or export records, from where, and under which agreement. |
| External services | Data sent to email, analytics, payment, support, and AI providers. |
Record evidence rather than assumptions. A setting marked “geo-redundant” needs an identified secondary location. A supplier described as “global” needs a review of the relevant processing terms and configuration.
The backup and disaster recovery guide explains why those copies deserve their own check.
05 / Make requirements practical
Turn the agreed requirements into controls
Once the responsible owners agree the requirements, translate them into settings and operating procedures. Region restrictions, access roles, private connectivity, logging rules, and retention policies can all help, depending on the design.
Use deployment policies to detect or prevent unapproved regional resources where appropriate. Review exceptions for global services instead of applying a rule that silently breaks the application.
Reduce unnecessary personal data in logs. Give support staff the access they need for their role, and review export permissions. Store secrets through the chosen secure mechanism rather than passing production credentials around in deployment notes.
Test the controls. Try a deployment in a disallowed location, review a user-access removal, and follow a data-retention procedure through the application. A policy document and an effective control are different pieces of evidence.
06 / Prepare for review
Give the legal and privacy team something concrete
A useful review pack includes the data-flow map, purposes, categories of personal data, roles of the parties, processing locations, access model, retention settings, and relevant supplier agreements.
Add the proposed migration stages. During a phased move, data may follow a different route from the final design. Old backups and source copies may also remain after the customer-facing application has moved.
Put unresolved questions beside the architecture, with owners. For example: can a particular recovery copy remain in the existing region, and for how long? Does the support arrangement need to change? Which requirements apply to a new AI integration?
Engineers can demonstrate configuration and data flows. The accountable organisation must assess its legal duties and approve the compliance position. A technical readiness report should support that decision without presenting itself as a legal certification.
07 / Say exactly what you can show
Make a precise hosting claim
When discussing the design with customers, use statements your evidence supports. Describe the relevant production-data location, backup arrangements, access controls, and any approved exceptions.
Avoid expanding “our production database is hosted in Saudi Arabia” into “all information always remains in Saudi Arabia” unless you have verified every part of that broader statement.
Revisit the map when a new supplier, log destination, recovery method, or feature changes the data flow. Data-residency work continues after migration because the application continues to change.
Primary references
Sources and further reading
Questions teams ask
Frequently asked questions
Does PDPL require every business to store all data in Saudi Arabia?
That is too broad a statement. The PDPL and transfer regulation provide a framework for personal-data transfers outside the Kingdom, with conditions and safeguards. Sector rules, data classification, government requirements, and contracts may impose additional restrictions. Assess the specific workload.
Is an Azure workload PDPL compliant because it runs in Saudi Arabia?
No. The organisation still needs to address lawful processing, notices, data minimisation, access, retention, individual rights, security, and other applicable duties. Hosting location is one part of that assessment.
Should backups and application logs be included in a residency review?
Yes, where they contain personal data or other restricted information. Identify their locations, retention, replication destinations, access permissions, and deletion arrangements rather than reviewing only the main database.
Who should approve the final compliance position?
The accountable business owner, privacy or legal team, and relevant control owners should assess the evidence and applicable requirements. Engineers supply the architecture, configuration, and data-flow facts. An infrastructure checklist is not a legal certification.