CBUAE Cybersecurity Requirements: What UAE Banks Must Know

How CBUAE supervision actually works

The Central Bank of the UAE licenses and supervises banks, finance companies and exchange houses, and its cybersecurity expectations arrive through that supervisory relationship rather than through a single technical checklist. Risk management regulation makes the board accountable for operational and technology risk. Consumer protection rules push liability for fraud losses and for misuse of customer data toward the institution. Outsourcing rules put any arrangement that touches confidential customer data under regulatory scrutiny, which is why cloud projects at UAE banks begin with a data residency conversation rather than an architecture diagram.

Supervision is examination-driven. CBUAE teams come on site, request evidence and track findings to closure. That shapes how a sensible programme is built. The question is never "do we have a policy for this" but "can we produce the artefact that proves the policy runs". A privileged access policy without access review records is a finding. An incident response plan that has never been exercised against a core banking scenario is a finding. In my experience the banks that handle examinations calmly are the ones that maintain evidence continuously instead of assembling it in the two weeks before a visit.

Incident notification matters as much as prevention. When something goes wrong, the regulator expects to hear it from the bank, quickly and with substance, not from the press. The internal escalation path that makes fast, accurate notification possible is part of the requirement even though it never appears as a named control.

Where NESA and the UAE IA Standards fit

The National Electronic Security Authority published the UAE Information Assurance Standards as the national control framework for critical sectors, and finance is one of them. The institutional side has been reorganised since, with the UAE Cyber Security Council now leading national policy, but the IA control catalogue survived and it is still the language many assessors in the sector work from. Its controls are grouped into management and technical families with priority tiers, which gives a bank a defensible order of implementation rather than an undifferentiated list.

For a bank the practical question is overlap. The IA controls map heavily onto ISO 27001, and most UAE banks already run an ISO-shaped management system. Run one control framework internally and map it outward to CBUAE expectations, the IA standards and ISO, instead of running parallel programmes that drift apart. Assessors accept mappings. What they do not accept is a certificate offered in place of implementation evidence. The register they want to see shows which controls are implemented, which are compensated, and which are accepted risks with a named owner and a review date.

Why the Oracle estate carries so much of the evidence

The reason Oracle belongs in a CBUAE compliance post is unglamorous: a large share of core banking in the Gulf runs on Oracle, whether that is FLEXCUBE or in-house applications built on Oracle Database. When an examiner asks who can read customer account data, where that data is encrypted, and who held SYSDBA during last month's change window, the honest answers live in the database layer. Get the Oracle estate right and a surprising amount of the evidence burden resolves itself.

The database controls worth their licence cost

Transparent Data Encryption protects datafiles and backups at rest. It is a real control against stolen backup media and file-level access to storage, and it is the cleanest answer to the encryption-at-rest question. It does nothing against a compromised application server or an authenticated session, so treat it as one layer rather than the answer. TDE sits in a separately licensed option on Oracle Enterprise Edition, and the licensing line surprises budget owners more often than the technology does.

Database Vault addresses the harder question: separation of duties inside the database. It can block even administrator accounts from reading application schemas, which is exactly the control an assessor wants when the finding says administrators can see customer data. The tradeoff is operational friction. Patching jobs, monitoring agents and long-forgotten admin scripts all break when the restrictions arrive unannounced, so run it in monitoring mode first, fix what would have been blocked, then enforce.

Unified auditing is the third leg. Write audit policies for privileged actions, schema changes against application objects and access to sensitive tables, and size for the volume before switching on. An audit trail that stays inside the database it audits is worth little. It has to leave the box, land somewhere the DBA cannot edit, and generate alerts somebody owns.

The DBA access problem

The most common database finding in the region has nothing to do with missing Oracle options. It is unmanaged administrative access: shared SYSDBA credentials, direct SSH to database servers using the oracle operating system account, no session recording, and access reviews that cover application users but not administrators. The fix is a privileged access management layer in front of the estate: vault the credentials, broker and record sessions, enforce named individual accounts, and keep a break-glass path that is alarmed rather than convenient. This one control converts "trust us" into evidence, which is why it is usually the right first investment for a bank that is behind.

The evidence examiners ask for

Requests vary with the examiner and the bank's finding history, but the recurring set is consistent:

• Privileged access review records for the last cycle, covering database and infrastructure administrators, not only application users.
• Audit logs from core systems flowing into a central platform, with alerting somebody demonstrably responds to. A SIEM that receives logs nobody watches is storage, not a control.
• An independent penetration test from the last year, scoped to include internet-facing channels such as online and mobile banking, with retest evidence for what was found. Scoping is where VAPT for banks most often goes wrong; a report that quietly excluded the core banking segment proves less than it appears to.
• Incident response exercise records: at minimum a tabletop against a plausible scenario, with the resulting actions tracked to closure.
• An outsourcing and third-party register showing who touches customer data and what assurance was collected from each of them.

None of these are exotic. All of them fail the same way: they exist as one-off documents from eighteen months ago instead of outputs of a running process.

Where bank compliance programmes fail

Four patterns cover most of the failures I see. The paper programme: a complete policy library with no enforcement underneath it, which an examiner uncovers with a single request for records. Logging without operations: log sources connected during the SIEM project, alert queues nobody triages, and no answer to who responded and when. Untested response: an incident response document that has never met a realistic scenario, which matters because ransomware remains the scenario most likely to hit hard, and UAE banks are still exposed to it in ways one honest tabletop exercise would surface. And compliance as an annual project: a scramble before each examination instead of an operating rhythm, which costs more and reads to an examiner exactly as what it is.

What to have ready before the next examination

If you are prioritising, work in this order:

1. Named accounts and session recording for all administrative access, database included.
2. Access review records that are less than one review cycle old.
3. Core system audit logs in a central platform with owned alerts.
4. One incident response exercise per year against a core banking scenario, with tracked actions.
5. A current third-party register with assurance evidence, not just signed contracts.

The logic behind the order is simple: privileged access and audit evidence answer the questions examiners open with, and every other control builds on the visibility those two provide.