"CBUAE compliance" isn't one rulebook
Ask five different CBUAE-licensed entities what their cybersecurity obligations are and you'll often get five different answers, because the Central Bank doesn't regulate through a single instrument. There are five overlapping ones, and which combination binds you depends on your licence category. Most institutions carry two or three at once without realising the full set applies to them.
Every licensed entity — bank, finance company, exchange house, payment institution — sits under the Information Security Regulation at minimum. It's the floor: a named security function reporting independently of IT, a defined risk-assessment cadence, access control, encryption at rest and in transit, logging, incident classification. Larger or systemically important institutions build on top of it, but nobody gets to skip it.
Sitting alongside that is the Operational Risk Standard, which treats cyber risk as one operational risk category among several. It wants a documented risk appetite statement, periodic business impact analysis, and recovery time objectives that have actually been tested — not numbers pulled from a policy template three years ago.
Two more frameworks apply narrowly but matter a great deal if they hit you. E-wallet and prepaid card issuers fall under the Stored Value Facilities framework, which segregates customer funds from operational accounts and calibrates monitoring to high-volume, low-value transaction patterns. Anyone doing payment initiation or merchant acquiring sits under Retail Payment Services, which increasingly expects sanctions screening at the point of settlement rather than as an after-the-fact report.
And then there's the one almost nobody is ready for: Open Finance. It demands real API-level security — OAuth consent flows, token lifecycle management, per-partner rate limiting — and a bank can be fully ISR-compliant and still fail an Open Finance review because its API gateway doesn't enforce consent properly.
What actually gets asked in a supervisory review
CBUAE reviews have moved away from "show me the policy" and toward "show me it firing." An examiner is far more likely to ask for the last board-level cyber risk report and what decision it triggered than to ask whether one exists at all. They'll want the escalation trail on your last three security incidents, however small, with time-to-detection and time-to-containment attached. They'll ask whether last cycle's penetration testing findings were actually remediated and independently retested — not just marked closed in a tracker somewhere.
The institutions that fail this kind of review usually aren't technically weak. They're undocumented. The gap is almost always in evidence discipline, not in the underlying controls.
What non-compliance actually costs
Beyond the fine schedule itself — and fines do scale with turnover and severity — CBUAE can order mandatory remediation on a fixed deadline, restrict specific licensed activities until a control is demonstrated, or in serious or repeat cases suspend the licence outright. The quieter cost is reputational: correspondent banking partners increasingly run their own due-diligence checks on an institution's CBUAE supervisory history before extending or renewing a relationship, and a public enforcement notice follows you into those conversations.
Where boards are now expected to actually engage
Cyber risk used to sit with IT. CBUAE has been pushing it toward the boardroom for a few years now, and that shift changes what evidence an institution has to produce. A board that receives a single red-amber-green heat-map slide and moves on isn't demonstrating oversight — CBUAE wants to see quantified exposure, a risk appetite that ties to specific control spend, and minutes showing the board actually pushed back on something.
The three-lines-of-defence question comes up constantly in our engagements: the business function running risk day-to-day, an independent compliance function challenging it, and internal audit testing whether the first two are doing their jobs. Examiners probe whether these lines are genuinely separate people, not the same person wearing two hats — because that's not oversight, it's a conflict of interest with a nicer name. Smaller finance companies without headcount for three full functions can run proportionate structures, but the principle holds regardless of size: nobody marks their own homework on cyber risk.
The gaps we keep finding, engagement after engagement
A few patterns show up often enough across ITSEC's CBUAE readiness work that they're worth naming plainly.
Risk registers that haven't been substantively touched in over a year are probably the single fastest way to trigger a finding — even when the underlying risks genuinely haven't changed much, a static register reads to an examiner as a risk function that isn't paying attention. Vendor risk assessments tend to happen once, at onboarding, and never again, even for vendors sitting directly on core banking or payment data; CBUAE wants ongoing monitoring, not a one-time checkbox.
Incident response plans are frequently reviewed on paper and never actually exercised. The first time most of these plans get tested for real is during an actual incident, at 3am, when nobody has time to discover the plan's assumptions were wrong. Encryption key rotation is another one — a documented rotation schedule sitting next to production keys that haven't actually rotated on schedule is trivial for a reviewer to catch and reads badly once they do.
And Open Finance integrations built fast to hit a deadline often work fine for the business while quietly missing proper token expiry, scope limitation, or revocation handling — functional, but not what the regulation was actually asking for. None of this is exotic. It's the kind of thing a properly scoped readiness review catches months before a supervisory examination does, which is rather the point of running one proactively.
Speak with ITSEC about CBUAE compliance across ISR, Operational Risk, SVF, RPS, and Open Finance.
Consult Cyber Experts →
