An institution that has run an operational risk framework for years, with a loss database, a risk and control self-assessment cycle and a Board-approved appetite statement, has met the first half of what the Central Bank of the UAE now requires. The second half is a different question, and most frameworks were never built to answer it: if the thing you cannot afford to stop doing stopped tomorrow, could you keep doing it anyway, and can you show the regulator the map that proves it?
The Operational Risk Management Regulation, Circular 1 of 2026, is effective from 14 September 2026 and applies to every Licensed Financial Institution that is a juridical person: banks, finance companies, exchange houses, payment institutions and insurers alike. It is a new instrument issued under the 2025 Central Bank Law rather than an amendment to what came before, and it is worth reading as one, because the shape of it is different. Operational risk is defined in Article 1.19 in the familiar terms, loss from inadequate or failed processes, people and systems or from external events. Operational resilience is defined separately in Article 1.18, as the ability to deliver Critical Operations through disruption, and required separately in Article 3. An institution needs a framework for the first and a strategy for the second, integrated with each other.
That distinction is the whole regulation in miniature. A programme that records and manages events, however well, addresses Article 2. It says nothing about Article 3 until it can name what is critical, trace what each critical thing depends on, and state how long the institution can tolerate its absence.
The map that everything else refers to
Article 3.4 requires each institution to identify its Critical Operations and every asset required to deliver them: the people, technology, processes, data, facilities and third-party providers, including intragroup entities, and the interconnections among them. This has to be formalised in a mapping for each Critical Operation and updated as part of change management.
Three things are critical by definition under Article 3.5: payment systems and other time-critical customer services; the ability to maintain accurate and current financial records; and the ability to measure and manage solvency and liquidity, including exposure to all material risks. The Central Bank may designate more.
The map is not one requirement among sixteen articles. It is the spine. The business continuity plans must leverage and refer to it (Article 11.2). Incident management must cover every resource it names (Article 9.5). Third-party risk must be reflected in it (Article 13.10). Change management must assess the impact on it before any change to a Critical Operation goes ahead (Article 12.3.9). An institution that builds the map properly has done the structural work for four other articles at once. An institution that treats it as a form to complete will find every later article asking a question the form cannot answer.
The regulation does not ask whether the institution has a business continuity plan. It asks whether the plan traces back to a map of what the institution cannot afford to stop doing, and whether that map is current.
Who has to decide, and how often
The regulation is specific about which body approves what, and it moves several decisions up a level.
Under Article 4.2 the Board, and not a Board committee, must approve and review at least annually three things: the risk appetite and tolerance statement for operational risk, with its limits and thresholds; the institution’s tolerance for disruption, considered against a broad range of severe but plausible scenarios affecting Critical Operations, including what the Board’s policy says should happen when capabilities fall short of that tolerance; and the business continuity and disaster recovery plans. The annual review of the plans may be delegated to a committee, but the Board approves them initially and reviews them itself at least every three years.
Tolerance for disruption is the item most Boards have never been asked to set. It is not a general statement of risk appetite. It is a defined answer to how long a specific Critical Operation can be unavailable before the harm becomes unacceptable, and under Article 11.8 it has to flow through to measurable recovery time and recovery point objectives in the continuity plans. A Board that has approved a continuity plan without approving the tolerance it was built to has approved the answer without stating the question.
Two further governance requirements land at the same level. Senior management must report breaches of the operational risk appetite or tolerance to the Board itself rather than to a committee (Article 5.4). And institutions designated as systemically important must have a Board operational risk committee (Article 4.9), which the Central Bank may also require of others.
A report that changes its audience
Article 5.6 requires senior management, at least annually for banks and insurers, to assess the internal control system and formalise that assessment as a report on internal control. The report describes the key control measures for all material processes related to Critical Operations, the assessment itself, and the measures taken or planned to improve the system. It is presented to the Board and provided to the Central Bank.
That last clause is the change. Many institutions already produce something like this document for the audit committee. It was an internal artefact, written in an internal register, and its weaknesses were discussed internally. It is now a regulatory submission, and the standard of evidence behind each stated control has to survive a supervisor reading it as one. The ICOFR discipline of documenting control design, testing operating effectiveness and classifying deficiencies is the closest existing practice, and it is the right one to borrow.
The control system, and two requirements new in kind
Article 7 sets out the internal control system in four components: risk assessment, control activities, monitoring, and information and communication. It covers all activities including those relying on third parties, and names the control measures a supervisor will expect to see, among them segregation of duties, dual control, limit monitoring, safeguards over assets and data, reconciliations, and a mandatory minimum-leave policy for staff.
Two requirements have no direct equivalent in the practice most institutions inherited.
The first is a process universe (Article 7.8): a register of all processes, each with a named process owner and a named risk owner. Institutions that have run a risk and control self-assessment tend to have something like a process list; the regulation requires it to be complete, maintained, and to assign accountability at the level of each process.
The second is a standing automation review (Article 7.7). Processes and controls that involve manual intervention must be periodically evaluated for whether they can be automated. Conversely, automated controls must be periodically tested for the accuracy and effectiveness of the automation, with the related technology risk managed. The regulation treats a manual control as a choice that needs justifying, and an automated one as a dependency that needs testing.
Article 7.13 requires periodic stress testing of operational risk, including exercises that challenge the control environment, with penetration testing named as an example, across ICT, physical and people-dependent controls. Under Article 7.14, for Critical Functions the penetration test must be performed by an independent third party and the results presented to the Board. An internal red team, however capable, does not satisfy the requirement for the functions that matter most.
Technology concentration and the third-party question
The digital-first institution’s exposure is less to a failed process than to a failed dependency: a cloud provider, a payment rail, a core system vendor, an API partner. Where a branch-era framework saw a single vendor risk in a single category, the digital institution has a small number of dependencies on which most Critical Operations rest at once.
Article 13 addresses this directly and in more demanding terms than the market has been used to. Institutions must not overly rely on outsourcing and must maintain sufficient staff, expertise and resources of their own to perform and manage the activities they are licensed for (Article 13.2). Before any arrangement, a risk assessment and due diligence (Article 13.3). For anything relating to Critical Operations, verification that the provider has at least equivalent operational resilience (Article 13.4). And a notice of non-objection from the Central Bank before outsourcing any activity whose disruption could significantly affect Critical Operations (Article 13.5).
The contractual requirements in Articles 13.6 to 13.8 are worth reading against existing vendor agreements: data ownership and confidentiality, termination rights, the institution’s right to inspect records and receive audit and risk reports, the provider’s obligation to comply with Central Bank requests including on-site examination, and flow-down of all of it to subcontractors who touch the institution’s or its customers’ data.
Substitutability is the test that exposes concentration. A provider that could not be replaced in time, at acceptable cost and risk, is a dependency the continuity plan has to name as such, and Article 13.12 gives the Central Bank the power to require an arrangement discontinued, or a Critical Operation that is over-reliant on one discontinued, at its discretion.
Continuous access and the API surface
Open banking, embedded finance and API integrations create a risk surface that is continuously live rather than periodically reviewed. A framework built around point-in-time control testing meets an exposure that changes with every deployment on either side of the interface.
The regulation’s answer runs through change management. Article 12 requires a resourced change process with the operational risk function involved throughout, and twelve minimum considerations for any change in operations. For changes material to Critical Operations, Article 12.5 requires thorough testing before implementation, a rollback plan, a parallel run of old and new systems where one replaces another, an independent external expert’s assurance report, notification to the Central Bank with that report at least 30 calendar days before implementation, and a written no-objection before go-live.
For an institution that ships changes to customer-facing systems weekly, the practical question is which of those changes are material to Critical Operations and which are not. That classification has to be made deliberately, documented, and defensible, because the consequence of getting it wrong is a change that went live without a no-objection the regulation required.
Article 8 sits underneath all of this. The ICT and cybersecurity framework must address nine minimum policy areas, the institution must keep a strategy and timeline for retiring obsolete and unsupported systems, and under Article 8.9 the Master System of Record, all data required to run Critical Operations, must be continuously maintained and stored within the UAE, outsourcing included. Foreign branches may hold an up-to-date copy in the UAE with the Central Bank’s approval.
The clock
Article 15 sets the notification timetable, and it is the part of the regulation that will be tested first, because incidents do not wait for frameworks to mature.
| Trigger | Deadline |
|---|---|
| Significant deviation from the Board-approved appetite, policies or tolerance for disruption | Promptly |
| An event that significantly affects, or may significantly affect, Critical Operations, or is likely to trigger the continuity plans, or materially affects customers, operations, profit or capital | Within 4 hours: notify the Central Bank, naming the affected Critical Operations |
| The same event | Within 24 hours: summary of the nature of the event, actions being taken, likely impact and time to normal |
| The same event | On return to normal operations: notify |
| Any high-risk incident, on criteria set in Board-approved policy | Within 72 hours |
Four hours is short enough that it cannot be met by a process that starts when someone decides the event is serious. It requires that the incident classification criteria in Article 9.4.1 are already defined, that the communication plan in Article 9.4.4 already names who calls the Central Bank and with what, and that the path has been rehearsed. Article 9.2 also requires root-cause analysis of every material incident and measures to prevent recurrence, with the effectiveness of that process itself measured and reviewed. An incident register that records what happened but not why, and not what changed as a result, does not meet it.
Islamic institutions
Article 14 applies to Islamic financial institutions and gives Sharia non-compliance risk a formal place in the operational risk framework. It requires a Sharia governance framework and compliance with the Higher Sharia Authority’s resolutions; a dedicated framework, systems, controls and limits for Sharia non-compliance risk; testing of how that risk interacts with other risks across the life of a contract; and separate accounts for restricted and unrestricted investment accounts and Takaful funds.
Two provisions have direct operational consequences. Article 14.4 requires a formal record of income not recognised because of Sharia non-compliance, reported regularly to the internal Sharia supervision committee. And Article 14.5 makes that committee the sole authority on whether a non-compliance event has materialised, with the risk function responsible for identifying potential events, assessing likelihood and severity, and disclosing them. The record and the reporting line have to exist before the first event, not after it.
What the remaining time is for
The regulation is effective in two days and its text grants no implementation period. Reading across the sixteen articles, eight artefacts have to exist for a supervisor to find the framework defensible:
- The Critical Operations map with every dependency (Article 3.4)
- The Board-approved tolerance for disruption and the scenarios it was tested against (Article 4.2.2)
- The process universe with named owners (Article 7.8)
- The incident register and the most recent root-cause analysis (Articles 9.4.5 and 9.2)
- The report on internal control provided to the Central Bank (Article 5.6)
- The most recent independent penetration test of Critical Functions and the Board minute recording it (Article 7.14)
- The outsourcing register and the exit plan for the largest dependency (Articles 13.9 and 13.11)
- Evidence that the four-hour notification path has been rehearsed (Article 15.2)
A programme that can produce those eight, with dates and owners, has met the regulation in substance. Most programmes built to the previous standard have two or three of them, and the ones missing are usually the map, the tolerance and the exit plans, which are also the ones that take longest to build because they require the business, technology and third-party owners in the same room. That is the work to start with.
This article reflects the position as at 12 September 2026, against the CBUAE Operational Risk Management Regulation, Circular 1 of 2026, effective 14 September 2026, as published on the CBUAE Rulebook. Article references are to that regulation. The Central Bank may issue standards or guidelines that elaborate on it, and specific requirements should be confirmed against the Rulebook and any subsequent circulars. Nothing here constitutes legal advice.