Operational Resilience Obligations for BFSI Institutions in the UAE

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.

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

The Requirements, Article by Article

Article 2 — Operational Risk Management Framework. Every 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 Resilience. The 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 Board. The 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 Management. Requires 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 Management. Institutions 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 Planning. Requires 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. This article is covered in depth in this series' dedicated Business Impact Analysis pillar page.

Article 12 — Change Management. Material 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 Management. Requires 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. This article is covered in depth in this series' dedicated developer and third-party risk management pillar page.

Article 15 — Notification and Reporting Requirements. Sets 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 Requirements. Institutions 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

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

Practical Example: A Payment System Outage, Start to Notification

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

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 on — get 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 statement before treating any RTO or RPO as final.
• Build the 4-hour notification decision into monitoring systems in advance, so the question "does this qualify" is already answered before an incident occurs.
• Confirm Master System of Record residency now, including for any outsourced or cloud-hosted arrangements, rather than assuming existing infrastructure already complies.
• Include material Third-Party Service Providers in annual BCP/DR testing, not just internal systems.
• Prepare the public disclosure required under Article 16 well before the effective date, rather 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

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

1. Complete or refresh the Critical Operations mapping under Article 3.4, involving every business line that touches a candidate Critical Operation.
2. Bring the tolerance-for-disruption statement to the Board with genuine scenario-based analysis, not a generic risk appetite restatement.
3. Audit Master System of Record residency across all Critical Operations, including outsourced and group-shared systems.
4. Review and, where needed, rebuild Incident Response and Recovery Plans to meet the full lifecycle requirements of Article 9.4.
5. Schedule BCP/DR testing for all Critical Operations, including relevant Third-Party Service Providers, ahead of the effective date.
6. Build the incident notification workflow to meet the 4-hour/24-hour/72-hour timelines under Article 15, including clear internal escalation triggers.
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.

Explore how autoResilience can support your institution's operational resilience program.

Related Resources

• CBUAE Rulebook — Operational Risk Management Regulation (C 1/2026), full text
• Internal: Business Impact Analysis for trust and agency operations at regional banks (deep dive on Article 11)
• Internal: Developer risk management for real estate lending banks (deep dive on Article 13's adjacent counterparty risk discipline)
• autoResilience GRC platform — Critical Operations, BCP, and incident management

Frequently Asked Questions