GDPR and the UAE PDPL: what your software has to handle

Companies in the Gulf increasingly sell to Europe, and companies in Europe increasingly build in the Gulf. Both find themselves subject to two privacy regimes at once: the EU's General Data Protection Regulation and the UAE's federal Personal Data Protection Law, with separate rules again in the DIFC and ADGM free zones. The details differ; the practical demands on software are strikingly similar. Whatever your lawyers conclude about which law applies, the systems you build will need the capabilities below — and they are far cheaper to design in than to retrofit.

This article describes engineering requirements, not legal obligations; take the legal question to counsel.

Lawful basis and consent capture

Systems must record why each item of personal data is processed — consent, a contract, a legitimate interest — and, where consent is the basis, capture it explicitly, granularly, and with a timestamp. Pre-ticked boxes and bundled consent do not count. Your software needs a consent record, per purpose, that can be shown later.

Data-subject rights as features

Individuals can ask what you hold, ask for it to be corrected, ask for it to be deleted, ask for a copy in a portable format, and object to certain processing. Each of these is a feature: an export that assembles everything about a person across systems, a deletion routine that reaches backups and third parties within policy, a correction path with an audit trail. Companies that handle these by hand discover the cost at the first request.

Data minimisation

Collect what the purpose needs and nothing more. In software terms: forms that do not ask for fields you will never use, integrations that request only the scopes they need, analytics that do not sweep up identifiers by default. Minimisation is mostly a design discipline, and it reduces breach exposure as a side effect.

Retention and deletion

Personal data should be kept only as long as its purpose requires. Systems need retention rules per data category and a mechanism that actually enforces them — scheduled deletion or anonymisation, with logging. "We keep everything forever" is a liability, not a feature.

Breach detection and logging

Both regimes expect breaches to be detected and reported within tight windows. That is only possible if systems log access to personal data, alert on anomalies, and can reconstruct what was affected. Audit logs are not optional in any system holding personal data.

Cross-border transfers

Data moving between the EU, the UAE, and elsewhere must be covered by an appropriate mechanism, and your architecture should make it possible to say where data lives and where it flows. Choose hosting regions deliberately, document data flows, and design so that a region can be changed without rebuilding the system — a hosting decision that runs through our cloud and DevOps work.

Processors and vendors

Every third-party service that touches personal data — hosting, email delivery, analytics, support tools — is a processor that needs a contract and a record. Your system inventory should list them and what each receives. The architecture should avoid sending personal data to vendors that do not need it.

Security by design

Encryption in transit and at rest, role-based access, least privilege, secure defaults, and regular review. None of this is exotic; all of it must be present, and it must be demonstrable, because demonstrating it is what both regimes ultimately ask for. In sectors such as healthcare, where data is especially sensitive, these controls are the foundation of the product, not an add-on.

Designing it in

The practical approach is to treat privacy as a set of requirements at scoping time: a data inventory, a consent model, rights workflows, retention rules, logging, and hosting decisions, all written into the proposal alongside the features. It costs little when planned and a great deal when discovered. It is also, increasingly, what enterprise buyers ask to see before they sign.

Frequently asked questions

Does the UAE PDPL apply to my company? That is a question for counsel; it depends on where you are established, whom you serve, and which free zone rules may apply. The engineering requirements above are worth building regardless.

Is a privacy policy enough? No. A policy describes what you do; the systems must be able to do it. Regulators and customers check both.

We already have data everywhere — where do we start? With an inventory. You cannot protect, export, or delete what you cannot find. Then consent and retention, which have the broadest effect.

This article is general guidance for engineering teams, not legal advice. If you are building or modernising a system that handles personal data, tell us what it holds and we will show you how the requirements shape the scope.