Data Protection in Saudi Arabia and the UAE: The PDPL Laws

Saudi Arabia and the UAE each have a personal data protection law. The site calls them the Saudi PDPL and the UAE PDPL, and both sit inside the wider family of MENA personal data protection laws. The details differ, and your legal team decides which one applies to each activity. The systems question is shared: where does personal data live, who can reach it, and how do you prove the answer?

What the Laws Ask of Your Systems

A privacy law is not only a policy document. It reaches the systems that hold customer, employee, learner, guest or tenant data. In practice, it asks a company to answer several questions with evidence.

• Where is personal data stored and processed, and in which country?

• Which systems and people can read or change it?

• Is it encrypted in transit and at rest?

• How long is it kept, and does deletion reach copies and backups?

• Which third parties receive it, and under what rules?

• What records show how the data is protected?

The answer cannot come from one team. Finance knows the billing data, HR knows the employee data, operations knows the customer records, and IT knows the infrastructure. A data map that joins those views is the first control, because a company cannot protect data it cannot locate.

Data Residency Is a Design Decision

Both laws make location a live question. A regulator can ask where a record is stored and processed, and a supplier or a cloud region can move that answer without anyone noticing. The design has to make the location visible and keep it inside the rules that apply.

That may mean a regional cloud, a private cloud, an on-premises platform or a mix. It also means the less visible paths: backups, logs, support access, analytics copies and AI services. Data often leaves a region through one of those paths rather than through the main application.

The same discipline applies to AI. A model that sends personal data to a public service abroad creates a transfer the company may not be able to justify. Permission-aware retrieval, private models and regional hosting keep the decision inside the company's control.

Where Systems Fail

• Customer data sits in a CRM, a billing system, a data warehouse and a spreadsheet, with no shared map.

• A cloud service replicates backups to another region by default.

• Access is broad because roles were copied from an old system.

• A deleted record survives in a backup or an analytics copy.

• A vendor receives a data extract with no written limit on its use.

• The evidence for an audit is assembled from screenshots.

Each of these is fixable, but only after the data is mapped. Encryption, least-privilege access, retention rules and audit logs are technical controls. The map is what tells you where to apply them.

What to Do First

Start with one business process, not the whole company. Choose a process that handles sensitive data and crosses several systems, such as customer onboarding or employee records. List every system in the flow, the data each one holds, the country it runs in and the people who can reach it.

Then fix the gaps that carry the most risk. Limit access by role and log it. Encrypt data in transit and at rest. Set a retention period for each kind of data and test that deletion reaches copies and backups. Write down the decisions, because a record of how data is protected is part of the evidence an auditor or regulator will ask for.

Repeat for the next process. A series of small, documented maps is more useful than one large diagram that nobody updates.

The authorities publish current guidance and any timetable for the rules. Check the version that applies to your business with your legal team. This guide describes what the laws ask of systems. It is not legal advice.

How XSIS Helps

XSIS maps data flows, designs residency and access controls, and builds the records that show how personal data is protected. We work with your legal and compliance teams, who decide how the laws apply. We do not give legal advice.