CBUAE Cybersecurity Requirements: What UAE Banks and Financial Firms Must Do

CBUAE cybersecurity requirements depend on a financial institution’s licence and activities, but licensed financial institutions must embed ICT and cybersecurity risk management in their operational risk framework and operational resilience approach. Under requirement 8.1, they must identify and assess ICT risks, mitigate them, and monitor and test controls.

Compliance therefore means more than putting security tools in place. Institutions need to identify the Critical Operations they must protect, understand the systems and dependencies that support them, and plan how to respond to disruption.

For banks and other regulated financial firms, applying these obligations across applications, APIs, cloud environments and internal networks can be challenging. This guide explains what the rules require, where controls apply, how to identify and address gaps, and what to monitor and report. The aim is to connect regulatory expectations with your organisation’s risks and operating model.

What is CBUAE cybersecurity compliance?

CBUAE cybersecurity compliance means applying the Central Bank of the UAE’s relevant technology, cyber and information security obligations according to an institution’s licence, activities and risks. Licensed financial institutions must include ICT and cybersecurity risk management in their operational risk management and operational resilience.

Regulatory instruments and licence scope

An institution’s licence determines which CBUAE instruments and requirements apply. This distinction matters because banks, insurers, finance companies, exchange houses and fintech providers perform different activities and are not subject to identical controls.

Licensed financial institutions must comply with relevant UAE authority requirements under 8.10. Article 8 addresses ICT and cybersecurity management, while Article 12 addresses technology and specific risk management. UAE Information Assurance requirements should be applied according to the institution’s licence, activities and relevant national or sector-specific obligations, not assumed to apply universally.

Integrated GRC and regulatory controls

Integrated governance, risk and compliance links regulatory obligations to accountable owners, risk assessments, controls and evidence. A policy alone cannot show whether a control works across the systems that support a regulated activity.

For example, a UAE financial institution can map a CBUAE obligation to its risk register, control owner, testing record and remediation evidence. The CBUAE operational risk requirements also connect ICT and cybersecurity risks to an institution’s operational resilience approach. A consistent cybersecurity compliance approach helps organise those relationships without treating every rule as a separate project.

Cybersecurity requirements for financial institutions

The CBUAE cybersecurity requirements for banks and other financial institutions centre on identifying, assessing, mitigating, monitoring and testing ICT risks. Requirement 8.1 places that risk framework within operational risk management and resilience. Institutions must also identify Critical Operations and understand the assets and dependencies needed to deliver them.

Article 2 sets out operational risk management framework requirements, while Article 3 addresses operational resilience. Requirement 8.6 calls for policy coverage of governance, accountability, security measures, data management, incident and recovery plans, project management, and systems development and acquisition. These controls should reflect the institution’s activities and technology dependencies.

A UAE payment service provider, for example, must meet the Retail Payment Services and Card Schemes Regulation, including the UAE Information Assurance Standards at a minimum under Article 13. ISO 27001 certification is not named as a CBUAE requirement in the instruments covered here.

Non-compliance can have regulatory and licensing consequences, including administrative penalties and action affecting the institution’s licence.

Applications, APIs, cloud environments, and internal networks

The CBUAE cybersecurity requirements reach the technology that processes transactions and supports financial services. For a licensed financial institution, ICT infrastructure must meet current and projected business needs while protecting data and system integrity, confidentiality and availability under requirement 8.3. That scope includes applications, network connections, cloud resources and dependencies used to deliver regulated services.

Controls begin during system development or acquisition. UAE payment service providers must define security requirements early and build them into systems during development. This makes information security part of design and change processes, rather than leaving it to a final review. Open Finance Providers must also follow operator-set security and other standards to prevent software compromise during development.

APIs need safeguards for interactions and data exchange between applications. The CBUAE Open Finance Regulation requires secure open communication standards, secure interfaces and communication between licensees and Open Finance providers. For example, a UAE payment service provider connecting a customer-facing app to payment processing should consider how its API protects data moving between those components.

Payment-related controls also cover authentication data and network accountability. Providers must encrypt Retail Payment Service User passwords end to end during transmission, preventing exposure at intermediate nodes. A UAE payment service provider with monthly average payment transactions of AED 10 million or more must assign overall responsibility for network management to suitably expert individuals, often supported by professional networking and security training from Insoft Services.

For cloud environments and internal networks, requirement 8.6.3 identifies controls including access controls, identity management, Critical Information Asset protection, network security, vendor management security, vulnerability testing and information classification. Requirement 8.8 also calls for proactive management of ICT and cybersecurity systems, including third-party systems, and timely renewal or discontinuation of obsolete and unsupported hardware or software.

• Applications: embed security requirements into development and acquisition processes.
• APIs: protect application interactions and data exchange, including Open Finance interfaces.
• Cloud and third parties: include provider dependencies in ICT risk management and system oversight.
• Internal networks: apply access, identity, network security and information classification controls.

These controls should form part of the institution’s broader risk management processes. A cloud security posture assessment can help map cloud configurations and dependencies to relevant security controls, while taking the institution’s licence and technology risks into account.

Consider a UAE payment app that sends transaction data through an API to a cloud-hosted service. Its control design should address secure development, protected data exchange, network ownership and the third-party systems supporting the service. The relevant controls depend on the service’s architecture and role in the institution’s operations.

Compliance gap assessment and remediation

A CBUAE gap assessment compares applicable obligations with documented controls, evidence of how they operate and residual risks. It helps a licensed financial institution distinguish a policy gap from a control that exists but does not work as intended under testing. Findings should be linked to Critical Operations, business impact and the institution’s risk tolerance.

The Operational Risk Management function must assess vulnerabilities in Critical Operations and regularly report findings and recommendations to the Board. Requirement 8.7.1 calls for regular review of ICT and cybersecurity risk management processes against relevant standards, best practices, evolving technologies and threats. Requirement 8.7.2 requires regular testing to identify gaps against risk tolerance and improve risk identification, protection, detection and event management.

Penetration testing and vulnerability management should follow the institution’s regulatory scope and risk profile. Licensed financial institutions are expected to periodically conduct operational-risk stress tests, including independent third-party penetration testing for Critical Functions, with results presented to the Board. This is not a blanket annual test of every system in every bank. Payment service providers with monthly average payment transactions of AED 10 million or more must regularly assess whether penetration and cyber-attack simulation testing is necessary.

For each finding, map the affected service, system owner, risk rating, evidence and remediation action. For example, a UAE exchange house may identify a weakness in a system supporting a Critical Operation. The assessment should record the vulnerability, its possible effect on service delivery, existing safeguards and the accountable remediation owner. Consider recovery implications too: a finding affecting restoration capability may need different treatment from a weakness in a non-critical asset.

Prioritise findings by exposure and consequence, not simply by their number. An exploitable weakness affecting a Critical Function, customer data or a key third-party dependency may need faster action than a low-impact issue with compensating controls. Record the rationale, planned treatment and any accepted residual risk so management can see how decisions align with risk appetite.

• Scope: map applicable CBUAE obligations to Critical Operations and supporting assets.
• Assess: combine document review, technical testing and control evidence.
• Prioritise: weigh exploitability, operational impact, dependencies and recovery effects.
• Remediate: assign ownership, track corrective work and retest relevant controls.
• Report: present material vulnerabilities, recommendations and progress to the Board.

Independent assurance can strengthen an assessment when testing is appropriate to the Critical Function and its threat exposure. Retesting can establish whether a corrective change addressed the underlying weakness, while updated risk records preserve the decision trail. This turns assessment findings into operational improvements rather than leaving them for a future review.

Compliance monitoring and audit evidence

Monitoring turns written security requirements into a continuing view of control performance. Under requirement 8.1.3, a licensed financial institution must regularly monitor and test ICT risk-mitigating measures. This helps identify whether controls still address assessed risks as systems, suppliers and business processes change. Evidence should connect each control to its owner, operating activity, test result and follow-up action.

Changes create a specific need for monitoring. A Licensee should have an ongoing process to evaluate, monitor and control technology risks arising from change. For example, a change to a payment application may affect access permissions, data flows or dependencies. Recording the change assessment, approval and relevant control checks gives reviewers a clear trail from decision to implementation.

Transaction records also support accountability. UAE payment service providers must log all payment transactions with an appropriate audit trail. This helps link an individual transaction to recorded activity and supports investigations of discrepancies or suspected misuse. Consider the trail alongside other evidence, such as access records, security alerts, control tests and incident records.

Useful audit evidence shows what happened, when it happened and how the institution responded. A control description alone cannot demonstrate that monitoring took place. Evidence may include dated test results, identified exceptions, assigned remediation actions, approval records and closure notes. Make the link between each piece of evidence and the relevant security requirement clear.

• Control ownership: identify the accountable role and the systems or processes covered.
• Monitoring results: record observed exceptions and the control test that identified them.
• Change records: link material technology changes to risk evaluation and control decisions.
• Remediation evidence: preserve action ownership, progress and retest outcomes.
• Transaction trails: retain appropriate records that support review of payment activity.

Reporting connects operational evidence with governance. Under requirement 8.4, the Board and Senior Management must be regularly informed about ICT and cybersecurity risk exposures. This includes incidents and weaknesses identified through assessment and testing. Reports should therefore show material exposures, trends, unresolved findings and the status of corrective actions, rather than presenting test counts without context.

Requirement 8.7 also makes regular review and testing part of ICT and cybersecurity risk management. Actionable intelligence should inform improvements to security posture and decision-making. For example, if monitoring identifies repeated access-control exceptions, management can examine their cause, assess associated risk and track corrective work. Subsequent testing can show whether the change improved control performance.

A coherent evidence set lets internal reviewers trace the path from obligation to control, monitoring, finding and response. Consistent records also show how the institution evaluates technology risks as its environment changes. Compliance monitoring then becomes an active management process, rather than a collection of documents assembled for an audit.

Incident notification timelines

Article 15 of the CBUAE Operational Risk Management Regulation sets different notification requirements for qualifying events. A licensed financial institution must notify the CBUAE, within the timelines the CBUAE sets, of operational risk events that significantly affect its Critical Operations and of high-risk incidents, and provide summary reports for qualifying events.

These timelines have distinct triggers: significant effects on Critical Operations, summary reports for qualifying operational risk events, and high-risk incidents. They should not be collapsed into one deadline or treated as applying to every security alert.

Classification matters. Assess an alert’s operational impact, affected services and risk level to determine whether it is a reportable concern. For example, a cyber incident disrupting a UAE bank’s payment processing may significantly affect a Critical Operation. A suspicious event with no established impact still needs assessment against the high-risk incident criterion.

Response teams need a shared process for escalating incidents to decision-makers. It should connect technical investigation with operational risk, business continuity and regulatory reporting responsibilities. A vendor-related outage, for example, may require the institution to assess both the supplier’s role and the effect on its own Critical Operations. Outsourcing technology does not remove the need to assess that impact.

Strong incident records support timely decisions and consistent reporting. Capture the event’s discovery, classification rationale, affected services, known impact, containment actions and escalation decisions. Record when each material update becomes available. This gives management a traceable basis for assessing whether Article 15’s criteria apply and preparing the required notification or summary.

• Assess impact: determine whether the event significantly affects Critical Operations.
• Classify risk: evaluate whether the incident meets the high-risk threshold.
• Escalate: involve operational risk, technology and senior decision-makers.
• Document: retain the timeline, assessment, response actions and reporting decisions.
• Update: ensure later information informs the institution’s incident record and response.

For UAE financial firms, a practical exercise can test a scenario involving a payment service interruption and a third-party vendor. Teams can practise impact classification, escalation and preparation of a summary report. The exercise should clarify who gathers evidence and who coordinates regulatory communication, without confusing the separate Article 15 triggers.

Keep the incident response plan aligned with Critical Operations and recovery arrangements. Clear roles and accurate records help the institution assess events consistently against the CBUAE’s reporting requirements.

OAD Technologies: Banking IT and Cybersecurity

OAD Technologies helps financial institutions address cybersecurity needs through Zero Trust, SIEM/SOC and email security with Mimecast and Trustifi, alongside services such as Vulnerability Assessment and Penetration Testing (VAPT), Managed Detection and Response (MDR), and Data Loss Prevention (DLP). These services can support financial firms assessing technical weaknesses, strengthening detection, or protecting sensitive information.

For example, a UAE financial institution could use VAPT to assess exposure, consider DLP controls for sensitive information and use MDR to support threat detection and response. The appropriate combination depends on the organisation’s systems, risk priorities and compliance gaps. These services complement, but do not replace, the institution’s responsibility to interpret and meet its CBUAE obligations.

Discuss your requirements with OAD Technologies to explore how its cybersecurity services could support your organisation’s needs.

Build compliance into your next decision

Meeting CBUAE cybersecurity requirements is an ongoing management responsibility, not a one-off documentation exercise. Connect compliance priorities with planned technology changes, operational ownership and the decisions leaders already make about risk. This keeps security visible as services evolve, rather than treating it as a separate workstream.

Bring together the teams responsible for technology, risk and business operations to agree which gaps need attention first. Then shape remediation around the systems and services that matter most to your organisation. A clear, shared view helps decision-makers direct effort, track progress and adapt controls as the environment changes.

OAD Technologies can discuss how its cybersecurity services may fit your organisation’s compliance priorities and technical needs. Start a conversation to explore a practical path forward.

Clear ownership and ongoing improvement can help your organisation strengthen its security posture while supporting informed business change.

Frequently asked questions

Which CBUAE regulations and standards govern cybersecurity and information security?

Relevant instruments vary by regulated activity and include sector-specific rules alongside operational risk requirements. For stored value facility issuers, Article 12 of the Stored Value Facilities Regulation addresses technology risk and information security. Open Finance Providers are also subject to Article 24 of the CBUAE Rulebook on technology risk and information security. These examples show why an instrument register should reflect the services actually provided.

What are the key controls required under the CBUAE Information Security Regulation and Standards?

Payment controls include stronger verification for higher-risk activity. UAE payment service providers must require multi-factor authentication for high-risk transactions and re-authenticate transactions such as those exceeding predefined limits or involving changes to contact details. Authentication decisions should therefore account for transaction context and specified risk conditions, rather than relying solely on the user’s initial sign-in.

What are CBUAE requirements for cyber risk governance, policies, and board oversight?

Open Finance Providers have specific governance expectations. The Board or its designated committee is responsible for ensuring a sound, robust and proportionate technology risk management framework. IT governance must include an effective IT function, a technology risk management function and an independent technology audit function. The governance design should therefore clearly separate operational, risk and audit responsibilities.

What are CBUAE requirements for incident reporting, response, and notification timelines?

For personal-data events, distinguish CBUAE reporting duties from UAE PDPL obligations. Under Article 9 of the UAE PDPL, a controller must notify the UAE Data Office once aware of a qualifying breach; the law sets no fixed number of hours. CBUAE Consumer Protection Standards separately require immediate notification of significant personal-data breaches. The event’s nature and the applicable regulatory route therefore matter.

What cybersecurity requirements does CBUAE impose on cloud services and third-party providers?

Requirement 8.9 addresses the LFI’s Master System of Record: it must be continuously maintained and stored within the UAE, including when outsourcing. A branch of a foreign financial institution may instead maintain an up-to-date UAE copy, subject to Central Bank approval. This specific record-location rule should be considered separately from broader assessments of outsourced technology and cloud-related risk.

How do CBUAE cybersecurity requirements differ for banks, exchange houses, insurers, and payment providers?

Requirements differ according to regulated activities, not simply an organisation’s business label. Payment service providers face transaction-specific requirements, while a bank or exchange house may also provide a payment service subject to those provisions. An insurer’s obligations depend on its licensed activities and applicable instruments. A scope review should map each product and service to the relevant licence conditions and CBUAE rules.