Register processing operations with the Commissioner and maintain a written data protection policy
Severity HighArt. 14(5)(7)(8)、Art. 15
Article 14(7) requires controllers and processors to register with the Commissioner by filing a notification of processing operations and to keep it current through amended notifications; Article 14(8) puts the notification on a publicly available register and attaches a prescribed fee. Article 14(5) requires a written data protection policy proportionate to the extent and type of processing and consistent with the Law. Article 15 requires controllers and processors each to maintain a written record of processing activities, including categories of recipients, third countries and international organisations, documentation of safeguards for Article 27 transfers, erasure time limits by category, and a general description of technical and organisational security measures.
- Applies when
- Every controller and processor incorporated in the DIFC or processing personal data in the DIFC.
- Evidence to retain
- · Commissioner registration confirmation and the latest amended notification
- · Written data protection policy with version history and approval trail
- · Record of processing activities covering the Article 15(1) fields
- · Documentation of Article 27 transfer safeguards and its filing index
Estimated first-time effort: 3–8 person-days (estimate, not a commitment)
DPO for High Risk Processing Activities, or documented allocation of responsibility
Severity HighArt. 16、Art. 17、Art. 18
Article 16(2)(b) requires a DPO where a controller or processor performs High Risk Processing Activities on a systematic or regular basis (DIFC Bodies must also appoint one). An entity that is not required to appoint a DPO must, under Article 16(4), clearly allocate responsibility for data protection oversight and compliance within the organisation and be able to give the Commissioner the details of the responsible persons on request. The DPO may be a member of staff, a group employee, or a third party under a service contract; a group may share one DPO if easily accessible from each entity. Note Article 16(7): the DPO must reside in the UAE unless they are employed within the organisation’s Group and perform a similar function for the Group internationally — check that proviso before assigning the role to a China-based team remotely. Article 16(8) also requires the DPO’s contact details to be published so a third party can reach them without disproportionate effort, and the identity confirmed to the Commissioner in writing on request.
- Applies when
- AI businesses built on large-scale profiling, biometrics, behavioural monitoring or sensitive data will typically constitute High Risk Processing Activities; KYC and anti-fraud scoring in financial services are the clearest cases.
- Evidence to retain
- · High Risk Processing Activity determination memo, per business line, with reasoning
- · DPO appointment document or the Article 16(4) allocation-of-responsibility document
- · Note on the DPO’s independence and resourcing
- · Response template for providing responsible-person details to the Commissioner
Estimated first-time effort: 3–10 person-days (estimate, not a commitment)
DPIA and prior consultation with the Commissioner
Severity HighArt. 20、Art. 21
Carry out a DPIA for high-risk processing under Article 20; where the assessment indicates that, despite the measures referred to in Article 20(6)(e), risks to data subjects’ rights remain, Article 21 requires the controller to consult the Commissioner before processing, and the Commissioner may notify the controller and processor and use the Article 46 powers if the processing would infringe the Law. Wire the DPIA into model evaluation, red-teaming and launch approval so assessments are never retrofitted after go-live.
- Applies when
- Controllers launching new AI features, switching model vendors or widening data sources in the DIFC.
- Evidence to retain
- · DPIA report and the list of mitigating measures
- · Prior consultation submission and the Commissioner’s response, where triggered
- · Model evaluation and red-team test reports
- · Launch approval record showing the DPIA conclusion as a gating condition
Estimated first-time effort: 8–20 person-days (estimate, not a commitment)
Transfers out of the DIFC: adequacy list, safeguards and Commissioner notification
Severity HighArt. 26、Art. 27
Article 26 permits transfers to third countries or international organisations that the Commissioner has determined provide an adequate level of protection; the Commissioner publishes and maintains that list by Regulations, and such transfers need no specific authorisation. Otherwise Article 27 applies: rely on the Article 27(2) safeguards (a legally binding instrument between public authorities, Binding Corporate Rules, standard data protection clauses adopted by the Commissioner, or an approved code of conduct or certification mechanism with binding and enforceable commitments), or an Article 27(3) derogation; only where neither is available does the limited Article 27(4) route apply, and Article 27(5) then requires the controller to inform the Commissioner of the transfer. The Commissioner’s site publishes the Article 26 adequacy list and the Article 27(2)(c) model clauses — always use the current version.
- Applies when
- Every flow of personal data held by a DIFC entity to a Chinese parent, non-DIFC cloud, model training cluster or third-party labelling vendor.
- Evidence to retain
- · Export register (recipient, location, data categories, Article 26 or 27 route relied on)
- · Executed DIFC model clauses / standard contractual clauses or BCR approval
- · Record of the Article 27(5) notification to the Commissioner, where applicable
- · Review record against the Commissioner’s current adequacy list
Estimated first-time effort: 6–15 person-days (estimate, not a commitment)
Breach notification to the Commissioner, communication to data subjects, and written records
Severity HighArt. 41、Art. 42
Article 41 requires the controller to notify the Commissioner “as soon as practicable in the circumstances” of any personal data breach that compromises a data subject’s confidentiality, security or privacy, with at least the nature of the breach (including, where possible, the categories and approximate numbers of data subjects and records), the DPO or other contact point, the likely consequences, and the measures taken or proposed; information may be provided in phases. A processor must notify the relevant controller without undue delay. Article 42 requires communication to affected data subjects as soon as practicable where the breach is likely to result in a high risk to their security or rights, and prompt communication where there is an immediate risk of damage; the communication must be in clear and plain language and contain at least Articles 41(4)(b)–(d), with mitigation recommendations where possible. Article 41(6) requires a written record of all breaches, their effects and remedial action, available to the Commissioner without delay on request.
- Applies when
- All controllers and processors subject to the DIFC Data Protection Law.
- Deadline: To the Commissioner: as soon as practicable in the circumstances. To data subjects: as soon as practicable, and promptly where there is an immediate risk of damage.
- Evidence to retain
- · Breach response plan and Commissioner notification template aligned to the four elements of Article 41(4)
- · Written breach register recording facts, effects and remedial action
- · Data subject communication text and proof of delivery
- · Timing records for processor-to-controller notifications
Estimated first-time effort: 4–10 person-days (estimate, not a commitment)
Regulation 10: first-use notice and system disclosure for AI systems
Severity HighDP Regulations Reg. 10.2.2
Where an application or website service uses autonomous or semi-autonomous systems to process personal data, the Deployer or Operator must, on first use of or access to the system, give notice in clear and explicit terms of the underlying technology and processes that may process personal data in ways that are not human-initiated, controlled or directed (for example whether the system is restricted to specific human-defined purposes or can define further purposes itself), and of the impact of using the system on the exercise of individual rights under Article 29(1)(h)(ix). The notice must also give a comprehensive, true and plain description of: the human-defined purposes for which the system processes personal data; all human-defined principles and limits within which the system may define further purposes; the output produced and how it is used; the principles on which the system was designed to operate, including safeguards built in by design; and the codes, certifications or principles the system was designed or developed to — the Regulation names the Dubai Digital Authority, the OECD, UNESCO, the NIST AI Framework and the Guidelines for Financial Institutions adopting Enabling Technologies issued by the UAE Central Bank, the Securities and Commodities Authority, the DFSA and the FSRA as examples, and lets the Commissioner designate further codes and certifications.
- Applies when
- Deployers and Operators of AI-enabled applications or website services in the DIFC. A Chinese vendor supplying the system must be able to furnish the material behind all five descriptions, or the customer cannot launch.
- Applies from: 2023-09-01
- Evidence to retain
- · Final first-use notice copy and screenshots of where it is shown
- · System description (human-defined purposes, principles and limits for self-defined purposes, outputs and their use)
- · Inventory of safeguards built in by design and evidence of implementation
- · List of codes/certifications relied on (for example OECD, NIST AI RMF, UNESCO, Central Bank or DFSA guidelines)
Estimated first-time effort: 6–15 person-days (estimate, not a commitment)
Regulation 10: five design requirements and the human-defined-purpose constraint
Severity CriticalDP Regulations Reg. 10.3.1–10.3.2、10.3.4
Regulation 10.3.1 requires any system used in products, services or use cases that may affect a data subject, positively or negatively, to be designed to be Ethical (unbiased algorithmic decisions and data lineage, with bias mitigated), Fair (treat individuals equally, avoid or mitigate bias leading to unfair outcomes), Transparent (processing explainable to data subjects and stakeholders in non-technical terms with appropriate supporting evidence), Secure (personal data protected and confidential, preventing breaches causing reputational, psychological, financial or professional harm) and Accountable (internal governance and control frameworks or regular external audit enabling assessment of algorithms, data and design processes). Regulation 10.3.2 prohibits commercial use of any system unless it can process personal data only for human-defined or human-approved purposes — or for purposes it defines itself solely on the basis of human-defined principles and strictly within human-defined constraints — and is designed in compliance with 10.3.1 and any further audit and certification requirements the Commissioner establishes. Regulation 10.3.4 deems the Deployer a Controller and the Operator a Processor, so liability follows.
- Applies when
- Providers, Deployers and Operators of any AI system used commercially in the DIFC. It is especially pointed for agentic products, where the ability to define further purposes must be fenced by hard-coded human principles and constraints.
- Applies from: 2023-09-01
- Evidence to retain
- · Conformity note against the five design requirements and design review records
- · Bias and fairness test reports including data lineage analysis
- · Technical evidence of the purpose constraint (system prompts, tool allow-lists, purpose validation and refusal logic, logs)
- · Internal governance framework or external audit report covering algorithms, data and design processes
Estimated first-time effort: 12–30 person-days (estimate, not a commitment)
Regulation 10: certification and an Autonomous Systems Officer for High Risk Processing Activities
Severity CriticalDP Regulations Reg. 10.3.3
Regulation 10.3.3 provides that no person may use, operate, provide, offer or otherwise make available for commercial use a system to engage in High Risk Processing Activities unless: the Commissioner has established audit and certification requirements for such systems; the system complies with all of them; the system processes personal data solely for human-defined or human-approved purposes; and the Deployer or Operator has appointed an Autonomous Systems Officer with the same or substantially similar competencies, status, role and tasks as a DPO under Articles 17 and 18 of the Law. The Regulation’s guidance note states the regulatory intent that no system may be used for High Risk Processing Activities until the Commissioner has promulgated those requirements. DIFC has published a Regulation 10 certification framework, an accelerator framework and a list of Accredited Certification Bodies, together with an online certification application and a self-assessment tool.
- Applies when
- Providers, Deployers and Operators intending to use an AI system in the DIFC for High Risk Processing Activities such as large-scale profiling, biometrics, behavioural monitoring, or credit and insurance decisioning.
- Applies from: 2023-09-01
- Evidence to retain
- · High Risk Processing Activity determination and Regulation 10.3.3 applicability analysis
- · Regulation 10 certification application and the Accredited Certification Body’s conclusion
- · Autonomous Systems Officer appointment and role description, mapped to Articles 17 and 18
- · Technical evidence and audit trail that the system processes data only for human-defined or human-approved purposes
Estimated first-time effort: 15–40 person-days (estimate, not a commitment)
Article 38: manual review of solely automated decisions and special protection for minors
Severity HighArt. 38、Art. 39
A data subject has the right to object to any decision based solely on automated processing, including profiling, which produces legal consequences or other seriously impactful consequences, and to require manual review. The Article 38(2) exceptions are: necessity for entering into or performing a contract between the data subject and the controller; authorisation by applicable law that also lays down suitable safeguards; or the data subject’s explicit consent. Where the controller relies on contract necessity or explicit consent, Article 38(5) requires suitable safeguards including, at minimum, the ability for the processing to be reviewed manually. Article 38(4) disapplies all the exceptions where the data subject is a minor by reference to the UAE age of majority. Article 38(6) further bars decisions affecting a data subject based solely on automated processing of special category data unless explicit consent is given or the processing is necessary for reasons of substantial public interest on the basis of applicable law, proportionate, and accompanied by suitable safeguards.
- Applies when
- Controllers running automated approvals, scoring or screening in the DIFC. Products reaching minors must exclude solely automated significant decisions altogether.
- Evidence to retain
- · Automated decision inventory with legal analysis of the exception relied on
- · Manual review procedure and sample review records
- · Age assurance / minor routing mechanism description and test records
- · Lawfulness reasoning and safeguards list for automated decisions on special category data
Estimated first-time effort: 6–14 person-days (estimate, not a commitment)