Governance and Policy ManagementCBUAE Operational Risk Regulation: Cyber Resilience and Incident Reporting
Cyber risk reporting becomes useful when the number presented to management can be traced back to what is happening across the bank.
A dashboard might show vulnerability exposure as “moderate.” Another report may state that critical systems are within risk appetite. Yet the regulator can still ask harder questions: Which systems produced that result? How current is the evidence? What exceptions remain open? Who accepted the residual risk?
That is the challenge behind CBUAE CRIR compliance and wider cyber risk reporting for UAE financial institutions. The objective is not simply to produce another regulatory report. Banks need a repeatable process for collecting cyber risk information, validating it and showing how the results influence decisions.
This requirement has become more important under the CBUAE’s Operational Risk Management Regulation C 1/2026, effective from 14 September 2026. Licensed Financial Institutions must maintain an ICT and cybersecurity risk framework within their wider Operational Risk and Operational Resilience approach. The regulation requires ongoing identification, mitigation, monitoring and testing of ICT and cyber risk.
Who It Covers
The regulation applies to all Licensed Financial Institutions that are juridical persons. The Rulebook’s definition covers banks, (re)insurance companies, and other financial institutions, including UAE branches or subsidiaries of institutions incorporated abroad and entities in financial free zones.
The regulation sets minimum requirements. The Rulebook’s introduction reserves the CBUAE’s right to impose additional requirements where it lists items “at a minimum,” and to issue standards or guidelines that elaborate on the text, so institutions should treat it as a floor and watch for further guidance.
The Reporting Clock
Article 15 sets a tiered notification regime. The table below follows the Rulebook, with the 24-hour content taken from Dubai Standard’s summary.
Trigger | Deadline | What to send |
An event that significantly impacts, or may significantly impact, the continuity or integrity of Critical Operations | 4 hours | Notice of the event, identifying the affected Critical Operations |
The same event | 24 hours | A summary report on the nature of the incident, measures taken, potential impact, and expected time to restore operations |
Return to normal | On resumption | Notice that normal operations have resumed |
Any high-risk incident | 72 hours | Notice, with high-risk criteria defined in Board-approved policies |
A four-hour clock cannot be met by an institution that lacks timely visibility, clear escalation paths, and well-defined Critical Operations, as one analysis of the rule puts it. The incident definition is also broad: it covers an event that has or could potentially have an adverse effect on Critical Operations or on Critical Information Assets.
What Is New Compared With 2018
SwissGRC lists the elements the 2026 regulation adds to the 2018 framework: operational resilience, identification of critical operations, dependency mapping, cybersecurity, third-party risk management, stress and penetration testing, four-hour incident reporting, change management, customer protection, data governance, and public disclosure. The common thread is a shift from showing that controls exist to showing that Critical Operations continue through disruption, a point Crowe also makes in its summary.
Critical Operations Come First
Article 3.4 requires institutions to identify their Critical Operations and every asset needed to deliver them: people, technology, processes, data, facilities, and Third-Party Service Providers, including intragroup entities, plus the interdependencies among them. The mapping must be formalized for each Critical Operation and updated through change management.
At a minimum, Critical Operations include payment systems and other time-critical customer services, accurate financial records, and the ability to measure and manage solvency and liquidity, plus anything the CBUAE deems critical.
What the Cyber Articles Require
A cyber framework inside operational risk: Article 8.1 requires an ICT and cybersecurity risk framework covering risk identification, mitigation measures consistent with assessed risk, regular monitoring and testing, and ongoing management.
Tested programs: Article 8.5 requires protection, detection, response, and recovery programs that are regularly tested. Article 3.6 adds incident response, business continuity, and disaster recovery plans for all Critical Operations.
Board ownership: Article 4.4 makes the Board responsible for approving, overseeing, and ensuring the effectiveness of the ICT and cybersecurity risk framework. Under Article 4.2, the Board itself, not a committee, must approve and review at least annually the operational risk appetite and tolerance and the tolerance for disruption.
An annual control report: Article 5.6 requires banks and (re)insurers to give the Board and the CBUAE a report on internal control at least annually, covering key controls for the processes behind Critical Operations.
Testing, Evidence, and Insurance
Article 7.13 requires periodic stress tests, including penetration testing, across ICT systems, physical controls, and people-based controls. Article 7.14 requires penetration testing by an independent third party, at least for Critical Functions, with results presented to the Board.
Article 7.5 states that risk transfer tools such as insurance may complement internal operational risk management and controls, but not replace them.
Rehearse the Clock With a Scenario
This scenario is illustrative. Monitoring flags failing payment transfers at 2 a.m. The on-call engineer must know that payments are a Critical Operation, who classifies the event as significant, who drafts a notice naming the affected operation, and who submits it to the CBUAE. Rehearse that chain with a stopwatch, record how long each handoff takes, and fix the slowest one first.
Readiness Plan
This plan is practical guidance, not CBUAE text.
Map Critical Operations and their dependencies: Complyan’s third-party risk management keeps suppliers and intragroup providers attached to what they support, which feeds the Article 3.4 mapping.
Define high-risk criteria and approve them at Board level: Complyan’s governance and policy management tools hold the approved criteria, owners, and review dates.
Build and rehearse the 4, 24, and 72-hour workflow: keep a notification log with timestamps. Complyan’s audit and compliance management platform maps the log, test results, and approvals to controls.
Express cyber risk against disruption tolerance: Complyan’s cyber risk management platform holds scored risks next to the appetite statements the Board approves.
Report to the Board with current data: Complyan’s executive and board reporting gives directors a live view of testing results and open gaps.
Map once across other UAE frameworks: institutions also work with UAE IA and, in Dubai, DESC requirements, and one control record can serve each.
Where Programs Will Stall
Undefined classification criteria: the 72-hour duty depends on Board-approved high-risk criteria, so unclear definitions cause late or missed notices.
No overnight visibility: a four-hour clock runs at 3 a.m. as well as 3 p.m., so detection and escalation need coverage around the clock.
Group-run services outside the map: intragroup providers fall within the mapping requirement, not outside it.
Insurance treated as a control: Article 7.5 allows insurance to complement controls, never to replace them, so a policy cannot stand in for a tested recovery capability.
Tests without Board visibility: an independent penetration test that never reaches the Board misses the Article 7.14 requirement.
Conclusion: CRIR Compliance Is About Traceable Cyber Risk Information
Strong CBUAE cyber risk reporting does not begin with the final template.
It begins with consistent risk definitions and reliable data. The Board view should connect to risk appetite. Control evidence should support the numbers being reported. Testing should change the risk position when weaknesses are identified.
Complyan gives UAE financial institutions a central environment for cyber risk, compliance controls, third-party oversight and evidence so regulatory reporting can be produced from the same information used to manage risk every day.
The real test is simple: when a cyber risk figure appears in a CBUAE report, can the institution prove where it came from?
Frequently Asked Questions About Vendor Risk Scoring
What is the purpose of CBUAE cyber risk reporting?
It gives regulators and financial institutions a structured view of ICT and cybersecurity exposure, control effectiveness and resilience so material risks can be identified and acted upon.
What changed under the CBUAE Operational Risk Management Regulation in 2026?
The regulation places ICT and cybersecurity within the wider Operational Risk and Operational Resilience framework and strengthens requirements around risk appetite, testing, Board reporting and third-party technology risk.
What evidence should support cyber risk reporting?
Evidence can include vulnerability results, control testing, access reviews, incident records, recovery exercises and third-party assessments. The exact evidence should correspond to the metric being reported.
Can Complyan support CBUAE cyber risk reporting?
Yes. Complyan can connect cyber risks, framework controls, evidence and vendor exposure in one GRC environment, reducing the manual work required to assemble regulatory information.