Quick Answer
Every UAE-licensed bank, (re)insurance company, and other financial institution must comply with the Operational Risk Management Regulation (Circular C 1/2026, in force from 14 September 2026), which replaces the 2018 Operational Risk Regulation. It requires institutions to identify their Critical Operations, map every asset and third party supporting them, maintain Board-approved Business Continuity and Disaster Recovery Plans with tested recovery targets, manage third-party risk formally, and notify the Central Bank within 4 hours of any event significantly affecting a Critical Operation.
Key Takeaways
- The regulation applies to all Licensed Financial Institutions that are juridical persons, banks, Islamic Finance Institutions, (re)insurance companies, and Other Financial Institutions, not banks alone (Scope).
- "Critical Operations" is a defined term with a specific test: activities whose disruption would affect financial stability or the institution's role in the financial system, judged by size, market share, interconnectedness, complexity, and substitutability (Article 1.10).
- The Board, not a delegated committee, must approve the institution's Risk Appetite and Tolerance for Operational Risk and its tolerance for disruption at least annually, and must itself approve the initial Business Continuity and Disaster Recovery Plans (Article 4.2).
- Incident notification runs on a strict clock: 4 hours for initial notification of an event significantly affecting Critical Operations, 24 hours for a summary report, and 72 hours for any high-risk incident regardless of Critical Operation impact (Article 15).
- This regulation is the parent instrument behind two more detailed obligations: Business Impact Analysis for trust and agency operations (Article 11), and Third-Party Risk Management for developer and vendor relationships (Article 13).
The Regulation: What It Is and Why It Replaces the 2018 Rules
The Operational Risk Management Regulation (Circular C 1/2026) comes into force on 14 September 2026 and formally cancels and replaces Circular No. 163/2018, the earlier "Operational Risk Regulation," and its accompanying Operational Risk Standards issued 29 August 2018 (Article 19.1).
It is issued under the Central Bank's powers pursuant to Federal Decree-Law No. (6) of 2025 Regarding the Central Bank, Regulation of Financial Institutions and Activities, and Insurance Business.
The shift from the old regulation to the new one is not cosmetic. Where the 2018 rules focused on operational risk governance, identification, and control, the new regulation introduces Operational Resilience as a distinct, defined concept: the ability of an institution to deliver Critical Operations through disruption, not merely to manage the risk of disruption occurring (Article 1.18). That distinction, resilience as an outcome to be demonstrated, not just a risk to be managed, runs through nearly every article that follows.
Who It Applies To
The regulation applies to all Licensed Financial Institutions that are juridical persons (Scope). This is a broader net than "banks":
Banks - any juridical person licensed to primarily take deposits plus other financial activities (Article 1.1)
Islamic Finance Institutions - banks, Takaful insurance companies, and other institutions conducting business under Shari'ah principles (Article 1.13)
(Re)Insurance Companies - both insurance and reinsurance companies (Article 1.24)
Other Financial Institutions - any licensed entity that isn't a bank or (re)insurance company but carries a Licensed Financial Activity (Article 1.20)
This includes UAE-incorporated institutions and branches or subsidiaries of foreign financial institutions operating in the UAE.
Comparison: What Changed from the 2018 Operational Risk Regulation
| Dimension |
2018 Operational Risk Regulation (Circular 163/2018) |
2026 Operational Risk Management Regulation (C 1/2026) |
| Core concept |
Operational risk governance, identification, and control |
Operational Risk and Operational Resilience as distinct, defined obligations |
| Critical Operations |
Not a formally defined, mapped concept |
Explicitly defined; institutions must map every supporting asset and interdependency (Article 3.4) |
| Third-party risk |
General outsourcing guidance |
A dedicated article (13) with Board-approved strategy, mandatory contingency and exit plans, and substitutability assessment |
| Incident notification |
Less prescriptive timelines |
Explicit 4-hour/24-hour/72-hour tiered notification clock (Article 15) |
| Data residency |
Not specified at this level of detail |
Master System of Record must be continuously maintained and stored within the UAE (Article 8.9) |
| Testing |
General expectation |
At least annual testing for Critical Operations, under severe-but-plausible scenarios, with Third-Party Service Providers included where relevant (Article 11.10-11.11) |
The Requirements, Article by Article
Article 2 - Operational Risk Management FrameworkEvery institution needs a documented framework covering governance structure, policies, risk identification tools, thresholds and limits, monitoring, and mitigation strategies, fully integrated into the institution's broader risk management framework.
Article 3 - Operational ResilienceThe centerpiece article. Institutions must identify their Critical Operations and map every supporting asset, people, technology, processes, data, facilities, and Third-Party Service Providers, including intragroup entities, and the interdependencies among them (Article 3.4). At minimum, Critical Operations must include payment systems and time-critical customer services, the ability to maintain accurate financial records, and the ability to measure and manage solvency and liquidity (Article 3.5).
Article 4 - Role of the BoardThe Board bears ultimate, non-delegable responsibility. It must approve and review at least annually the institution's Risk Appetite and Tolerance for Operational Risk, its tolerance for disruption under severe-but-plausible scenarios, and its Business Continuity and Disaster Recovery Plans (Article 4.2). The Board may delegate the annual review of BCP/DR plans to a committee, but must itself approve the initial plans and review them at least every three years (Article 4.2). Systemically important institutions must have a Board Operational Risk committee (Article 4.9).
Article 8 - ICT and Cybersecurity ManagementRequires a robust ICT risk framework and, notably, that the institution's Master System of Record, all data required to conduct Critical Operations, be continuously maintained and stored within the UAE, even where activities are outsourced (Article 8.9).
Article 9 - Incident ManagementInstitutions must maintain Incident Response and Recovery Plans covering the full incident lifecycle: severity classification, response and recovery procedures, roles and responsibilities, communication plans, and a documented incident register (Article 9.4).
Article 11 - Business Continuity PlanningRequires Business Continuity and Disaster Recovery Plans built on the Critical Operations mapping from Article 3.4, tested annually, with clear Recovery Time and Recovery Point Objectives reflecting the Board-approved tolerance for disruption.
Article 12 - Change ManagementMaterial changes affecting Critical Operations require thorough testing, rollback plans, and, for changes materially affecting Critical Operations or customers, an external expert assessment submitted to the Central Bank at least 30 calendar days before implementation, with written no-objection required before go-live (Article 12.5).
Article 13 - Third Party Risk ManagementRequires a Board-approved third-party risk strategy, pre-engagement due diligence, contractual safeguards, and, for arrangements material to Critical Operations, viable contingency and exit plans that assess substitutability.
Article 15 - Notification and Reporting RequirementsSets the incident notification clock: 4 hours to notify the Central Bank of an event significantly affecting Critical Operations, 24 hours for a summary report, notification upon return to normal operations, and 72 hours for any incident classified as high-risk regardless of Critical Operation impact (Article 15.2-15.3).
Article 16 - Disclosure RequirementsInstitutions must publicly disclose key information about their Operational Risk and Resilience approach, commensurate with their size and systemic importance.
Expert Insight: Resilience Is Now a Board Accountability, Not a Delegated Function
Expert Insight
The most consequential design choice in this regulation is where it places accountability. Article 4.1 states plainly that Board members "bear ultimate responsibility" for the Operational Risk and Resilience framework, and that this responsibility "is retained by the members of the Board regardless of any Board committees set up." Article 4.2 goes further, specifying that the Board, not a committee, must approve the institution's tolerance for disruption and its initial Business Continuity and Disaster Recovery Plans.
This matters because operational resilience has historically been treated, in practice if not in policy, as a technology and operations problem escalated to the Board only after something goes wrong. This regulation inverts that: the tolerance for disruption is a strategic decision the Board makes in advance, informed by severe-but-plausible scenario analysis, and every recovery target the institution sets, including the RTOs and RPOs specialist teams work to, must trace back to that Board decision. A GRC function that presents resilience metrics to the Board only as a status update, without first securing genuine Board engagement on the underlying tolerance statement, is missing the article's actual intent.
Controls and Evidence Mapping
| Control Area |
Governing Article |
Evidence to Maintain |
Typical Owner |
| Critical Operations mapping |
Article 3.4 |
Documented mapping of assets, interdependencies, updated via change management |
Operational Risk / BCM |
| Board tolerance for disruption |
Article 4.2 |
Board minutes, approved tolerance statement, reviewed at least annually |
Board / Senior Management |
| Master System of Record residency |
Article 8.9 |
Data residency confirmation, including for outsourced arrangements |
ICT / Operational Risk |
| Incident lifecycle management |
Article 9.4 |
Incident register, severity classification records, root cause analyses |
Operational Risk |
| BCP/DR testing |
Article 11.10-11.11 |
Test plans, results, Board and Senior Management reporting |
BCM |
| Third-party risk management |
Article 13 |
TPSP register, due diligence records, contingency/exit plans |
Third-Party Risk |
| Incident notification |
Article 15.2-15.3 |
Notification logs against the 4hr/24hr/72hr timelines |
Operational Risk / Compliance |
Practical Example: A Payment System Outage, Start to Notification
Example
A UAE bank's payment processing system, a Critical Operation under Article 3.5.1, experiences an unplanned outage at 9:14 AM. Because the Critical Operations mapping required under Article 3.4 already identifies this system's dependencies, the operational risk team immediately knows which downstream processes are affected and which Third-Party Service Providers, if any, are involved.
By 10:00 AM, the incident is classified under the severity criteria set out in the institution's Board-approved Incident Response Plan (Article 9.4.1). The 4-hour notification clock under Article 15.2.1 is running: the Central Bank must be notified of the event and which Critical Operations are affected by 1:14 PM. A summary report, nature of the event, actions being taken, likely impact, timeframe for return to normal, is due by 9:14 AM the next day under Article 15.2.2. Once payment processing is restored, a final notification confirms the return to normal operations (Article 15.2.3).
Because the institution's Business Continuity Plan was tested within the last 12 months against a severe-but-plausible scenario resembling this one (Article 11.10-11.11), the recovery time objective for this specific Critical Operation was already known and defensible before the incident occurred, rather than being estimated for the first time under pressure.
Operational Resilience Readiness Checklist
Critical Operations identified and formally mapped, including all supporting people, technology, data, facilities, and Third-Party Service Providers (Article 3.4)
Board has approved the institution's tolerance for disruption based on severe-but-plausible scenarios (Article 4.2.2)
Board has approved the initial Business Continuity and Disaster Recovery Plans directly, not via committee delegation (Article 4.2)
Master System of Record confirmed as continuously maintained and stored within the UAE, including for outsourced arrangements (Article 8.9)
Incident Response and Recovery Plans documented, covering the full incident lifecycle (Article 9.4)
BCP/DR plans tested within the last 12 months for all Critical Operations, with results reported to the Board (Article 11.10)
Third-Party Risk Management strategy Board-approved, with contingency and exit plans for TPSPs material to Critical Operations (Article 13.1, 13.11)
Incident notification procedures built to meet the 4-hour/24-hour/72-hour timelines (Article 15.2-15.3)
Public disclosure on Operational Risk and Resilience approach prepared, commensurate with institution size and systemic importance (Article 16)
Systemically important institutions have established a Board Operational Risk committee (Article 4.9)
Operational Resilience Maturity Model
| Dimension |
Level 1: Ad Hoc |
Level 2: Developing |
Level 3: Managed |
Level 4: Optimized |
| Critical Operations mapping |
Not formally identified |
Identified but not mapped to supporting assets |
Mapped per Article 3.4, updated periodically |
Mapping integrated into live change management |
| Board engagement |
Resilience reported as a status update |
Board reviews annually but tolerance statement is generic |
Board actively approves specific, scenario-based tolerance |
Tolerance statement drives resource allocation decisions |
| Testing |
Ad hoc or undocumented |
Annual desktop exercise only |
Annual scenario-based testing including key TPSPs |
Continuous testing informing live recovery target revision |
| Incident notification |
No defined process |
Process exists but timelines not consistently met |
4hr/24hr/72hr timelines consistently met |
Notification triggers built into monitoring systems |
| Third-party risk |
Managed informally per relationship |
Due diligence exists but inconsistent |
Board-approved strategy with contingency plans for material TPSPs |
Substitutability continuously assessed and reported |
A self-assessment against these five dimensions, rather than an assumption about where the institution or its peers currently sit, is the most useful starting point for a gap analysis ahead of the regulation's effective date.
Best Practices
Treat the Critical Operations mapping (Article 3.4) as the foundation every other obligation builds onGet this right first, since BCP, incident management, and third-party risk management all reference it directly.
Secure genuine Board engagement on the tolerance-for-disruption statementBefore treating any RTO or RPO as final.
Build the 4-hour notification decision into monitoring systems in advanceSo the question "does this qualify" is already answered before an incident occurs.
Confirm Master System of Record residency nowIncluding for any outsourced or cloud-hosted arrangements, rather than assuming existing infrastructure already complies.
Include material Third-Party Service Providers in annual BCP/DR testingNot just internal systems.
Prepare the public disclosure required under Article 16 well before the effective dateRather than treating it as a late-stage compliance task.
Common Mistakes
Treating Critical Operations identification as a one-time exercise
Article 3.4 explicitly requires the mapping to be updated as part of change management, a static document produced once for the effective date will be out of date within months.
Delegating the initial BCP/DR approval to a committee
Article 4.2 is explicit that the Board itself, not a committee, must approve the initial plans, a common governance gap at institutions accustomed to delegating operational matters.
Underestimating the Master System of Record requirement
Institutions relying on offshore or group-level systems for core data may not currently meet the UAE residency requirement under Article 8.9 and need lead time to address this before the effective date.
Testing only internal systems
Article 11.10 expects testing to include key Third-Party Service Providers where relevant, a BCP test that only exercises internal failover misses a meaningful part of the requirement.
Waiting until an incident to define severity classification criteria
Article 9.4.1 requires predefined criteria for incident severity, defining these during a live incident undermines the speed the notification clock demands.
Common Challenges at Scale
Coordinating a mapping exercise across business lines that don't naturally share data
Critical Operations frequently span multiple departments, each with a partial view of the full dependency chain.
Balancing Board-level engagement with operational detail
Boards need enough scenario-based context to make a genuine tolerance-for-disruption decision without being overwhelmed by technical detail that belongs at the operational risk function level.
Meeting the 30-day change notification requirement (Article 12.5.5) for fast-moving technology changes
Institutions modernizing core systems need to build regulatory lead time into project planning from the outset.
Verifying Master System of Record residency for group-structured institutions
Branches and subsidiaries of foreign financial institutions need a clear internal process to confirm and evidence UAE data residency, including where a Central Bank-approved alternative arrangement applies.
Expert Tip
Best Practice
When assessing whether the institution is ready for this regulation, don't start with the BCP. Start with the Critical Operations mapping under Article 3.4, nearly every other article (BCP, incident management, third-party risk, notification) explicitly references this mapping as its foundation. An institution with a strong BCP built on an incomplete or outdated Critical Operations map is building on the wrong foundation.
Use Cases
A bank preparing for the 14 September 2026 effective date
A comprehensive gap assessment against the readiness checklist above, prioritized by which articles depend on the Critical Operations mapping first.
An insurer determining whether it qualifies as systemically important
Understanding the Board Operational Risk committee requirement under Article 4.9 and confirming current governance structure meets it.
A GRC team building a Board reporting pack for the tolerance-for-disruption approval
Structuring scenario-based analysis in a form the Board can genuinely engage with and approve, rather than rubber-stamp.
An institution outsourcing a core system to a cloud provider
Assessing Master System of Record residency requirements under Article 8.9 before finalizing the arrangement.
Implementation: Getting Ready Before 14 September 2026
Step 1
Complete or refresh the Critical Operations mapping
Under Article 3.4, involving every business line that touches a candidate Critical Operation.
Step 2
Bring the tolerance-for-disruption statement to the Board
With genuine scenario-based analysis, not a generic risk appetite restatement.
Step 3
Audit Master System of Record residency
Across all Critical Operations, including outsourced and group-shared systems.
Step 4
Review and rebuild Incident Response and Recovery Plans
To meet the full lifecycle requirements of Article 9.4.
Step 5
Schedule BCP/DR testing for all Critical Operations
Including relevant Third-Party Service Providers, ahead of the effective date.
Step 6
Build the incident notification workflow
To meet the 4-hour/24-hour/72-hour timelines under Article 15, including clear internal escalation triggers.
Step 7
Prepare the Article 16 public disclosure
On the institution's Operational Risk and Resilience approach.
Metrics to Track
Percentage of Critical Operations with a current, change-management-linked dependency mapping
Time from Board approval of the tolerance-for-disruption statement to its translation into documented RTOs/RPOs
Percentage of Critical Operations tested in the last 12 months, including Third-Party Service Provider participation where relevant
Incident notifications meeting the 4-hour/24-hour/72-hour timelines vs. total qualifying incidents
Number of Third-Party Service Provider arrangements material to Critical Operations with a current contingency and exit plan
How autoResilience Supports Operational Resilience Programs
autoResilience is an integrated Governance, Risk, Compliance and Resilience platform. Meeting this regulation's requirements involves coordinating a Critical Operations mapping, Board-level tolerance statements, incident management, BCP/DR testing, and third-party risk management, obligations that in most institutions today live in separate documents, owned by separate teams, with no single view connecting them back to the underlying Critical Operations mapping the regulation treats as foundational.
Within autoResilience, an institution can maintain a centralized Critical Operations register linked to supporting assets and dependencies, track Board approval and review cycles for the tolerance-for-disruption statement, manage the incident lifecycle from detection through the regulatory notification timeline, and maintain BCP/DR testing schedules and third-party contingency plans in one connected system. Dashboards can surface which Critical Operations lack a current mapping, which BCP tests are overdue, and which incident notifications are approaching their regulatory deadline.
This does not replace the Board's non-delegable responsibility for approving the institution's tolerance for disruption, or the judgment of the operational risk professionals managing a live incident. What it can do is help the institution maintain the evidence trail and cross-functional visibility this regulation's obligations genuinely require.
Frequently Asked Questions
When does the Operational Risk Management Regulation take effect?
14 September 2026, one month after publication in the Official Gazette, per Article 20.1.
Does this regulation apply to insurance companies, or only banks?
It applies to all Licensed Financial Institutions that are juridical persons, explicitly including (Re)Insurance Companies and Other Financial Institutions, not banks alone.
What replaced the old Operational Risk Regulation?
The Operational Risk Management Regulation (C 1/2026) formally cancels and replaces Circular No. 163/2018 and its accompanying Operational Risk Standards (Article 19.1).
Who has to approve the Business Continuity Plan, can it be a Board committee?
The Board itself must approve the initial Business Continuity and Disaster Recovery Plans. The annual review thereafter may be delegated to a committee, but the Board must still review the plans directly at least every three years (Article 4.2).
How fast does an institution have to notify the Central Bank of an incident?
Within 4 hours for an event significantly affecting Critical Operations, with a 24-hour summary report to follow, and within 72 hours for any incident classified as high-risk (Article 15.2-15.3).
Does data have to be stored inside the UAE?
The Master System of Record, the data required to conduct all Critical Operations, must be continuously maintained and stored within the UAE, including where activities are outsourced, subject to a Central Bank-approved alternative for branches of foreign institutions (Article 8.9).
Explore how autoResilience can support your institution's operational resilience program.