The UAE Personal Data Protection Law — Federal Decree-Law No. 45 of 2021 — applies to anyone processing the personal data of people inside the UAE, regardless of where the company or its servers sit. For a website that means two obligations that fail independently: the documented one (lawful basis, notice, data subject rights) and the technical one (measures that actually keep the data from walking out).
Search for "UAE PDPL penalties" and you will find confident tables: AED 50,000 to 5 million in one article, up to AED 20 million in the next. The decree-law itself sets no amounts — it delegates administrative penalties to a Cabinet resolution. Any specific figure, including ones quoted by consultancies, should be checked against the current resolution and with counsel. We would rather tell you the number is unsettled than invent precision.
Who the law covers
The scope follows the data subject, not the infrastructure. You are in scope if you process personal data of individuals inside the UAE — as a controller (you decide why and how) or as a processor (you handle it on someone else's instructions).
| Situation | In scope? | Why |
|---|---|---|
| UAE company, servers abroad | Yes | Location of processing does not remove the obligation |
| Foreign company, UAE customers | Yes | Processing personal data of individuals inside the UAE |
| Entity established in DIFC or ADGM | Usually no | Those free zones have their own data protection regimes |
| Government entities and their data | Separate treatment | The federal law carves out specific categories |
The free-zone distinction matters more than it looks. A company registered in DIFC follows the DIFC Data Protection Law, not the federal PDPL. Building a programme against the wrong regime is a common and expensive way to be busy without being compliant.
What the law asks of a website
Strip away the sections that concern internal governance, and what remains visible on a website is a short list. Every item below is observable from the outside — which means a regulator, a competitor or a complainant can check it without your cooperation.
| Requirement | What it looks like when done | Common failure |
|---|---|---|
| Lawful basis for processing | Consent, or another basis the law recognises, identified per purpose | One blanket checkbox covering marketing, analytics and fulfilment at once |
| Privacy notice | Published, reachable from every page, describing real practice | A template naming purposes the company does not have and omitting the ones it does |
| Consent that can be withdrawn | Withdrawal as easy as giving it | Consent in one click, withdrawal only by emailing support |
| Data subject rights | A working route to access, correct, delete, object, port | A form that reaches nobody and a request that expires unanswered |
| Cross-border transfer basis | Documented basis for sending data outside the UAE | A CRM, analytics stack and support desk all hosted elsewhere, undocumented |
| Technical and organisational measures | Access control, encryption in transit, logging, vulnerability management | Confused with "we have a firewall" |
| Breach response | A named owner and a route to notify the Data Office | Notification drafted from scratch during the incident |
Where the technical requirement actually bites
The documented half is cheap to fix — a lawyer and a week. The technical half is where companies lose money, because it fails silently and surfaces only when data is already gone.
None of these appear in a document review. A company can hold a flawless privacy notice, a signed processor agreement and a data map, and still hand over its customer base to anyone who changes a number in a URL.
Breach response: decide who sends it before you need to
The obligation is to notify the UAE Data Office once a breach that risks data subjects is discovered, without undue delay, and to inform affected individuals where the risk warrants it. The practical failure is never the drafting — it is the hours lost deciding who owns the decision.
- Preserve first. The instinct to wipe and reinstall destroys the evidence needed to establish scope. Snapshot systems and logs before touching anything.
- Establish scope second. Which records were reachable, not just which you can prove were taken.
- Notify third, with what is known — under-reporting and correcting later reads worse than reporting an estimate honestly labelled as one.
Without retained logs you cannot establish what was reached, which means you cannot notify accurately, which means you are explaining to a regulator why your own account of the incident is a guess. Retention long enough to investigate is part of the technical measures the law asks for.
Checklist
- Confirm which regime binds you — federal PDPL, DIFC or ADGM.
- Map every form on the site to a purpose and a lawful basis. Separate marketing consent.
- Make withdrawal of consent as easy as giving it, and test that the route works.
- Publish a privacy notice that matches what the site actually does today, not the template.
- Document where data goes outside the UAE — analytics, CRM, support, hosting.
- Test the site externally: injection points, access to other users' records, exposed admin panels and backups, outdated components, forms posting over plain HTTP.
- Fix what is found, then re-test — an unverified fix is regularly a partial one.
- Name the person who notifies the Data Office, and write the template before the incident.
- Turn on logging with retention long enough to investigate.
- Repeat the technical check on a schedule. A single audit is a snapshot; the requirement is ongoing.