Security, Breaches, Impact Assessment, and Cross-Border Transfers

This page covers the PDPL's operational protection duties: the Article 20 security measures every controller and processor must take, the Article 9 breach-reporting process, the Article 21 assessment of the impact of personal data protection, and the Articles 22–23 rules for moving personal data outside the UAE. It maps to the app requirements MRF-437, MRF-438, and MRF-439 and the org requirements ORF-459 and ORF-462.

Primary source

Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, in force since 2 January 2022. Quotations are from the official English translation; the Arabic original prevails in case of conflict. This page draws on Article 9 (breach reporting), Article 20 (personal data security), Article 21 (impact assessment), and Articles 22–23 (cross-border transfers). The regulator the translation refers to as "the Bureau" is the UAE Data Office, established under Federal Decree-Law No. 44 of 2021.

Key requirement families

Governance (OFF-24)	Execution (MFF-24)	Family	New UAE-PDPL control
—	MRF-437	Personal data security (Article 20)	—
ORF-459	—	Breach reporting (Article 9)	OCF-364
—	MRF-438	Data protection impact assessment (Article 21)	—
ORF-462	MRF-439	Cross-border transfers (Articles 22–23)	—

The split follows the law's addressees. Security measures and the impact assessment are executed where the processing happens, so they live in the application template. Notifying the Bureau of a breach is one organizational process regardless of which system was breached, so it is an org requirement. Transfers appear on both sides: ORF-462 is the organization's transfer framework, MRF-439 the per-application transfer record.

Executive Regulation status

As of this framework release (Modulos templates 1.0.23), the PDPL's Executive Regulation has not been issued. On this page, that affects the Article 9(1) and 9(2) notification periods, measures, and requirements, and the Article 23(2) transfer controls and stipulations. Two further items depend on the Bureau rather than the Regulation: the Article 21(6) list of processing operations exempt from impact assessment is not published, and no cases approved by the Bureau under Article 22 are published. The Modulos framework marks each of these points inside the affected requirement text and will be updated when the Executive Regulation is issued; see Scope, enforcement, and the Executive Regulation.

Article 20 — Personal data security (MRF-437)

Article 20(1) requires the controller and the processor to develop and take appropriate technical and regulatory measures to ensure "the highest standard of information security that is suitable for the risks related to data processing in accordance with the best international practices and standards". The article names four measure families:

• Encryption and pseudonymization — "Encryption of Personal Data and the application of Pseudonymisation" (Article 20(1)(a)).
• System integrity — measures ensuring the "continuous confidentiality, safety, accuracy and flexibility of data processing systems and services" (Article 20(1)(b)).
• Recovery after failure — measures ensuring "timely retrieval of and access to Personal Data in case of any actual or technical failure" (Article 20(1)(c)).
• Testing and evaluation — measures ensuring "a seamless testing and evaluation of the effectiveness of the technical and regulatory measures to ensure the security of processing" (Article 20(1)(d)).

Article 20(2) makes the security level risk-based. The evaluation observes the data processing risks, including "damage, loss, accidental or illegal change and disclosure of or access to the Personal Data, whether being transferred, stored or processing", and the costs, nature, scope and purposes of processing, together with the potential risks to the confidentiality and privacy of the data subject's personal data.

In Modulos, MRF-437 carries these duties per application on twelve controls, all reused from existing estates; the PDPL adds no new application controls:

• MCF-424 (Encryption at Rest), MCF-425 (Encryption in Transit), and MCF-426 (Pseudonymization Implementation) evidence Article 20(1)(a).
• MCF-427 (Access Control System) and MCF-429 (Security Monitoring) evidence the Article 20(1)(b) system-integrity measures.
• MCF-432 (Resilience and Availability) and MCF-433 (Backup and Recovery) evidence the Article 20(1)(c) recovery duty.
• MCF-322 (Security testing in development and acceptance) is the primary Article 20(1)(d) evidence, with MCF-430 (Penetration Testing) as one testing technique.
• MCF-234 (Information security risk assessment and documentation) and MCF-438 (Privacy risk assessment and documentation) evidence the Article 20(2) risk-based evaluation.
• MCF-269 (Independent review of information security) closes the loop with an independent check on the measures.

Article 9 — Reporting a personal data breach (ORF-459)

Article 9(1) requires the controller, at the time it becomes aware of a breach or violation of personal data that would prejudice the privacy, confidentiality and security of data, to notify the Bureau "of such breach or violation and the investigation rights within the period and in accordance with the measures and requirements set by the Executive Regulations of this Decree by Law". The phrase "and the investigation rights" appears as such in the official English translation; the Arabic original prevails. The law itself fixes what the notification must contain:

• a description of the nature of the breach or violation, its form, causes, approximate number and records (9(1)(a));
• details of the appointed Data Protection Officer (9(1)(b));
• potential and expected effects of the breach or violation (9(1)(c));
• corrective measures and actions taken or suggested to confront the violation and reduce its negative impacts (9(1)(d));
• documents of the violation and the corrective actions taken (9(1)(e));
• any other requirements required by the Bureau (9(1)(f)).

Article 9(2) adds a second notification: the controller notifies the data subject where the violation or breach would prejudice the privacy and confidentiality of the security of their personal data, again within the period and per the measures set by the Executive Regulation, and informs them of the measures taken. The data-subject period is delegated to the Regulation separately from the Bureau period, not derived from it. For processors, the first sentence of Article 9(3) is verbatim:

If the Processor becomes aware of any breach of Personal Data, it shall notify the Controller of such breach as soon as it becomes aware of the same.

The clause's second sentence closes the loop: "the Controller shall in turn inform the Bureau in accordance with Clause (1) of this Article."

Under Article 9(4), the Bureau verifies the reasons for the violation to ensure the integrity of the security measures taken, and shall impose the Article 26 administrative penalties where a violation of the law or the decisions implementing it is proven against the controller or processor.

No notification period is set

The Executive Regulation will specify the notification periods, measures and requirements for both the Bureau and the data-subject notification; it has not yet been issued. Do not assume the GDPR's 72-hour deadline applies. A breach process that hard-codes an invented deadline fails control OCF-364.

ORF-459 runs on two controls with a deliberate division of labor:

• OCF-193 Breach Response Process — reused from the GDPR estate and generalized: triggers, deadlines, recipients, and notification content are configured per applicable law, with the 72-hour deadline retained on the GDPR branch only. It owns detection, containment, investigation, the Article 9(2) data-subject notification, and the Article 9(3) processor-to-controller escalation.
• OCF-364 Breach Notification Readiness — new for the UAE PDPL. It keeps the Article 9(1)(a)–(f) Bureau content package assembled in advance, tracks any additional content the Bureau requires under 9(1)(f) as an already-operative element, and maintains the mechanism to adopt the Executive Regulation's period, measures, and requirements once issued.

Article 21 — Assessment of the impact of personal data protection (MRF-438)

Article 21(1) requires the controller, before carrying out the processing and taking into account its nature, scope and purposes, to evaluate the impact of the proposed processing operations on the protection of personal data "when using any of the modern technologies that would pose a high risk to the privacy and confidentiality of the Data Subject's Personal Data". Article 21(2) makes the assessment mandatory in two cases:

• processing that includes "a systematic and comprehensive assessment of the personal aspects of the Data Subject, using automated processing, including profiling, having legal consequences or serious impact on the Data Subject" (21(2)(a));
• processing of "a large volume of Sensitive Personal Data" (21(2)(b)).

Article 21(3) sets the minimum content: a clear and systematic explanation of the proposed processing operations and the purpose of processing; an evaluation of how necessary and suitable the operations are for that purpose; an evaluation of the potential risks to the privacy and confidentiality of the data subject's personal data; and the suggested procedures and measures aimed at reducing those risks. Three procedural clauses complete the article: the controller may carry out one evaluation for a set of processing operations of similar nature and risks (21(4)), coordinates with the Data Protection Officer when evaluating (21(5)), and reviews the evaluation results on a regular basis to make sure processing remains in accordance with the assessment in case the risk level changes (21(7)).

Article 21(6) directs the Bureau to prepare and publish a list of processing operation types that do not require an assessment. As of this framework release that list is not published; an exemption cannot be relied on without a verified applicable entry on the published list.

MRF-438 carries the assessment per application on two reused privacy controls: MCF-443 (Privacy impact assessment), extended to cover the full Article 21 minimum content, DPO coordination, grouping of similar operations, and reassessment, and MCF-438 (Privacy risk assessment and documentation) for the underlying risk analysis. The coordination duty in 21(5) presupposes the DPO appointment and enablement requirements covered in Controllers, processors, and the DPO.

Articles 22–23 — Cross-border transfers (ORF-462, MRF-439)

The PDPL regulates transfer in two tiers. Article 22 covers destinations where a proper protection level is available:

Personal Data may be transferred to outside of the State in the following cases approved by the Bureau:

The two Article 22 cases: the destination state or province has personal data protection legislation, including the most significant provisions, measures, controls, stipulations and rules protecting the privacy and confidentiality of the data subject's personal data and their ability to exercise their legal rights, plus a judicial or regulatory authority imposing appropriate measures against the controller or processor (22(1)); or the UAE has joined a bilateral or multilateral agreement related to the protection of personal data with the destination country (22(2)). As of this framework release, no cases approved by the Bureau under Article 22 are published, so no transfer can currently be grounded on Article 22.

Article 23 covers transfers where a proper protection level is not available. Notwithstanding Article 22, personal data may be transferred outside the State in six cases:

• Contract — companies operating in countries with no data protection laws may transfer under a contract or agreement obligating the companies in those countries to adopt the measures, controls and requirements of the PDPL, including provisions forcing the controller or processor to adopt appropriate measures imposed by a judicial or regulatory authority in such countries as set out in the contract (23(1)(a)).
• Explicit consent — the data subject's explicit consent to the transfer, "provided that such transfer shall not contradict the public or security interest of the State" (23(1)(b)).
• Judicial necessity — the transfer is necessary to fulfill obligations and establish, exercise or defend rights before judicial entities (23(1)(c)).
• Contractual necessity — the transfer is necessary to sign or implement a contract between the controller and the data subject, or between the controller and third parties to serve the interest of the data subject (23(1)(d)).
• International judicial cooperation — the transfer is necessary to implement an action related to an international judicial cooperation (23(1)(e)).
• Public interest — the transfer is necessary to protect the public interest (23(1)(f)).

Article 23(2) reserves the controls and stipulations to be observed during transfer to the Executive Regulation, so the mechanics of each mechanism remain to be specified.

In Modulos the transfer duty splits between the templates. ORF-462 is the organization's transfer framework: for each destination it records the basis of transfer, with evidence. Reliance on Article 22 requires that the relied-on case be one approved by the Bureau; as of this framework release no such approvals are published, so each transfer is documented under an Article 23 mechanism, whose controls and stipulations Article 23(2) reserves to the Executive Regulation. The requirement runs on four org controls reused from the GDPR estate and generalized so their GDPR branches stay fully correct: OCF-199 (Contractual Transfer Safeguards), rewritten around legally recognized or authority-approved contractual instruments with the GDPR's standard contractual clauses preserved as the GDPR branch; OCF-201 (Adequacy Monitoring), whose PDPL branch monitors for cases approved by the Bureau under Article 22; OCF-202 (Derogation Documentation), with jurisdiction-conditional constraints; and OCF-205 (Cross-Border Processing Register), the register of cross-border processing activities and the transfer mechanism each relies on.

MRF-439 is the application-side record: every cross-border transfer of the application's personal data is identified and documented with its destination, mechanism, and safeguards. It runs on three controls from the ISO 27701 estate: MCF-466 (Identify basis for PII transfer between jurisdictions), MCF-467 (Countries and international organizations to which PII can be transferred), and MCF-468 (Records of transfer of PII).

Cross-framework mapping (preview)

Preview

• GDPR — Articles 32 (security), 33–34 (breach notification), 35 (DPIA), and 44–49 (transfers) cover corresponding ground with different triggers, and with deadlines the PDPL has not yet set. The shared controls carry both branches; the PDPL branch never inherits GDPR deadlines.
• ISO/IEC 27701 — the transfer-basis, destination, and transfer-record controls (MCF-466–MCF-468) come directly from the 27701 estate.
• ISO/IEC 27001 — the Article 20 security measures reuse existing GDPR- and ISO-estate security controls (encryption, access control, monitoring, resilience, backup, security testing); most of the twelve are shared with the GDPR's Article 32 requirement.

These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence.

Related pages

Scope, enforcement, and the Executive Regulation

Who the PDPL applies to, the Bureau's role, and the full inventory of Executive-Regulation-dependent items — ORF-456, ORF-463, ORF-464

Lawful processing and data subject rights

Consent, the processing controls, and the rights the breached or transferred data ultimately serves — MRF-431–432, MRF-434–436

Controllers, processors, and the DPO

The DPO whose details go in the Article 9(1) Bureau notification and who coordinates the impact assessment — ORF-457–458, ORF-460–461, MRF-433

Operationalizing in Modulos

The OFF-24 / MFF-24 rollout sequence, control split, and evidence model

Source attribution

The authoritative source is Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, issued 20 September 2021, published in Official Gazette No. 712 of 26 September 2021, and in force since 2 January 2022. Quotations are from the official English translation published at uaelegislation.gov.ae; the Arabic original prevails in case of conflict. This page draws on Articles 9, 20, 21, 22, and 23. Requirement and control codes are Modulos template identifiers, not PDPL references.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The Executive Regulation of the PDPL has not yet been issued, and several obligations described here will be completed by it. Verify against the current text of the law and consult qualified advisers.