CBUAE Cybersecurity and IT Risk Requirements: A Compliance Guide for UAE Banks and Fintechs

Banks, finance companies, exchange houses and payment service providers in the UAE don't just answer to international security frameworks — they answer to the Central Bank of the UAE (CBUAE), the supervisory authority responsible for the stability and integrity of the country's financial system. Unlike ISO 27001 or SOC 2, which are frameworks an organisation chooses to pursue, CBUAE's expectations are a condition of holding a licence. For regulated financial institutions, getting IT and cyber risk management wrong isn't just a security gap — it's a licensing and supervisory issue.

Who CBUAE regulates, and why cyber sits at the centre of it

CBUAE licenses and supervises banks, finance companies, exchange houses, payment service providers and card scheme operators, insurance-related entities, and a growing number of fintechs operating under regimes such as retail payment services and open finance. As financial services in the UAE have digitised — mobile banking, instant payments, API-driven open finance, stored value facilities — the attack surface regulated entities present has grown accordingly, and CBUAE's supervisory focus on technology and cyber risk has grown with it.

This isn't a side concern bolted onto prudential supervision. A cyber incident at a bank or payment provider can disrupt payment rails, erode consumer trust in digital financial services, and create systemic risk well beyond the institution itself — which is exactly why CBUAE treats technology risk as a core supervisory concern rather than a purely technical one.

The core pillars of CBUAE's technology and cyber expectations

While the specific regulations and standards vary by licence category, a consistent set of expectations runs through CBUAE's approach to regulated entities:

• Board and senior management accountability. Technology and cyber risk is expected to be owned at a governance level, not delegated entirely to IT. Regulated entities are expected to have clear accountability for information security outcomes, with regular reporting to the board or an equivalent oversight body.
• A documented IT and cyber risk management framework. Entities need a structured approach to identifying, assessing and treating technology risk — covering everything from core banking systems and payment infrastructure to mobile and online banking channels.
• Outsourcing and third-party risk management. As banks and fintechs increasingly rely on cloud infrastructure, SaaS platforms and outsourced technology providers, CBUAE expects regulated entities to assess, contract for, and continuously monitor the security posture of those third parties — the institution remains accountable for the risk even when the technology is operated by someone else.
• Business continuity and operational resilience. Entities are expected to be able to maintain or quickly restore critical financial services after a disruption, with tested continuity and disaster recovery plans rather than documentation that has never been exercised.
• Incident detection and reporting. Regulated entities are expected to detect security incidents promptly and escalate materially significant ones through defined reporting channels, rather than treating incident disclosure as discretionary.
• Consumer data protection. Customer financial and personal data handled by regulated entities carries its own protection expectations, which sit alongside — and interact with — the UAE's broader personal data protection law.

For payment service providers and card scheme operators specifically, CBUAE's retail payments regulatory regime layers additional technology risk, security and operational resilience requirements on top of these general expectations, reflecting the direct exposure of payment infrastructure to fraud and service-disruption risk.

How this relates to other frameworks you may already hold

Banks and fintechs operating in the UAE are rarely working against CBUAE's expectations alone. Many also pursue ISO 27001 certification as an internationally recognised way to demonstrate a mature information security management system, and most payment-handling entities are separately in scope for PCI DSS if they store, process or transmit cardholder data. The practical reality is that these frameworks overlap substantially — governance, risk management, access control, incident response and third-party oversight are common to all of them. An institution that builds a genuinely mature security programme against ISO 27001 or PCI DSS is usually most of the way toward satisfying CBUAE's expectations too, provided it maps its controls explicitly against CBUAE's specific requirements rather than assuming equivalence.

Where banks and fintechs typically fall short

A few recurring gaps show up across financial-sector security assessments:

1. Outsourcing risk treated as a procurement exercise. A cloud or SaaS vendor is vetted at onboarding, then rarely reassessed as the relationship, data access, or the vendor's own risk profile changes.
2. Business continuity plans that exist but aren't tested. A disaster recovery plan that has never been exercised against a realistic scenario is a document, not a capability.
3. Fragmented ownership of cyber risk. Technology risk sits with IT, fraud risk sits with operations, and data protection sits with legal — with no single view of how these risks interact.
4. Incident reporting processes defined too late. Without a rehearsed escalation path, the pressure of a live incident is the worst possible time to work out who reports what, to whom, and on what timeline.
5. API and open finance security treated as an afterthought. As open finance and API-driven banking expand, the authentication, authorization and data-sharing controls around those APIs need the same rigour as the core banking platform itself.

Practical steps to prepare

1. Map your existing controls against CBUAE's specific expectations for your licence category, rather than assuming ISO 27001 or PCI DSS compliance automatically covers it.
2. Validate third-party and cloud provider security through contractual requirements and periodic reassessment, not a one-time onboarding check.
3. Test your business continuity and disaster recovery plans against realistic scenarios, including a cyber incident disabling a primary system.
4. Rehearse incident reporting so the escalation path, timelines and required information are known before an incident happens, not improvised during one.
5. Validate technical controls independently. A penetration test of customer-facing banking channels, payment infrastructure and APIs confirms that access controls and segmentation actually hold up under real attack techniques.
6. Assign clear accountability. Where no one holds end-to-end ownership of technology and cyber risk, a virtual CISO can provide that oversight and manage board reporting without a full-time executive hire.

FAQ

Does CBUAE regulate fintechs, or only traditional banks?

CBUAE's supervisory remit extends well beyond traditional banks to finance companies, exchange houses, payment service providers, card scheme operators, and fintechs operating under specific licensing regimes such as retail payments and open finance. The specific requirements that apply depend on the licence category held.

Is ISO 27001 certification enough to satisfy CBUAE?

Not automatically. ISO 27001 demonstrates a mature, internationally recognised information security management system and covers much of the same ground CBUAE expects, but regulated entities should explicitly map their controls against CBUAE's own requirements rather than assuming the two are equivalent.

What's the difference between CBUAE's expectations and PCI DSS?

They apply for different reasons and to different scopes. PCI DSS is a card-industry contractual standard focused specifically on protecting cardholder data. CBUAE's expectations are broader supervisory requirements covering governance, IT risk, outsourcing, resilience and incident reporting across a regulated entity's whole technology environment. Payment-handling institutions are typically in scope for both.

What happens if a CBUAE-regulated entity suffers a major cyber incident?

Materially significant incidents are expected to be reported through defined channels within set timelines, and the entity's response — including whether continuity plans worked as intended — is likely to draw supervisory attention. Institutions without a rehearsed reporting and response process are at a real disadvantage when an incident actually occurs.

Understanding where your security programme stands against CBUAE's expectations is easier with an outside view. Talk to our team about a gap assessment for your institution.