Data Protection
Data Breach Notification in the UAE: DIFC and ADGM
· 6 min read · By Aureus Worldwide
Data breach notification is the duty to tell the regulator, and sometimes the affected individuals, when personal data has been compromised. In the UAE, three separate regimes impose breach-notification obligations: the Federal PDPL, the DIFC Data Protection Law 2020 and the ADGM Data Protection Regulations 2021. The differences between them matter, because the clock can start the moment you become aware. This guide explains what counts as a breach, who you must notify and how quickly, and how to prepare so a breach does not turn into a crisis.
What counts as a personal data breach
A personal data breach is a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It is broader than a "hack" and covers three failure types:
- Confidentiality breach, unauthorised or accidental disclosure of, or access to, data (a misdirected email, a stolen laptop, a database left exposed)
- Integrity breach, unauthorised or accidental alteration of data
- Availability breach, accidental or unauthorised loss of access to, or destruction of, data (ransomware, a failed backup, deletion in error)
Recognising all three is important. Businesses often think only of external attacks, but a large share of notifiable breaches are internal and mundane, an email to the wrong recipient, a lost device, or a misconfigured system.
The two questions after every breach
When a breach occurs, everything turns on two questions:
- Do we notify the regulator?
- Do we notify the affected individuals?
Both answers depend on risk. Notification to the regulator is generally required where the breach is likely to pose a risk to individuals; notification to individuals is required where that risk is high. This is why you cannot answer either question without first assessing the breach, and why preparation is everything.
How the UAE regimes compare
The three UAE frameworks share the same architecture but differ in the detail, especially on timing.
| Regime | Regulator | Notify the regulator | Notify individuals |
|---|---|---|---|
| DIFC (DPL 2020) | Commissioner of Data Protection | As soon as practicable in the circumstances where the breach compromises a data subject's confidentiality, security or privacy | Where there is a high risk to the individual |
| ADGM (DPR 2021) | ADGM Commissioner of Data Protection | Without undue delay and, where feasible, within 72 hours of becoming aware, unless unlikely to result in a risk | Where there is a high risk, without undue delay |
| Federal PDPL | UAE Data Office | Upon becoming aware, where the breach would prejudice the privacy, confidentiality or security of the data (detail set by Executive Regulations) | Where the breach prejudices the individual's privacy or data |
Timeframes and thresholds continue to be refined, particularly under the PDPL's Executive Regulations, so confirm the current position with the relevant authority before you rely on a specific deadline. What is consistent across all three is that the obligation is triggered when you become aware, and that unreasonable delay is itself a compliance failure.
Assessing whether a breach is notifiable
A calm, structured risk assessment sits at the centre of breach response. Weigh factors such as:
- The nature and sensitivity of the data involved
- The volume of records and number of individuals affected
- How easily individuals can be identified from the data
- The severity of consequences, from inconvenience to fraud, discrimination or physical harm
- Whether the data was encrypted or otherwise unintelligible to an unauthorised party
- Any mitigating steps already taken to contain the incident
Crucially, document the assessment even where you conclude that notification is not required. A recorded, reasoned decision not to notify is defensible; a silent one is not.
What a breach notification must contain
Regulator notifications typically require:
- A description of the nature of the breach, including the categories and approximate number of data subjects and records affected
- The name and contact details of the DPO or other contact point
- The likely consequences of the breach
- The measures taken or proposed to address it and mitigate harm
If you cannot provide all the detail at once, most regimes allow you to notify in phases as the picture becomes clearer, but you should not sit on an initial notification while you gather every fact.
When the breach involves a vendor or processor
Many breaches happen not inside your own systems but at a processor you rely on, a cloud host, a payroll bureau or a marketing platform. As the controller, you generally remain accountable to the regulator and to affected individuals even though the incident occurred at the vendor. That is why processor contracts must require the vendor to notify you without undue delay after becoming aware of a breach, and to give you enough detail to meet your own reporting obligations. When you assess a vendor, ask how it detects and escalates incidents, how quickly it will tell you, and who its own sub-processors are. A breach discovered late because a supplier sat on it is still your problem to report, so build the notification chain into the contract before anything goes wrong. Your Record of Processing Activities and vendor register are what let you work out, quickly, which processor holds the data involved.
Build your incident response before you need it
The single biggest predictor of a good breach outcome is whether you prepared in advance. Put the following in place now, not during an incident:
- Detect, monitoring and a clear internal route for staff to report suspected breaches immediately.
- Contain, predefined steps to isolate affected systems and stop the bleeding.
- Assess, a documented risk-assessment method and the people responsible for running it.
- Notify, templates and the correct channels for each regulator, plus draft wording for individuals.
- Remediate, fix the root cause, not just the symptom.
- Learn, a post-incident review that feeds back into your controls.
Keep a breach register recording every incident, notifiable or not, and rehearse the plan so roles are second nature. You can only assess a breach quickly if you already know what data each system holds, which is exactly why a current Record of Processing Activities is indispensable. Breach readiness is a core line item on any data protection compliance checklist.
The 72-hour clock and why preparation wins
Where a short deadline applies, most visibly the ADGM's "where feasible, within 72 hours", the danger is spending the window in confusion rather than action. Organisations that have assigned roles, pre-drafted their notification templates and know their regulator's reporting channel handle the clock calmly. Those improvising in the moment often either miss the deadline or send a panicked, inaccurate notification. The measures identified in a DPIA, encryption, access controls, minimisation, are also what most reduce the severity of a breach when one occurs.
How Aureus Worldwide can help
Aureus Worldwide is a Dubai-based accounting and compliance-advisory firm, not a law firm. We help UAE businesses get breach-ready in practical terms: building an incident-response plan and breach register, defining the risk-assessment method, preparing notification templates, and rehearsing the process, all coordinated with your legal counsel and appointed DPO. This forms part of the governance support delivered through our compliance officers and AML and compliance advisory services. To pressure-test your breach response before you need it, contact our team.
Frequently asked questions
How quickly must I report a data breach in the UAE?
It depends on the regime. Under the DIFC Data Protection Law 2020 a notifiable breach must be reported to the Commissioner as soon as practicable in the circumstances. The ADGM Data Protection Regulations 2021 require notification without undue delay and, where feasible, within 72 hours of becoming aware. The Federal PDPL requires notification upon becoming aware, with specifics set by its Executive Regulations. Confirm the current timeframe with the relevant authority.
Do I always have to tell the affected individuals?
No. You generally notify individuals only where the breach is likely to result in a high risk to them. If the compromised data was, for example, strongly encrypted and the key was not exposed, individual notification may not be required, but you should document that assessment carefully.
What if I am not sure whether a breach is notifiable?
Assess it and record your reasoning. Record every breach in an internal register regardless of whether it is notifiable, and apply the risk threshold to decide on regulator and individual notification. Where the position is genuinely unclear, err toward seeking advice quickly, because the reporting window is short.
Do minor incidents need to be reported?
Not every incident meets the threshold for regulator notification, but you should still log all breaches internally. Only those likely to pose a risk to individuals are notified to the regulator, and only high-risk breaches are notified to the affected individuals. The internal register is what lets you show you assessed each one.