Gulf Data Residency: UAE PDPL and Saudi PDPL for Vendors

Every Gulf enterprise deal reaches the same slide eventually. Where does the data live, who can reach it, and what happens to it when we stop working together.

In our experience the question rarely comes from the IT team. It comes from legal, or from a board member who read something about fines, and it arrives late, after scope is agreed.

The answer is usually simpler than people fear, and the architecture it demands is narrower than what most vendors propose.

Neither PDPL bans ordinary commercial data from leaving the country

Start with the misconception, because it costs the most money.

Neither the UAE Personal Data Protection Law nor the Saudi Personal Data Protection Law imposes a blanket localisation mandate on ordinary commercial data.

There is no general rule saying a trading company's sales ledger, or a contracting firm's HR records, must physically remain inside the country.

What both laws do is regulate the conditions under which data leaves. That is a different problem with a different solution.

A localisation mandate is answered with a data centre.

A transfer condition is answered with a lawful basis, a written safeguard, a documented assessment and a set of access controls.

The second is cheaper and, on most Gulf projects we have delivered, correct.

We have watched buyers spend months specifying in-country infrastructure for systems that never needed it, then run short of budget for the control that actually mattered: who on the vendor side can open a production database.

Classify first. Then build.

Two things change the picture: sector rules and sensitive categories, and UAE health data is the clearest example of both.

UAE vs Saudi Arabia: the comparison in one place

Blanket localisation mandate for ordinary commercial data

UAE: No. Cross-border transfer is permitted subject to conditions.

Saudi Arabia: No. Transfer outside the Kingdom is permitted subject to conditions.

Transfer conditions

UAE: Article 22 allows transfer where the destination has personal data protection legislation with essential protections and a supervisory mechanism, or where the UAE has acceded to a bilateral or multilateral agreement. Article 23 covers the absence of that finding.

Saudi Arabia: A permitted purpose, no prejudice to national security or the vital interests of the Kingdom, an adequate level of protection in the destination, and data minimisation.

Accepted safeguards where adequacy is absent

UAE: A contract or agreement obliging the receiving party to apply the provisions, measures, controls and requirements of the law; express consent of the data subject; necessity for a contract with the data subject; legal claims; public interest.

Saudi Arabia: Saudi standard contractual clauses, binding common rules, or a certificate of accreditation, supported by a documented transfer risk assessment.

Adequacy finding for India

UAE: No published adequacy determination. The Implementing Regulations remain outstanding.

Saudi Arabia: No. SDAIA has not published an adequacy list, so India has no adequacy finding.

Penalties

UAE: No federal fine schedule published, because the Implementing Regulations have not been issued. Health data rules are separately enforceable.

Saudi Arabia: Up to SAR 3 million and up to two years for disclosing sensitive data with intent to harm, up to SAR 5 million otherwise, doubled for repeat offences.

UAE data residency requirements: what Articles 22 and 23 actually say

The UAE PDPL, Federal Decree-Law No. 45 of 2021, handles cross-border transfer in two articles.

Article 22 covers transfer to a destination that already offers adequate protection: either the destination has its own personal data protection legislation carrying the essential protections and a supervisory mechanism, or the UAE has acceded to a bilateral or multilateral agreement with that country.

Article 23 covers everything else, which is where an Indian software partner usually sits.

It permits transfer in the absence of an adequacy finding where one of several conditions is met.

The one that matters commercially is a contract or agreement that obliges the party in the receiving country to apply the provisions, measures, controls and requirements set out in the law itself.

The others are express consent of the data subject, necessity for the performance of a contract with the data subject, establishing or defending claims before judicial authorities, and protection of the public interest.

Read that carefully, because it is the whole game.

Article 23 does not ask you to move your servers. It asks you to bind your vendor in writing to the UAE standard, and to mean it.

One caveat before you plan around this.

The Implementing Regulations under the UAE PDPL have still not been issued, and the Data Office is not yet fully operational, with the Telecommunications and Digital Government Regulatory Authority acting as the practical point of contact.

Chambers reported that position in its 2026 UAE guide.

The obligations are live. The detailed mechanics are not published.

In that gap, write contract terms that would satisfy a strict reading rather than the loosest one.

The UAE exception that does bite: health data under Federal Law No. 2 of 2019

Health data is the genuine localisation rule in the UAE, and it is strict.

Federal Law No. 2 of 2019 on the use of information and communication technology in health fields provides that health data related to health services provided in the UAE may not be stored, processed, generated or transferred outside the UAE.

Latham and Watkins summarised the position when the law was published: offshore storage or transfer is permitted only where approved by a decision of the health authority or the Minister.

Ministerial Resolution No. 51 of 2021 later opened a defined set of exceptions, analysed by Hogan Lovells.

They include treatment delivered abroad, samples sent to overseas laboratories, approved scientific research, claims handling for UAE licensed insurers, data required by UAE state entities, simple monitoring data from wearables and medical devices, pharmacovigilance, certain non-confidential facility approval data, telemedicine, and transfers at the patient's own formal request.

Most carry conditions: written patient consent, encryption to the highest standard, notification of the specific recipient, transfer of the minimum necessary data, and a copy retained inside the UAE.

Notice what this means for vendor selection.

A hospital information system, a clinic ERP, a laboratory platform or a claims module for a UAE provider is a different architecture conversation from a trading company system.

An offshore partner who can only host in India is not eligible for that work. We host in region on request, so we are.

Do not let anyone blur the two conversations.

If you run a healthcare arm and a general trading arm, they are separate designs, separate hosting decisions and separate contract schedules.

Our clinical and hospital delivery work sits on our healthcare page, and the UAE hosting position sits alongside our UAE ERP practice.

Saudi Arabia has been fully enforceable since 14 September 2024

The Saudi PDPL came into force on 14 September 2023 with a one year grace period.

That period ended on 14 September 2024, and the law has been fully enforceable since.

The regulator is the Saudi Data and AI Authority, SDAIA.

CMS marked the one year anniversary by noting that SDAIA has been responding to data subject complaints and publishing guidance, including approved standard contractual clauses, rather than waiting quietly.

The transfer rules sit in the Regulation on Personal Data Transfer Outside the Kingdom, issued in August 2024 and announced by SDAIA on 1 September 2024.

The structure has two parts.

First, a permitted purpose.

The transfer has to serve one of a defined set of aims, including performing an international obligation, serving the interests of the Kingdom, meeting an obligation owed to the data subject, or carrying out central operations, providing a service or conducting scientific research.

Second, conditions on top.

The transfer must not prejudice national security or the vital interests of the Kingdom.

The destination must offer an adequate level of protection.

And the transfer must respect data minimisation, meaning you send what the purpose requires and no more.

The regulation also deals with onward transfers by the recipient, which is the clause most vendors forget.

If your Indian partner passes data to a monitoring tool, a support desk product or a sub-contractor, that is an onward transfer and it belongs in scope.

What the Saudi rules mean in practice for an Indian vendor

This is the part that decides your contract.

SDAIA has not published an adequacy list.

No adequacy list means India has no adequacy finding, and you cannot plan on one appearing before your project goes live.

So plan for safeguards.

The regulation provides three:

Saudi standard contractual clauses — published in modular form for different relationship types such as controller to processor.

Binding common rules — for transfers inside a corporate group.

Certificate of accreditation.

For an Indian vendor serving a Saudi customer, the working assumption should be Saudi SCCs in the controller-to-processor form, signed as a schedule to the master agreement.

On top of the safeguard, run a transfer risk assessment and keep the document.

SDAIA issued risk assessment guidelines in February 2025 and published a supporting tool on the National Data Governance Platform, announced in March 2025.

Clyde and Co pointed out that the guidelines are not themselves legally binding, which some readers treat as permission to skip the exercise.

That is the wrong conclusion.

They tell you what the regulator expects to see, and an assessment you cannot produce on request is an assessment you did not do.

The sequence we follow on Saudi engagements:

Classify the data → Fix the hosting region → Sign the Saudi SCCs → Complete and file the transfer risk assessment → Restrict and log the access path from India.

In that order.

Our Kingdom delivery work is described on our Saudi ERP page.

Penalties, so you can size the risk properly

Saudi penalties are specific enough to quote in a board paper.

Disclosing or publishing sensitive data with intent to harm the data subject carries imprisonment of up to two years and a fine of up to SAR 3 million.

Other violations of the law and its regulations carry a fine of up to SAR 5 million.

Both can be doubled for repeat offences.

A&O Shearman notes that the review committees can also issue warnings, so not every finding ends at the maximum.

The UAE side is less quotable, for the reason given earlier.

The Implementing Regulations are still outstanding, so there is no published federal fine schedule to cite.

Do not build a business case on the absence of a number.

The health data rules are already enforceable through the health authorities, and the PDPL obligations exist whether or not the mechanics are published.

In practice the commercial risk arrives before any regulator does.

It arrives as a failed vendor security review, a stalled procurement, or an enterprise customer of your customer asking for evidence you cannot produce.

What to put in the contract

You do not need a bespoke agreement for this.

You need eight things written down, and honest answers to each.

1. Named hosting region and named owner of the cloud account

Why it matters: Residency becomes a contractual fact instead of a preference, and fixes where production data physically sits.

Weak answer: “We use a global cloud, so it is covered.”

2. A complete sub-processor list, with notice before it changes

Why it matters: Onward transfer is regulated. A list naming only clouds is incomplete if a monitoring tool sees production data.

Weak answer: “Just AWS.”

3. Named individuals with production access, with logging and periodic review

Why it matters: Regulators and auditors ask who can see the data, not who could in theory.

Weak answer: “Only authorised personnel.”

4. Breach notification timing in hours, and to whom

Why it matters: Your own notification duty starts when you learn of it, so the vendor clock has to be shorter than yours.

Weak answer: “We will inform you promptly.”

5. No production personal data in development or test environments

Why it matters: Most avoidable exposure happens in non-production copies handled by people who never touch production.

Weak answer: “We mask it where possible.”

6. Deletion and return on exit: format, deadline, written confirmation

Why it matters: Exit is where residency promises quietly fail.

Weak answer: “We will hand over the database.”

7. Audit rights, plus the evidence you can request without calling an audit

Why it matters: An audit right you never use is worth less than a quarterly access log you actually read.

Weak answer: “You may audit us once a year.”

8. The security standard you are actually being held to, in writing

Why it matters: Certification claims are checkable. Aspirations are not.

Weak answer: “We are ISO compliant.”

On that last row, our own position, stated plainly.

We do not hold ISO 27001.

Implementation is underway, an auditor has been appointed, and certification is targeted for Q1 2027, January to March.

We do not hold ISO 9001 either; that is in progress.

We are not CERT-In empanelled.

Where a client needs a CERT-In audit, the client commissions the empanelled auditor, we build to that auditor's requirements and we implement every finding.

If a vendor tells you they are “ISO compliant” without a certificate number, ask for the certificate.

We publish our hosting, sub-processor, access and exit positions on our trust page so a buyer can check them before a call rather than during one.

The architecture we actually deploy

This is not a hypothetical reference design. It is what we run.

Production hosts in region, in the country the regulator or the client requires: the UAE, Saudi Arabia, India or elsewhere.

We deploy on Amazon Web Services, Microsoft Azure or Google Cloud Platform, with the region chosen to meet the client's requirement.

The environment is provisioned either on the client's own cloud account or on one we set up, with infrastructure billed to the client at cost.

Where a client prefers their own servers, we deploy on-premise and hold no client production data ourselves.

We do not push one hosting model on everyone, which is how UAE data residency requirements and Saudi transfer conditions get answered without a rebuild.

Access from India is the controlled part.

Developers work from Pune.

Production access is restricted to named people, granted for a stated purpose, and logged.

That single link is what your transfer risk assessment describes, and it is the thing to keep narrow.

Development and test environments carry no personal data.

Not masked, not partly redacted, none.

Synthetic and structurally realistic data is enough to build and test an ERP, and it removes a whole category of argument.

Sub-processors, stated in full: Amazon Web Services, Microsoft Azure, Google Cloud Platform, and client owned on-premise infrastructure where preferred, plus error and performance monitoring, analytics and product telemetry, and helpdesk tooling.

Region is selected per client requirement.

We list the tooling categories because a sub-processor list naming only three clouds is not a complete list.

[Diagram: reference architecture showing In Region Production Hosting connected by a single controlled and logged link to the Offshore Development Team, with a separate development environment holding no personal data.]

We deliver for clients across the Gulf, in the United Arab Emirates, Saudi Arabia and Bahrain, under the hosting and access rules described here.

Regional delivery detail sits on our Gulf hub.

Accucia's view

We will talk you out of hosting you do not need, and it costs us.

The honest position, after eight years and more than 730 projects: most Gulf commercial systems do not need in-country hosting to be lawful.

If you run a distribution business, a contracting firm or a manufacturing operation, the classification exercise usually ends at transfer conditions rather than localisation.

Saying so shrinks the deal.

In-region infrastructure is billed to you at cost, so we earn nothing by talking you into it, and a smaller footprint is less for us to manage.

We say it anyway, because a residency spec nobody can justify is the first thing to break under a real audit.

The other side of the same position.

If you are a UAE healthcare provider and you want India-only hosting to save money, we will not do it.

Federal Law No. 2 of 2019 does not bend for a budget, and neither will we.

That has ended conversations.

We are also not the right partner if you need a vendor with a Dubai office, a local trade licence and staff on the ground in the Emirates.

We have none of those.

We are an Indian company in Pune, founded in 2018, delivering to the Gulf from India with in-region hosting.

That is a real limitation and you should weigh it.

If you want local presence alongside offshore delivery, a local implementation partner is the better structure, and we work that way.

One last thing.

Ask every shortlisted vendor for their sub-processor list before you sign, not after.

The answer tells you more about their data handling than any certificate.

Frequently Asked Questions

Does UAE law require personal data to be stored inside the UAE?

No, not for ordinary commercial data.

Federal Decree-Law No. 45 of 2021 permits cross-border transfer where the destination offers adequate protection, or where a condition in Article 23 is met, such as a contract binding the receiving party to the protections set out in the law.

What is UAE PDPL Article 23?

Article 23 of Federal Decree-Law No. 45 of 2021 covers transfer of personal data to countries without an adequate protection finding.

It permits transfer under a contract obliging the receiving party to apply the law's requirements, with express consent, for performance of a contract with the data subject, for judicial claims, or to protect the public interest.

Do UAE data residency requirements treat health data differently?

Yes, and this is the exception that bites.

Federal Law No. 2 of 2019 provides that health data related to health services provided in the UAE may not be stored, processed, generated or transferred outside the UAE, unless approved by a decision of the health authority or the Minister.

Can health data ever leave the UAE?

Yes, within defined exceptions.

Ministerial Resolution No. 51 of 2021 permits specific cases including overseas treatment, foreign laboratory testing, approved research, insurance claims for UAE licensed insurers, telemedicine and formal patient requests.

Most carry conditions such as written patient consent, encryption, minimum necessary data and a copy kept inside the UAE.

Is the Saudi PDPL fully enforceable?

Yes.

The Saudi Personal Data Protection Law came into force on 14 September 2023 with a one year grace period.

That period ended on 14 September 2024 and the law has been fully enforceable since.

The Saudi Data and AI Authority, SDAIA, is the regulator.

What does the SDAIA transfer regulation require?

The Regulation on Personal Data Transfer Outside the Kingdom requires a permitted purpose, such as serving the interests of the Kingdom or carrying out central operations.

On top of that, the transfer must not prejudice national security or vital Saudi interests, the destination must offer adequate protection, and data minimisation applies.

Does India have an adequacy finding from SDAIA?

No.

SDAIA has not published an adequacy list, so no country including India currently holds a Saudi adequacy finding.

Until a list is published, transfers to India should rely on appropriate safeguards such as Saudi standard contractual clauses, supported by a documented transfer risk assessment.

What safeguards should an Indian vendor use for Saudi personal data?

Saudi standard contractual clauses in the controller-to-processor form are the practical default, signed as a schedule to the master agreement.

The regulation also allows binding common rules for transfers within a corporate group, and a certificate of accreditation.

Pair whichever you use with a written transfer risk assessment.

What is a transfer risk assessment under the Saudi PDPL?

It is a documented evaluation completed before data leaves the Kingdom, covering the purpose, the scope of processing, the safeguards in place, the adequacy of the recipient's protections and compliance with data minimisation.

SDAIA issued guidelines in February 2025 and a supporting tool on the National Data Governance Platform.

What are the penalties under the Saudi PDPL?

Disclosing or publishing sensitive data with intent to harm the data subject carries imprisonment of up to two years and a fine of up to SAR 3 million.

Other violations carry fines of up to SAR 5 million.

Both can be doubled for repeat offences.

Where does Accucia host client production data?

In the region the client or the regulator requires.

We deploy on Amazon Web Services, Microsoft Azure or Google Cloud Platform with the region chosen to meet the requirement, on the client's own account or one we set up, with infrastructure billed to the client at cost.

On-premise deployment is available.

Is Accucia ISO 27001 certified?

No.

ISO 27001 implementation is underway, an auditor has been appointed, and certification is targeted for Q1 2027, January to March.

ISO 9001 is also in progress and not yet held.

We are not CERT-In empanelled.

Where a CERT-In audit is required, the client commissions the empanelled auditor and we implement every finding.