On 14 September 2026, the Central Bank of the UAE's new Operational Risk Management Regulation came into force, sharpening expectations on how licensed banks and financial institutions manage resilience against outages, fraud, cyberattacks, and other operational disruptions. Coverage of the rollout has centred on a familiar-sounding but genuinely tightened obligation: institutions must be able to detect a significant disruption to a critical business service and notify the Central Bank within hours, not days.
Read narrowly, that sounds like an internal IT and business-continuity matter. Read correctly, it is not. Almost every critical banking service today — payments processing, core banking infrastructure, cloud hosting, customer onboarding, fraud detection, contact-centre operations — runs, in whole or in part, through a third party. A regulation built around the resilience of a service, rather than the internal-versus-external origin of a disruption, pulls the entire third-party ecosystem behind that service directly into scope. For third-party risk management (TPRM) and operational resilience teams that have historically run as separate functions with separate owners, that is the real story here.
Crest's TPRM platform gives risk and resilience teams a single, continuously updated view of vendor dependencies, criticality, and exposure — built for exactly this kind of cross-functional question.
See the PlatformWhat the New Regulation Actually Requires
The CBUAE's Operational Risk Management Regulation sits within the Central Bank's broader rulebook and is framed around outcomes rather than a checklist of internal controls. Institutions are expected to identify their critical business services, understand the people, processes, systems, and third parties that support each one, and demonstrate they can detect and respond to a disruption fast enough to protect customers and the wider financial system. Reporting on the rollout has flagged a materially shortened incident-notification window as one of the regulation's most operationally demanding requirements — a shift from a compliance posture built around periodic reporting toward one built around real-time detection.
This regulation does not replace the CBUAE's existing Outsourcing Regulation for Banks, which continues to govern due diligence, contractual terms, and approval thresholds for formal outsourcing arrangements. The two now need to be read together. Outsourcing regulation tells a bank who its vendors are and what they have contractually promised. Operational risk regulation asks a harder question: regardless of where a disruption originates, can the bank detect it, understand its impact on a critical service, and report it within the window the regulator now expects — and that question does not stop at the boundary of what technically qualifies as an "outsourcing arrangement." A cloud subprocessor two layers removed from the primary contract, a payment gateway, or a fraud-analytics vendor can all sit behind a critical service without ever appearing on a formal outsourcing register.
Importantly, this UAE move is not occurring in isolation. Operational resilience requirements with a similar third-party dimension have been strengthening globally — from the EU's Digital Operational Resilience Act (DORA) to the Basel Committee's Principles for Operational Resilience, and equivalent expectations from supervisors such as the UK's FCA and PRA. UAE banks with regional or international operations should expect these frameworks to increasingly converge on the same underlying expectation, one that professional bodies such as ISACA have also written about in the context of continuous control assurance: resilience is a property of the service, not of any single entity delivering it.
Why Third-Party Risk Has Been a Blind Spot in Operational Resilience
Most banks already run a TPRM programme. Most also already run an operational resilience or business continuity function. The problem is rarely a missing capability — it is that the two have historically answered different questions, owned by different teams, on different cycles.
TPRM programmes are typically built around onboarding due diligence and periodic reassessment: is this vendor financially sound, does it hold the right certifications, has it passed a security questionnaire. Operational resilience programmes are typically built around the bank's own critical services, systems, and continuity plans, with vendors appearing as a line item — "outsourced" or "not outsourced" — rather than as a dependency to be actively monitored for real-time risk signals. Neither view, on its own, answers the question the new regulation actually asks: if this specific vendor fails right now, which critical service breaks, and can we detect and report that within the required window?
Closing that gap requires connecting three things that usually live in separate systems — the critical-service inventory maintained by resilience teams, the vendor register maintained by procurement and TPRM, and the incident-management workflow that feeds regulatory reporting. Institutions that treat this as a documentation exercise, rather than a live operational connection, will likely discover the gap during an actual incident rather than during a supervisory review — which is precisely the scenario the regulation is designed to prevent.
Purpose-built TPRM agents can classify vendors by resilience criticality, watch for financial, cyber, and adverse-media signals continuously, and surface material change long before it becomes a reportable incident. See how Agentic AI applies to vendor risk operations.
Explore Agentic AIAn Eight-Point Framework for Third-Party Operational Resilience
The following chain reflects how a critical business service actually breaks — and where a control needs to sit at each link to catch the failure before it becomes a reportable incident.
Critical Process → Continuous Monitoring
- Critical Process: Identify the business services the bank cannot afford to lose, and the recovery-time objective each one carries.
- Third Party: Map every vendor supporting that process, including subcontractors and subprocessors beyond the primary contract.
- Technology/Data Dependency: Understand which systems, data flows, and infrastructure the third party actually touches.
- Risk: Assess concentration, substitutability, and single-point-of-failure exposure — not just the vendor's own security posture.
- Control: Define the specific control — contractual, technical, or monitoring-based — that mitigates each identified risk.
- Incident: Establish a tested path for vendor-reported incidents to reach the bank's own incident-management process immediately.
- Impact: Translate a vendor incident into its effect on the specific critical service and customer population affected.
- Management Action & Continuous Monitoring: Escalate, remediate, and keep watching — resilience is demonstrated continuously, not certified once a year.
The chain matters because a regulator reviewing an incident will not stop at "was the vendor certified." The relevant question is whether the bank could trace, in real time, from a third-party event to its impact on a named critical service — and whether that trace happened fast enough to meet the reporting obligation.
A Six-Step Playbook for Getting There
This is deliberately sequenced as a build-out, not a one-time compliance sprint — each step depends on the one before it, and the programme should keep running after step six, not stop there.
Map Critical Services to Third Parties
Start from the bank's critical-service inventory, not the vendor register, and trace outward to every third party — including subprocessors — that supports each service.
Classify by Resilience Criticality
Re-tier vendors by concentration and substitutability risk to a critical service, not only by annual spend — a low-value vendor can sit behind a high-impact process.
Connect Incidents to Regulatory Reporting
Build a tested, direct path from vendor-reported incidents into the bank's own regulatory-notification workflow, with named owners and clear escalation timers.
Extend Continuity and Exit Planning
Bring third-party concentration explicitly into business continuity plans and exit strategies, and test them through severe-but-plausible scenarios, not paper exercises alone.
Move to Continuous Monitoring
Replace point-in-time due diligence with ongoing tracking of vendor financial health, cyber exposure, adverse media, and operational signals for every critical-tier vendor.
Maintain an Audit-Ready Evidence Trail
Keep dependency maps, criticality tiers, incident-response test results, and monitoring outputs current and retrievable for supervisory review at any time.
Where Agentic AI Fits Without Removing the Human Decision
The volume problem here is real. A mid-sized bank can easily run several thousand third-party relationships across payments, technology, professional services, and facilities — far more than any team can continuously watch by hand for the kind of early-warning signal that operational resilience regulation now demands.
This is where AI-driven orchestration earns its place, provided it stays in a clearly bounded role. AI agents can continuously ingest financial filings, cyber-exposure signals, adverse media, and regulatory actions across a vendor portfolio, and flag material change against each vendor's resilience-criticality tier — surfacing the handful of signals that actually matter out of thousands of daily data points. AI-assisted evidence collection can pull the specific contract clauses, subprocessor lists, and prior incident records a risk team needs the moment a vendor event occurs, instead of that research starting only after the clock has begun. Conversational AI workflows can run scheduled check-ins with vendor relationship owners to confirm subprocessor changes or incident-readiness status between formal reassessment cycles.
None of this replaces the human judgment a regulator will ultimately hold the bank accountable for. Human-in-the-loop governance — a named risk owner reviewing the AI-surfaced signal, deciding materiality, and authorising escalation — remains the control that matters. What AI-led vendor engagement changes is how much of the routine detection and evidence-assembly work happens before a human needs to look at it, which is exactly the compression operational resilience regulation is forcing onto TPRM programmes that were built for annual cycles, not hourly ones.
Executive Takeaways
- Operational resilience regulation now reaches third parties by design, not by extension. A regulation built around the resilience of a critical service automatically covers whoever delivers that service, contracted or not.
- Outsourcing regulation and operational risk regulation now need to be read together — one governs the relationship, the other governs the bank's ability to withstand its failure.
- The reporting clock is the hardest new constraint. A vendor's own incident-notification terms are not a substitute for a tested, direct path into the bank's regulatory-reporting workflow.
- Criticality tiering needs to shift from spend-based to resilience-based — a small vendor behind a critical process is a bigger risk than a large vendor behind a peripheral one.
- Continuous monitoring is no longer a TPRM upgrade — it is close to a regulatory requirement once resilience is measured in hours rather than annual review cycles.
Crest Perspective
The UAE’s regulatory landscape is unique in its dual-jurisdiction structure: mainland CBUAE rules and the separate DFSA and ADGM frameworks for the financial free zones. A vendor relationship compliant under CBUAE guidance may face additional scrutiny under DFSA requirements if the same vendor serves DIFC entities. TPRM programmes serving UAE institutions need to map vendor relationships against both frameworks simultaneously, not sequentially.
Frequently Asked Questions
The Central Bank of the UAE's Operational Risk Management Regulation, which came into force on 14 September 2026, requires licensed financial institutions to identify, assess, and manage operational risk across the full set of processes, systems, and relationships that support critical banking services — not just internal operations. Because most banks now run core functions such as payments processing, cloud infrastructure, customer onboarding, fraud detection, and IT support through external providers, the regulation effectively pulls third-party dependencies into the same resilience perimeter as internal systems. Institutions are expected to map which critical business services rely on which third parties, understand the concentration and substitutability risk this creates, and demonstrate that incidents originating with a vendor are detected, escalated, and reported within the same tight timeframes that apply to internally-caused disruptions.
The Outsourcing Regulation for Banks governs the lifecycle of a formal outsourcing arrangement — due diligence before signing, contractual clauses, approval thresholds for material outsourcing, and ongoing oversight of the outsourced service. The Operational Risk Management Regulation is broader and outcome-focused: it asks whether the bank's critical business services remain resilient regardless of where a disruption originates, including from providers that may not meet the formal definition of an "outsourcing arrangement" at all, such as a cloud subprocessor, a payment gateway, or a data or analytics vendor several layers removed from the primary contract. In practice, the two regulations now need to be read together — outsourcing due diligence tells you who your vendors are and what they promised; operational risk management tells you whether your bank can actually withstand it if one of them fails.
Coverage of the regulation's rollout has highlighted a tightened incident-notification window — commonly summarised as requiring banks to report significant operational disruptions to the Central Bank within hours rather than days. Because the regulation is framed around the resilience of critical business services rather than the internal-versus-external origin of a disruption, an outage, breach, or fraud event that originates at a third party and affects a critical service falls within the same notification clock as an internally-caused incident. This is precisely the gap most TPRM programmes are not built to close today: a vendor incident-notification clause in a contract is not the same thing as a bank's own regulatory reporting clock, and the two need to be connected operationally, not just contractually, well before an incident happens.
Five actions matter most in the near term. First, map critical business services to the specific third parties, subprocessors, and technology dependencies that support them, not just the primary contracted vendor. Second, classify third parties by criticality to resilience rather than by spend, since a low-value vendor can still sit behind a critical process. Third, build a direct escalation path from vendor-reported incidents into the bank's own regulatory-reporting workflow, tested through tabletop exercises. Fourth, extend business continuity and exit planning to cover vendor concentration and substitutability, not only the bank's own systems. Fifth, move from point-in-time vendor due diligence toward continuous monitoring of vendor operational, financial, and cyber posture, since a resilience obligation that resets only at annual reassessment cannot support hour-scale incident reporting.
Operational resilience regulation is fundamentally forward-looking — it asks whether an institution can detect and respond to a disruption as it happens, not whether it passed a due-diligence review months earlier. A questionnaire completed at onboarding, or even an annual reassessment, cannot tell a bank that a critical vendor's infrastructure provider changed, that a subprocessor experienced a breach last week, or that a vendor's financial position has deteriorated to the point of business-continuity concern. Continuous monitoring — tracking vendor financial health, cyber exposure, adverse media, regulatory actions, and operational signals on an ongoing basis, with AI-assisted triage to separate material change from noise — gives risk and resilience teams a live picture of third-party exposure that a static assessment simply cannot, which is what a regulation built around real-time incident reporting actually requires.