Last updated: 2026-09-14
There is also a separate 72-hour requirement for high-risk Incidents. These provisions have different triggers. Treating them as one universal cyber-breach deadline could produce the wrong reporting decision.
For risk, compliance, technology and operations teams, the practical question is straightforward: can the institution identify the affected service, assess the consequences and authorise a notification while the incident is still unfolding?
The regulation is in force from 14 September 2026. Article 20 provides for commencement one month after publication; the Rulebook identifies the effective date explicitly.
It establishes minimum requirements across operational risk, resilience, governance, technology, incident management, continuity and third-party dependencies. Article 19 replaces the 2018 Operational Risk Regulation and Operational Risk Standards under Circular 163/2018.
Updating the notification section of an old policy is therefore only part of the work. Institutions also need the service maps, decision rights and recovery arrangements that make timely reporting possible.
The scope covers all CBUAE Licensed Financial Institutions that are juridical persons. The definition includes banks, insurers, reinsurers and other licensed financial institutions, including Islamic financial institutions. It also encompasses relevant UAE branches and subsidiaries of institutions incorporated overseas or in financial free zones.
Coverage depends on the institution’s licence and legal structure. A business does not fall within this regulation merely because it describes itself as a fintech or supplies software to a UAE bank. Similarly, a financial-free-zone authorisation alone should not be treated as proof of CBUAE coverage.
Technology providers may nevertheless face stronger contractual expectations because their financial-institution customers must manage the resilience of supporting services.
Critical Operations cover activities, services, processes and supporting assets whose disruption would affect the institution’s continued operation, financial-system role or customers. Criticality depends on the institution’s circumstances, and CBUAE can designate particular operations as critical.
Article 3 requires institutions to consider, at a minimum:
A practical assessment starts with the service delivered and the consequences of interruption. A server inventory alone cannot explain whether a failed application prevents customers receiving funds or leaves the institution unable to establish its financial position.
Critical Information Assets are data assets whose confidentiality, integrity or availability is essential to Critical Operations or legal and regulatory compliance, including personal-data protection.
The regulation defines an Incident as an event that adversely affects, or could adversely affect, Critical Operations or Critical Information Assets.
The practical implication is that service availability and data compromise need separate checks. A customer-facing application can remain online while information behind it is exposed or altered. Conversely, a serious outage can occur without personal-data theft.
Neither a functioning website nor the absence of confirmed exfiltration should end the assessment.
Article 3.4 requires a map for each Critical Operation covering people, technology, processes, data, facilities and third-party providers, including intragroup entities. The map must show relevant interconnections and dependencies and be updated through change management.
For a payment service, a useful map would connect the customer journey to authentication, transaction processing, financial records, network access, operational staff and external processing services. It should identify who can explain the business impact when one dependency fails.
Use that map to ask practical questions: Can an alternative channel carry the workload? Are financial records trustworthy? Is recovery dependent on the same provider or credentials that have just failed?
Article 15.2 addresses operational events with significant actual or potential effects on the continuity or integrity of Critical Operations. Its examples include actual or likely activation of continuity or disaster-recovery plans and material actual or likely effects on customers, operations, profitability or capital.
Article 15.3 concerns high-risk Incidents, with classification criteria established in Board-approved policies.
Our reading is that both provisions can apply to the same cyber incident. They are not expressed as mutually exclusive categories. A high-risk classification does not displace an independently applicable four-hour requirement.
Consider a hypothetical ransomware incident affecting a transaction platform. The institution should assess the operational reporting trigger and its high-risk criteria concurrently. For a suspected compromise of important customer records with no service interruption, the assessment still needs to consider data-related risk and separate privacy or consumer-protection duties.
The 24-hour report is a summary of the developing situation. Prepare it around verified facts, current actions and clearly labelled uncertainties. Do not invent a recovery estimate simply to complete a field; explain what is known and what still needs confirmation, subject to the applicable reporting instructions. For planning, do not assume that the initial notification starts a fresh 24-hour window.
Article 15.1 also creates a prompt-notification obligation for specified risk-governance issues. Teams should therefore avoid building a process that only recognises the numbered hourly deadlines.
The wording needs careful treatment:
As an operational precaution, retain separate timestamps for occurrence, first detection, initial awareness, impact assessment and escalation. Start the reporting assessment immediately; do not reset the clock when a committee meets or when a vendor completes its investigation.
Confirm the applicable timing interpretation through current supervisory instructions and qualified UAE counsel where needed. Article 18 identifies CBUAE’s Regulatory Development Department as the reference for interpreting the regulation. If an event is discovered late, escalate and document the chronology rather than assuming discovery creates a fresh reporting period.
Article 15 does not name a universal submission portal, incident email address or prescribed form. The public materials reviewed for this article did not establish a universally applicable channel or template for C 1/2026.
Institutions should obtain and maintain their current supervisory reporting instructions, including the approved route, required fields, authorised submitters, backup access and out-of-hours arrangements. Article 15.6 allows CBUAE to change notification requirements by notice, and additional requirements can apply to an individual event.
Where multiple provisions apply, confirm whether one submission can satisfy them and what additional information or follow-up is required. Do not assume an earlier report automatically closes every reporting obligation.
Article 8.10 requires compliance with applicable UAE ICT, cyber and information-security regulations. Article 9 also anticipates communications to other authorities where required.
Build an obligations register by legal entity, licence, affected information and jurisdiction. The following examples show why a single default deadline is inadequate.
Consumer data. Where applicable, the Consumer Protection Standards require immediate CBUAE notification of significant personal-data breaches. They also require affected-consumer communications without delay in specified risk circumstances. Four hours should not become a waiting period where an immediate duty applies.
Card schemes. The Retail Payment Services and Card Schemes Regulation contains a separate data-breach provision for card schemes: notification without undue delay and no later than 72 hours after awareness. That express awareness wording should not be imported into C 1/2026’s differently worded Article 15.3.
Federal personal-data law. Article 2 of Federal Decree-Law 45/2021 excludes personal banking and credit information where legislation regulates its protection and processing. This is not a sound basis for assuming every dataset held by a financial institution is excluded. Where the federal law applies, its Article 9 links breach reporting to awareness and refers to executive regulations for the period and procedures; the law itself does not supply a universal 72-hour deadline.
Cybersecurity and cross-border duties. Check applicable national, emirate-level, licence-specific and overseas requirements separately. A report to a financial supervisor should not be assumed to discharge a different authority’s requirements or a contractual customer-notification duty.
Article 9 requires predefined severity criteria, including factors such as impact and expected recovery time, together with assigned responsibilities, communication plans and an incident register.
For the high-risk policy, the public regulation does not prescribe a universal numerical scoring model. Institutions need criteria that staff can apply consistently to their own services and exposures.
A practical policy could assess:
These are suggested design factors, not CBUAE-issued thresholds. Document the rationale, examples, escalation rules and how an incident is reassessed as evidence changes. Keep the Article 15.2 test independently visible.
The Board retains ultimate responsibility for the framework. Article 4 requires Board oversight of ICT and cybersecurity risk management. Article 5.4 requires timely reporting of actual or expected breaches of risk appetite, tolerance and associated limits to the Board itself, rather than only a committee.
As a practical implementation choice, pre-authorise reporting roles and deputies. Board escalation and regulatory notification should be able to proceed in parallel without waiting for the next scheduled meeting.
Article 8 requires an integrated ICT and cybersecurity risk framework, monitoring and testing, protection and recovery capabilities, and management of obsolete or unsupported systems. The Board and senior management must receive information about exposures, incidents and identified weaknesses.
For implementation, connect monitoring alerts to the service map. Responders need to distinguish a failed device from a failed customer service, and an unavailable database from records whose accuracy can no longer be trusted.
Article 8.9 also requires the Master System of Record to be continuously maintained and stored in the UAE, including when outsourced. Foreign financial-institution branches may, subject to CBUAE approval, meet that requirement through an up-to-date UAE copy.
Review that specific requirement against the actual architecture. It should not be paraphrased as an unrestricted ban on every overseas processing arrangement.
Article 11 requires continuity and disaster-recovery plans linked to the Critical Operations map, with clear activation triggers, recovery time objectives and recovery point objectives. Plans and procedures must be tested at least annually for Critical Operations, with relevant providers involved where appropriate. Results must reach the Board and senior management.
In practical terms, a recovery time objective concerns how quickly an operation should be restored; a recovery point objective concerns the point to which data should be recoverable.
Test restoration of the service, including data consistency and transaction reconciliation. A successful infrastructure restart alone may not establish that customers can use the service safely.
Include a rehearsal in which the usual incident manager is unavailable, normal communications fail and the recovery environment shares an affected dependency. Capture who can decide that operations have returned to normal and the evidence supporting that decision.
Article 13 requires third-party risk assessment, due diligence, appropriate contractual rights and ongoing monitoring. Outsourcing an activity whose disruption could significantly affect Critical Operations requires prior CBUAE non-objection. Relevant subcontracting arrangements also need enforceable protections.
For incident readiness, review whether contracts actually enable fast action. A practical clause should address early alerts, a reachable incident contact, evidence preservation, updates, customer-impact information and cooperation with regulatory reporting. Set supplier response expectations early enough to leave the institution time to assess and submit; the regulation does not prescribe one universal vendor-to-customer notification interval.
An overseas location does not remove a dependency from the UAE assessment. Article 3.4 expressly includes intragroup entities in mapping. Our operational reading is that a group incident needs assessment against the UAE institution’s affected operations and information assets. This does not mean every unrelated overseas event is automatically reportable.
Ask group teams to identify affected UAE services early. A global severity label or head-office announcement may not answer the local reporting question.
Article 13.11 requires viable contingency and exit plans for arrangements material to Critical Operations. Substitution assessments must identify where a timely replacement—including bringing the service in-house—is costly, risky or impossible.
For a useful exit exercise, test data export, alternative-provider capacity, access to configuration and documentation, migration time, legal constraints and reconciliation after transfer. If replacing the provider would take months, record that dependency honestly and identify how the service would continue meanwhile.
The following is a recommended implementation sequence, not an official reporting template.
Record the affected legal entity, incident owner, known timestamps, services and information involved, available evidence, reporting assessments and unresolved questions. Keep updates under one incident identifier.
Assign compliance and operational-risk owners to evaluate the applicable CBUAE provisions and other reporting duties while technical teams investigate. Give each duty its own trigger, timing basis, recipient and submission status.
An internal working template should capture the institution and contact person, what happened, affected Critical Operations, known customer impact, containment or recovery actions and current uncertainties. Maintain the regulator’s required format where one has been supplied.
Use a separate update section for new facts, changed estimates and corrective actions. Preserve previous versions so the chronology remains clear.
Name the person who drafts, checks and submits the notification, with deputies for each role. Make sure authorised staff can access the submission route during an outage. Record submission evidence and acknowledgements.
Use a tabletop exercise where a provider confirms disruption but cannot yet explain the cause or full scope. Check whether the team can assess potential impact, escalate uncertainty and prepare a useful early report without presenting assumptions as facts.
Agree the evidence needed to confirm normal operations: service performance, record integrity, outstanding transactions and any remaining restrictions. Track subsequent reporting requirements and remediation separately from technical closure.
After an incident, compare the intended process with what happened. Was the business owner reachable? Did supplier information arrive soon enough? Were estimates clearly labelled? Give corrective actions owners and completion dates.
The practical challenge is being able to explain an incident while recovery is still underway. That depends on accurate service maps, usable criteria, clear authority and timely information from providers.
Begin with one Critical Operation and rehearse the full path from first alert to notification and recovery confirmation. The exercise will show where missing ownership, weak records or slow handoffs need attention.
For technology companies supporting financial institutions, Kooch can help organise the underlying security and privacy controls, data inventories and compliance workflows. Explore our ongoing privacy and compliance operations support to discuss a defined implementation scope. UAE regulatory interpretation and institution-specific filing decisions should be handled with the institution’s compliance team and qualified UAE counsel where required.
Official materials checked on 14 September 2026. Practical examples and suggested workflows in this article are implementation recommendations, not additional regulatory rules.
