CBUAE's New Operational Risk Rules: What Financial Institutions in the UAE Now Need to Put in Place
The CBUAE Operational Risk Management Regulation, Regulation C 1/2026, is now in force.
For UAE-regulated financial institutions, this is not simply another compliance document for the risk or compliance team to file away. The regulation brings Operational Risk and Operational Resilience into a framework that directly connects governance, cybersecurity, incident response, technology, business continuity, third-party risk and recovery.
The regulation became effective on 14 September 2026 and establishes minimum requirements for applicable Licensed Financial Institutions (LFIs). It replaces the earlier 2018 Operational Risk Regulation and Standards.
The practical message is straightforward:
Financial institutions need to be able to demonstrate that they can identify operational and cyber risks, protect Critical Operations, detect and respond to incidents, report significant events within the required timeframes, and recover from disruption.
The Defense Numerique research document summarises the shift in practical terms: policies alone are not enough; institutions need working services, controls, tools and regular testing, with meaningful reporting to the Board.
The CBUAE Operational Risk Management Regulation: What Has Changed?
Regulation C 1/2026 establishes minimum requirements for managing Operational Risk and Operational Resilience.
The official CBUAE Rulebook requires LFIs to maintain an Operational Risk management framework with strategies, policies, procedures, systems, controls and processes to identify, assess, monitor, report and mitigate Operational Risk. The framework must also be integrated with the institution’s broader risk-management and governance framework.
The change is important because operational risk is no longer something that can be viewed separately from technology and cybersecurity.
A cyber incident can interrupt payments.
A compromised account can affect customer services.
A ransomware event can affect records and critical applications.
A failed technology migration can interrupt operations.
A third-party outage can affect services that customers depend on.
The new framework therefore requires institutions to look at these risks together.
What does this mean for financial institutions?
It means a cybersecurity programme should connect with:
- Operational Risk
- Operational Resilience
- Business Continuity
- Disaster Recovery
- Incident Response
- Third-party risk
- Technology change management
- Internal controls
- Board-level risk reporting
This integrated approach is also reflected in the competitor research landscape. One competitor describes CBUAE compliance as an interconnected programme covering Operational Risk, Cybersecurity, Operational Resilience, Business Continuity, Third-Party Risk and Internal Controls rather than separate exercises.
Who Needs to Comply With CBUAE Regulation C 1/2026?
The attack surface of a business is not fixed.
It changes when the business:
- Launches a new website
- Adds a cloud service
- Opens a new office
- Connects a third-party platform
- Deploys a mobile application
- Creates a remote-access service
- Acquires another company
- Changes DNS records
- Adds APIs
- Moves workloads between cloud environments
The problem is that security documentation may not change at the same speed.
An asset can therefore remain online even after the business has stopped actively using it.
From an attacker’s perspective, an overlooked system may still be useful.
From the company’s perspective, it may not even appear on the security team’s list.
That gap is where External Attack Surface UAE concerns begin.
The Deadlines That Change Incident Response
One of the most important practical areas is incident notification.
For an Operational Risk event that significantly impacts, or may significantly impact, the continuity or integrity of Critical Operations, Article 15 requires notification to the CBUAE:
- Within 4 hours: Notify the CBUAE of the event and identify affected Critical Operations.
- Within 24 hours: Provide a summary covering the nature of the event, actions being taken, likely impact and expected timeframe for returning to normal operations.
- Upon return to normal operations: Notify the CBUAE that normal operations have resumed.
- Within 72 hours: Notify the CBUAE of a high-risk Incident, based on criteria defined in Board-approved policies.
The Defense Numerique source document highlights these same reporting windows and connects them directly with escalation paths, reporting templates and DFIR support.
Why Four Hours Is a Security Issue
Four hours can pass quickly during an incident.
A team may need to determine:
- What happened?
- Which systems are affected?
- Which Critical Operations are affected?
- How serious is the event?
- Who needs to be informed?
- What containment action is required?
- What information must be reported?
- Who is authorised to make the decision?
This cannot depend entirely on people figuring out the process during a crisis.
What should be in place?
Financial institutions should consider having:
- Clearly defined incident severity levels
- Escalation procedures
- Incident-response playbooks
- Regulatory notification procedures
- Defined decision-makers
- Contact lists
- Incident documentation
- Evidence-preservation procedures
- Tested response exercises
- Access to specialist DFIR support where required
What Financial Institutions Need to Implement
The most useful way to understand the new requirements is to connect each regulatory expectation with the capability needed to support it.
CBUAE Requirement | What Financial Institutions Need to Put in Place | Practical Cybersecurity Consideration |
Independent penetration testing of Critical Functions | Independent third-party testing programme | VAPT, penetration testing and appropriate red-team exercises |
Detection, response and situational awareness | Continuous security monitoring | Managed SOC, SIEM, EDR/XDR and threat intelligence |
Access control and identity management | Strong authentication and privileged-access controls | MFA, IAM and privileged access management |
Vulnerability testing and patch management | Continuous vulnerability management | Scanning, remediation tracking and retesting |
Retirement of outdated or unsupported systems | Technology lifecycle management | Asset inventory and technology lifecycle roadmap |
Master System of Record requirements | Data and system governance | Data classification, residency review and appropriate DLP controls |
Incident response | Tested incident-response capability | Playbooks, tabletop exercises and response support |
4/24/72-hour reporting | Predefined escalation and reporting workflow | Regulatory templates, escalation paths and DFIR support |
Recovery from permanent loss | Tested recovery capability | Immutable backups, ransomware recovery and DR testing |
Critical Operations mapping | Dependency mapping | Business impact analysis and dependency mapping |
Third-party due diligence | Vendor risk management | Third-party risk assessments and security reviews |
Major system changes | Independent assurance where applicable | External security assurance for major migrations and changes |
Board-approved risk appetite and reporting | Governance and GRC framework | CBUAE gap assessment and board-level reporting |
Staff training | Regular security awareness | Security awareness training and phishing simulations |
These implementation mappings come directly from the supplied Defense Numerique research document.
The important distinction is that the regulation establishes requirements, while the products and services used to meet those requirements should be selected according to the institution’s risk, environment and applicable obligations.
Independent Penetration Testing for Critical Functions
Penetration testing has a specific role under C 1/2026.
Article 7 requires periodic Operational Risk stress testing, and for Critical Functions the testing includes penetration testing by an independent third party, with results presented to the Board. The official regulation should be used to determine the exact applicability and testing requirements for the institution.
This is more than running an automated vulnerability scanner.
A meaningful testing programme should consider the institution’s actual technology environment.
Depending on the scope, testing may include:
- External infrastructure
- Web applications
- Mobile applications
- APIs
- Internal networks
- Cloud environments
- Authentication and access controls
- Systems supporting Critical Functions
A competitor analysis also identified an important practical issue: testing should be documented from scope through remediation and retesting, with clear records of what was tested and what remained outside scope.
What happens after the penetration test?
The report should not be the end of the process.
Financial institutions should have a process for:
Finding → Owner → Remediation → Retest → Evidence → Closure or approved risk decision
This makes the security testing programme much more useful for both management and regulatory review.
Detection, Response and Situational Awareness
The regulation requires LFIs to maintain an ICT and cybersecurity risk framework covering identification, assessment, mitigation, monitoring and testing of ICT and cybersecurity risks. It also requires appropriate infrastructure for current and projected business needs under normal and stressed conditions.
For a financial institution, that means knowing what is happening across the environment.
This may involve capabilities such as:
- Security monitoring
- SIEM
- EDR/XDR
- Threat intelligence
- Centralised logging
- Alert triage
- Incident investigation
- Security operations
The supplied Defense Numerique document maps the requirement for detection, response and situational awareness to 24/7 Managed SOC, SIEM, EDR/XDR and threat intelligence feeds.
However, technology alone does not create effective monitoring.
The institution also needs:
- Defined escalation rules
- Analysts or responsible teams
- Incident classifications
- Response procedures
- Investigation capability
- Management reporting
Access Control and Identity Management
A compromised identity can become an operational-risk problem when the account provides access to systems supporting Critical Operations.
The source document maps CBUAE access-control expectations to:
- Multi-factor authentication
- Identity and access management
- Privileged access management
For financial institutions, access controls should therefore be considered from both cybersecurity and operational-risk perspectives.
Questions worth asking include:
- Who has privileged access?
- Why do they need it?
- Is access reviewed regularly?
- Are privileged accounts protected with stronger authentication?
- Are former employees removed promptly?
- Are service accounts documented?
- Are excessive permissions identified?
- Can access be traced during an incident?
The goal is not simply to have an access-control policy.
It is to demonstrate that access is actually controlled.
Vulnerability Management and Patch Management
Vulnerability management is another area where financial institutions need an ongoing process rather than an occasional scan.
The Defense Numerique research document maps the CBUAE requirement to continuous vulnerability scanning with tracked remediation.
A practical vulnerability-management cycle should include:
Discover → Assess → Prioritize → Remediate → Retest → Report
Not every vulnerability carries the same operational significance.
A vulnerability affecting an internet-facing system supporting a Critical Operation may deserve different treatment from a low-risk issue on an isolated system.
This is why vulnerability management should connect with the institution’s risk framework.
Outdated and Unsupported Technology
Technology that is no longer supported can create problems for both cybersecurity and operational resilience.
C 1/2026 requires LFIs to manage ICT and cybersecurity risks, and the framework includes technology lifecycle considerations. The supplied research document specifically recommends an IT asset inventory and technology lifecycle roadmap for systems that need to be retired.
A useful lifecycle review should identify:
- What systems exist?
- Who owns them?
- Which business process depends on them?
- Are they supported?
- Are they still required?
- What risks arise from keeping them?
- What is the replacement or retirement plan?
Replacing legacy systems is not always immediate.
But the risk should be known, documented and managed.
Master System of Record and Data Governance
The supplied research document identifies requirements around the Master System of Record and maps them to data classification, data residency review and data loss prevention.
For financial institutions, data governance should answer basic but important questions:
Where is critical information stored?
Who can access it?
Which systems depend on it?
Where is the data processed?
Which third parties can access it?
What happens if the system becomes unavailable?
These questions become especially important when critical operations rely on cloud platforms, outsourced services or interconnected applications.
Incident Response and Recovery
C 1/2026 requires LFIs to maintain Incident Response and Recovery Plans for relevant operational-risk events, with appropriate testing and updating. The official framework also connects incident management with Operational Resilience.
The supplied Defense Numerique document recommends:
Incident-response plans
Incident-response playbooks
Tabletop exercises
Incident-response retainers
An incident register
Why tabletop exercises matter
A tabletop exercise allows teams to walk through a realistic scenario before an actual crisis occurs.
For example:
09:00 — Suspicious activity detected
↓
09:15 — Critical system identified
↓
09:30 — Incident classified
↓
10:00 — Senior management informed
↓
Response team activated
↓
Regulatory reporting process initiated
The purpose is not to simulate every technical action.
It is to find decision-making and coordination gaps.
Ransomware Recovery and Disaster Recovery
A backup is not automatically a recovery strategy.
Financial institutions should understand how they will recover when critical technology or data is unavailable or compromised.
The supplied research document maps recovery from permanent asset loss and annual testing to:
- Immutable backups
- Ransomware recovery capability
- Tested disaster recovery plans
- Clear recovery targets
Recovery planning should connect with Critical Operations.
The key question is:
Which services must be restored first, and what technology, data and people are required to restore them?
This is where cybersecurity, business continuity and disaster recovery teams need to work together.
Mapping Critical Operations and Their Dependencies
Operational resilience starts with understanding what the institution must keep running.
Article 3 requires LFIs to identify Critical Operations and the assets required to deliver them, including people, technology, processes, data, facilities and third-party service providers, together with their interdependencies.
The practical exercise can be represented as:
Critical Operation → Process → Technology → Data → People → Facility → Third Party
For example, a critical customer-facing service may depend on:
- An application
- Authentication infrastructure
- Databases
- Network connectivity
- Cloud infrastructure
- Employees
- A technology vendor
If one dependency fails, the operation may be affected.
That is why dependency mapping should be part of resilience planning rather than treated as a simple IT inventory.
Third-Party Risk Management
Financial institutions often depend on external providers for important technology and business services.
C 1/2026 requires LFIs to assess, monitor and manage third-party risk. The official regulation requires appropriate risk assessment and due diligence before entering third-party arrangements, with specific resilience expectations where Critical Operations are involved.
The supplied Defense Numerique document maps this requirement to:
- Third-party risk assessments
- Vendor security reviews
A vendor assessment should consider more than whether a supplier has a security certificate.
Depending on the relationship, the institution may need to understand:
- What systems the vendor can access
- What information the vendor handles
- Whether the vendor supports a Critical Operation
- Security testing evidence
- Incident notification procedures
- Business continuity
- Disaster recovery
- Subcontractors
- Access management
- Remediation history
A competitor review also highlights that third-party oversight should change when the vendor’s access, technology, subcontractors, data or role in Critical Operations changes.
Major System Changes and Independent Assurance
Operational resilience starts with understanding what the institution must keep running.
Article 3 requires LFIs to identify Critical Operations and the assets required to deliver them, including people, technology, processes, data, facilities and third-party service providers, together with their interdependencies.
The practical exercise can be represented as:
Critical Operation → Process → Technology → Data → People → Facility → Third Party
For example, a critical customer-facing service may depend on:
- An application
- Authentication infrastructure
- Databases
- Network connectivity
- Cloud infrastructure
- Employees
- A technology vendor
If one dependency fails, the operation may be affected.
That is why dependency mapping should be part of resilience planning rather than treated as a simple IT inventory.
Board-Approved Risk Appetite and GRC
The Board has ultimate responsibility for ensuring that the LFI has an adequate Operational Risk management framework and must approve and review key Operational Risk and Operational Resilience strategies and policies at least annually.
This makes Board-level reporting an important part of compliance.
The supplied document maps Board-approved risk appetite and regular reporting to a GRC gap assessment against C 1/2026 and board-level risk reporting.
A Board report should not be a collection of technical security metrics.
It should answer:
- What are our most important operational risks?
- Which Critical Operations are exposed?
- Which controls are not working as expected?
- What high-risk findings remain open?
- What incidents occurred?
- What is management doing about them?
- What risks are being accepted?
- Where is Board action required?
This is where a structured GRC consulting UAE approach can help translate technical findings into business-level risk information.
Regular Staff Training
Operational resilience starts with understanding what the institution must keep running.
Article 3 requires LFIs to identify Critical Operations and the assets required to deliver them, including people, technology, processes, data, facilities and third-party service providers, together with their interdependencies.
The practical exercise can be represented as:
Critical Operation → Process → Technology → Data → People → Facility → Third Party
For example, a critical customer-facing service may depend on:
- An application
- Authentication infrastructure
- Databases
- Network connectivity
- Cloud infrastructure
- Employees
- A technology vendor
If one dependency fails, the operation may be affected.
That is why dependency mapping should be part of resilience planning rather than treated as a simple IT inventory.
What Happens If the Institution Is Not Prepared?
The supplied Defense Numerique research document highlights the seriousness of the supervisory consequences, including potential fines and actions affecting Board members and senior management.
The official CBUAE framework also provides supervisory and enforcement mechanisms.
But regulatory consequences are only one part of the problem.
Poor operational-risk preparation can also affect:
- Customer services
- Payments
- Data availability
- Business continuity
- Incident response
- Recovery
- Third-party services
- Management decision-making
The bigger concern is whether an institution can continue operating safely when a serious disruption occurs.
Start With a CBUAE Compliance Gap Assessment
For many financial institutions, the most practical starting point is not buying another security product.
It is understanding the current gap.
The supplied research document recommends a gap assessment to establish where the institution already meets the regulation, where gaps exist and which gaps should be addressed first.
A structured assessment can follow:
Requirement → Applicability → Existing Control → Evidence → Gap → Risk → Remediation → Validation
Step 1: Identify applicable requirements
Map C 1/2026 requirements to the institution’s licence, activities, Critical Operations and risk profile.
Step 2: Review existing controls
Identify policies, technology, processes and responsibilities already in place.
Step 3: Identify evidence
Ask whether the institution can demonstrate that the control actually operates.
Step 4: Record gaps
Document what is missing, incomplete or ineffective.
Step 5: Prioritize
Consider Critical Operations, risk exposure, regulatory importance and business impact.
Step 6: Assign ownership
Every remediation item should have a responsible owner and target date.
Step 7: Validate
Retest or reassess important controls after remediation.
This creates a compliance programme that can be maintained rather than a one-time audit exercise.
How Defense Numerique Can Support CBUAE Compliance
Defense Numerique supports financial institutions across the UAE with cybersecurity services relevant to the operational-risk and resilience areas covered by C 1/2026. The supplied company research document specifically identifies independent VAPT and red teaming, Managed SOC with SIEM and EDR/XDR, GRC gap assessments, incident-response planning and tabletop exercises, DFIR support, ransomware recovery and third-party risk reviews.
The important point is that these services should support the institution’s regulatory and risk programme rather than replace it.
VAPT and Penetration Testing
Independent testing can help identify weaknesses in systems supporting critical functions and provide evidence for remediation.
VAPT Service: https://defense-numerique.io/vulnerability-assessment-and-penetration-testing-dubai/
Penetration Testing Service: https://defense-numerique.io/penetration-testing-in-uae/
Managed SOC, SIEM and EDR/XDR
Security monitoring can provide continuous visibility into suspicious activity and support faster detection and escalation.
Incident Response and DFIR
Incident-response planning, tabletop exercises and DFIR support can help institutions prepare for serious events and the associated reporting and investigation requirements.
Incident Response: https://defense-numerique.io/incident-response-in-cybersecurity-dubai/
Digital Forensics: https://defense-numerique.io/digital-forensic-services-in-dubai/
GRC Gap Assessment
A structured GRC assessment can map C 1/2026 requirements to existing controls, identify gaps and establish a practical remediation roadmap.
GRC Consulting: https://defense-numerique.io/governance-risk-and-compliance-services-in-dubai/
Ransomware Recovery
Recovery planning and testing can help institutions prepare for scenarios involving loss or compromise of critical technology assets.
Ransomware Recovery: https://defense-numerique.io/ransomware-protection-solutions-in-dubai/
Third-Party Risk Reviews
Third-party assessments can help financial institutions understand security and resilience risks associated with vendors supporting important business services.
A Practical CBUAE Readiness Checklist
Before considering the implementation programme mature, financial institutions should be able to answer yes to the following:
- Have we identified the CBUAE requirements applicable to our institution?
- Have we identified our Critical Operations?
- Have we mapped the technology, people, data, processes and third parties supporting them?
- Is cybersecurity integrated with Operational Risk and Operational Resilience?
- Are our cybersecurity controls regularly tested?
- Is independent penetration testing included for relevant Critical Functions?
- Can we detect and escalate serious incidents quickly?
- Can we meet the applicable 4-hour, 24-hour and 72-hour reporting requirements?
- Are our Incident Response and Recovery Plans tested?
- Do we have effective third-party risk processes?
- Are major technology changes subject to appropriate assurance?
- Are outdated systems identified and managed?
- Does the Board receive meaningful risk information?
- Can we produce evidence of control operation and remediation?
- Are staff trained to recognize and report security incidents?
If several answers are uncertain, a structured gap assessment is a sensible starting point.
FAQ's
Tags :
Blog
Follow Us :
