UAE PDPL and your inbox: what compliance actually requires

Federal Decree-Law No. 45 of 2021 — the UAE Personal Data Protection Law, or PDPL — is the first comprehensive federal data protection framework in the Emirates. If you are evaluating any tool that touches your company email, it is the document your legal team will point at. This is a practical read of what it means in that specific context.

This is not legal advice. It is the shape of the questions worth asking, written by people who had to answer them while building an email product.

Why email is the hard case

Corporate email is the densest concentration of personal data most companies hold. A single inbox typically contains client names and contact details, passport and Emirates ID scans, salary and banking information, health details in HR threads, and commercially sensitive material belonging to third parties who never agreed to your vendor choices.

That last point is the one teams miss. When you connect an inbox to a third-party tool, you are making a processing decision on behalf of everyone who has ever emailed you.

The four obligations that bite

1. Lawful basis and consent

The PDPL requires a lawful basis for processing, with consent as the default route and a set of narrower exceptions. For an email tool, the practical test is whether the user granted a specific, informed, revocable permission — not whether they clicked through a general terms page. OAuth scopes are useful here precisely because they are specific and revocable at the source.

2. Data minimisation

You may process only what is necessary for the stated purpose. If a tool asks for full read and write access to extract task summaries, the scope exceeds the purpose. Read-only access is the correct ask; anything broader should be justified explicitly.

3. Cross-border transfer

Transferring personal data outside the UAE requires either an adequacy finding for the destination, or appropriate safeguards, or a specific exception. Any AI feature in your stack raises this question immediately, because inference usually happens somewhere else. The answer is not automatically "no" — but you need to know what leaves the country, in what form, and under what contract.

4. Data subject rights

Access, correction, erasure, restriction of processing, and portability all apply. In an email context the operative question is simple: when a user asks you to delete everything, can you actually do it, and how long does it take?

Questions to put to any vendor

1. 1What exactly is transmitted off my device or out of my tenancy — full message bodies, headers, or derived summaries?
2. 2Where is it processed, and which entity is the processor of record?
3. 3What is retained after processing, and for how long?
4. 4Are my credentials ever stored, or is access token-based and revocable at the identity provider?
5. 5Is my data used to train models? Get this in writing, not in a blog post.
6. 6What is the deletion path, and is it self-service or a support ticket?

If a vendor cannot answer question one in a single sentence, the remaining five will not be reassuring.

The architecture that makes this easy

Compliance gets dramatically simpler when the architecture removes the question rather than documenting an answer to it. Three design choices do most of the work:

• Token-based access via OAuth, so no credential is ever held by the vendor and revocation happens at Google or Microsoft, not through a support request.
• Local processing of message content, so raw email never becomes a server-side asset that needs a retention policy.
• Anonymised summaries as the only payload sent for AI classification, which keeps identifiable content out of the cross-border question entirely.

This is the model Taskify was built on, and it was a compliance decision before it was a product decision. It is also why our answer to "what do you store?" is short: an OAuth token on your device, and account metadata on ours.

Free zones are a separate question

If you operate in the DIFC or ADGM, those free zones have their own data protection regimes that sit alongside the federal PDPL and are, in several respects, stricter and closer to GDPR. Do not assume federal compliance settles the matter — check which regime governs your entity before signing anything.