The Central Bank of the UAE has established comprehensive cybersecurity requirements for licensed financial institutions. This article breaks down the CBUAE framework covering governance, risk management, access controls, and continuous monitoring.
The Central Bank of the UAE has progressively strengthened its cybersecurity expectations for licensed financial institutions. Banks, finance companies, exchange houses, and payment service providers operating under CBUAE supervision must implement cybersecurity controls that reflect the systemic importance of the financial sector to the UAE economy. ITSEC has worked with multiple CBUAE-regulated institutions on gap assessments, remediation programs, and ongoing compliance support. This article covers what the regulator expects in practice, not just on paper.
CBUAE expects cybersecurity governance to begin at the board level. This is not a formality — the regulator evaluates whether governance is functional by examining board meeting minutes, the quality of reporting provided to the board, and the decisions made in response to that reporting.
The board of directors must approve the institution's cybersecurity strategy and ensure that adequate resources are allocated to implement it. Board members do not need to be technical experts, but they must demonstrate informed oversight — they should understand the institution's risk profile, the adequacy of controls relative to that profile, and the implications of key cybersecurity decisions. ITSEC has seen institutions fail regulatory reviews because board reporting consisted of a single slide with a green traffic light, providing no basis for meaningful governance.
A designated Chief Information Security Officer must have a direct reporting line to senior management and periodic access to the board. Critically, the CISO function must be independent of the IT function. When the CISO reports to the CIO or CTO, the inherent conflict of interest — where security recommendations may be overridden by operational convenience — undermines the objectivity of risk assessment. CBUAE expects this independence to be structural, not just organizational. The CISO must have the authority to escalate concerns directly to the board without filtering by IT leadership.
Cybersecurity committees or steering groups should meet at minimum quarterly, with representation from business lines, technology, risk management, and compliance. Meeting minutes must document substantive discussion, not just attendance. Decisions, action items, and accountability must be recorded and tracked.
Financial institutions must maintain a cybersecurity risk management framework that identifies, assesses, and mitigates risks across the entire technology environment. ITSEC aligns assessments to NIST Cybersecurity Framework and ISO 27001 as reference standards, while ensuring specific coverage of CBUAE expectations.
Risk assessments must be conducted at least annually and whenever material changes occur to systems, processes, or the threat landscape. The assessment must cover technology risk across all platforms and infrastructure, operational risk from processes that depend on technology, third-party risk from vendors and service providers, and emerging threats specific to financial services including payment fraud, account takeover, ransomware targeting financial data, and insider threats.
The risk register must connect identified risks to specific controls, with residual risk calculated after controls are applied. Risks above the institution's risk appetite must have documented treatment plans with assigned owners, specific remediation actions, and target completion dates. ITSEC consistently finds that the most common weakness in financial institution risk assessments is the disconnect between the risk register and the actual security investment plan — risks are identified but the budget allocation does not reflect the priorities the assessment identifies.
Strict access controls are fundamental to CBUAE compliance and represent one of the most frequently examined areas during regulatory reviews. Institutions must implement role-based access control with the principle of least privilege — every user should have only the minimum access required to perform their job function, documented through formal access matrices that map roles to system permissions.
Multi-factor authentication is mandatory for all access to critical systems including core banking, payment processing, SWIFT infrastructure, and customer data repositories. MFA should also be implemented for all remote access including VPN, cloud services, and email. ITSEC recommends hardware tokens or authenticator applications rather than SMS-based MFA, as SMS is vulnerable to SIM swapping and interception attacks that have been used successfully against financial institutions.
Privileged access management requires additional controls beyond standard MFA. Administrative accounts should be managed through a PAM solution that provides just-in-time provisioning where administrative access is granted only for the duration needed and automatically revoked, session recording for all privileged sessions providing forensic evidence if incidents occur, automatic credential rotation ensuring that administrative passwords are changed after every use, and break-glass procedures for emergency access with post-use review and justification requirements.
Access reviews must be conducted regularly — quarterly for privileged accounts and semi-annually for standard user access. Reviews must verify that access remains appropriate for the user's current role, that terminated employees have had all access revoked promptly, that no orphaned accounts exist, and that service accounts are documented with assigned owners and justified access levels. Evidence of access reviews and remediation actions must be retained for regulatory examination.
The network architecture must implement defense-in-depth principles with clear segmentation between security zones. ITSEC designs network architectures for financial institutions with separate zones for customer-facing channels including internet banking, mobile banking, and ATM networks, internal processing systems including core banking and middleware, payment infrastructure including card processing, SWIFT, and domestic payment systems, management and administrative networks, development and testing environments completely isolated from production, and security infrastructure including SIEM, log management, and vulnerability scanning.
Each zone boundary must enforce explicit access controls through next-generation firewalls with application-layer inspection. Default-deny policies must be in place — only explicitly authorized traffic should traverse zone boundaries. Micro-segmentation within zones provides additional protection for critical assets, preventing lateral movement if an attacker compromises a system within a zone.
SWIFT infrastructure demands particular attention. CBUAE expects institutions to comply with the SWIFT Customer Security Programme, which requires a secure zone for SWIFT-related infrastructure isolated from the general IT environment. ITSEC conducts SWIFT CSP assessments as part of our banking cybersecurity practice and consistently finds that institutions underestimate the segmentation and access control requirements for SWIFT compliance.
Intrusion detection and prevention systems must monitor network traffic at zone boundaries and within critical zones. Network traffic analysis should be integrated with the SIEM platform to enable correlation of network events with endpoint and application events.
Customer data and financial records must be classified according to sensitivity with at minimum four classification tiers: public, internal, confidential, and restricted. Each tier must have defined handling requirements covering storage, transmission, access, and disposal. Classification must be applied consistently across all systems and data stores — ITSEC frequently finds that institutions classify structured data in core systems but fail to apply equivalent classification to unstructured data in email, file shares, and collaboration platforms.
Encryption must protect data at rest using AES-256 or equivalent and in transit using TLS 1.2 at minimum, with TLS 1.3 for all new implementations. Key management must follow established practices with keys generated using cryptographically secure methods, stored in hardware security modules for high-value keys, rotated according to defined schedules, and destroyed securely at end of life. Database encryption should use transparent data encryption at minimum, with column-level encryption for the most sensitive fields such as account numbers and personal identifiers.
Data loss prevention controls must prevent unauthorized exfiltration of sensitive information through email, web uploads, removable media, and cloud services. DLP rules must be tuned to the institution's data classification scheme and tested regularly to verify effectiveness.
CBUAE expects financial institutions to maintain security operations capabilities proportionate to their size and risk profile. For larger institutions, this means a dedicated Security Operations Center with twenty-four-seven monitoring capability. Smaller institutions may use managed security service providers, but must maintain internal accountability for security event management and incident response.
Centralized log collection through a SIEM platform must cover all critical systems with real-time correlation and alerting. Log sources must include authentication systems, firewalls and network security appliances, core banking and payment systems, database activity monitoring, endpoint detection and response, email and web security gateways, and cloud platform audit logs. Correlation rules must be tuned to financial services threat scenarios — generic SIEM deployments produce excessive noise and miss industry-specific attack patterns. ITSEC develops custom correlation rules for banking clients that address payment fraud indicators, account takeover patterns, insider threat behaviors, and lateral movement techniques commonly used in attacks against financial institutions.
Log retention must meet regulatory requirements — ITSEC recommends twelve months online and seven years in archive. Log integrity must be protected to ensure that records cannot be modified or deleted by attackers who compromise systems.
Continuous vulnerability scanning must cover all systems with defined remediation SLAs by severity: critical vulnerabilities within seventy-two hours, high within fourteen days, medium within thirty days, and low within ninety days. Scanning must include infrastructure, web applications, databases, and network devices. Vulnerability management is not just scanning — it requires a process for prioritizing remediation based on exploitability, asset criticality, and exposure, tracking remediation through to verified completion, managing exceptions where remediation is not immediately possible with compensating controls and risk acceptance by appropriate authority, and reporting to management on vulnerability trends and remediation effectiveness.
Annual penetration testing must cover external infrastructure, internal networks, web applications, mobile applications, and API interfaces. ITSEC recommends that testing include social engineering components — phishing simulations and physical security testing — as human factors remain the most exploited attack vector in financial services.
ITSEC has extensive experience supporting UAE banks and financial institutions with CBUAE cybersecurity compliance. Our services include comprehensive gap assessments against CBUAE requirements, policy and procedure development, security architecture design and review, penetration testing across all attack surfaces, SWIFT CSP assessment and remediation, SIEM deployment and correlation rule development, and ongoing compliance monitoring. We understand both the regulatory expectations and the operational realities of banking environments. Contact ITSEC for a banking cybersecurity consultation.
Get a comprehensive security assessment from our expert team. Protecting businesses since 2011.