The pattern we see in CB IBR audits
UAE Central Bank cloud audits land on the same gap categories with surprising consistency. Identity federation that meets Microsoft's reference architecture but not CB IBR's segregation requirements. Audit logging that retains data for the wrong duration in the wrong region. Network segmentation that holds in the Azure portal view but breaks down once payment-systems traffic is traced end-to-end. Third-party cloud-provider controls that are referenced in the policy but cannot be evidenced when the auditor asks.
None of these are technically difficult to fix once flagged. All of them are easier to design correctly from day one than to retrofit. This post walks through the working landing-zone architecture we build for UAE Central Bank-regulated banks on Azure UAE North — the residency-compliant region for banking workloads — and the specific decisions that turn it from a generic Azure landing zone into a CB IBR-compliant one.
For context: CB IBR is the UAE Central Bank Information Security Regulation. It is a mandatory control framework for licensed banks and payment-services providers under Central Bank oversight. The regulation is audited through the Central Bank inspection cycle and compliance is a licence condition.
Region selection: why Azure UAE North
For UAE banking workloads, Azure UAE North is the residency-compliant primary region. AWS Middle East (UAE) is the equivalent on the AWS side and works for AWS-anchored portfolios — the architectural principles below apply equally to either. The decisions that follow assume Azure for specificity.
Azure UAE Central is the paired region for UAE North. Both regions sit inside the UAE national territory, which is what CB IBR residency expectations actually require. International regions of Azure are not residency-compliant for the regulated data classes — they can host non-residency workloads, but the design needs to keep the residency boundary explicit and enforceable.
Subscription and management group topology
The subscription and management group structure is where most banking landing zones diverge from the standard Cloud Adoption Framework. We use a five-level management group hierarchy: tenant root → bank → environment-class → workload-domain → individual subscription. The two CAF-specific additions for CB IBR are an explicit environment-class separation (production, non-production-with-prod-data, development, sandbox) and a workload-domain separation (core banking, channels, analytics, identity, shared services, payment systems).
Payment systems get their own workload-domain branch with stricter policies applied at the management-group level. This means access policies, Azure Policy enforcement, network controls and audit-logging configuration are inherited from the management group rather than configured per-subscription. Configuration drift at the subscription level becomes a policy violation rather than a silent risk.
Identity federation under CB IBR segregation
Identity is the most common audit finding category. CB IBR expects strict segregation between roles administering production banking systems and roles administering supporting functions. The reference design uses Microsoft Entra ID as the primary identity provider with Privileged Identity Management (PIM) enforcing just-in-time elevation for any role with banking-production access.
Three specific decisions matter here. One, no standing access to production. Every privileged role is JIT-elevated through PIM with approval workflows and time-limited activation. Two, segregation of duties enforced at the role-definition level. The engineer who can deploy to production cannot also approve the deployment. Three, identity audit logs streamed to a dedicated Log Analytics workspace with retention configured against CB IBR's seven-year requirement.
Network topology and segmentation
The network topology is a hub-and-spoke with a dedicated payment-systems spoke that has stricter egress and ingress controls than the rest of the estate. Hub virtual network hosts the firewall (Azure Firewall Premium or a partner NGNV), the ExpressRoute gateway and the shared identity and security tooling. Spokes host workload-specific resources with peering through the hub.
Two specific design decisions here. First, payment-systems spoke runs deny-by-default egress with only the specific endpoints approved as exceptions. The default Azure egress posture is far more permissive than CB IBR allows for payment systems. Second, audit-logging traffic from every spoke is routed through a dedicated logging path that does not transit shared services, so a compromise of the shared spoke does not affect the audit trail.
Audit logging and retention
CB IBR specifies audit-log retention periods that exceed Azure's native defaults. The reference design uses a dedicated Log Analytics workspace per environment-class with long-term archive to Azure Storage in the same region. Retention configured against the CB IBR-specified period (seven years for most categories), with immutability enabled on the archive storage so logs cannot be deleted within the retention window even by privileged administrators.
The diagnostic settings on every Azure resource type (VMs, key vaults, storage accounts, SQL instances, network security groups) are deployed via Azure Policy at the management-group level. New resources inherit the logging configuration automatically. There is no "did we enable logging on this VM" question because the policy prevents the resource from existing without logging.
Third-party cloud-provider controls
CB IBR has specific provisions for third-party cloud-provider risk — Microsoft, in this case, as the Azure operator. The bank is responsible for evidencing the cloud-provider controls that meet CB IBR requirements. Microsoft's SOC 2, ISO 27001 and PCI-DSS attestations are the standard evidence base, supplemented by the Azure-specific compliance documentation in the Service Trust Portal.
The provisioning step that most banks skip: a documented mapping between the CB IBR control set and the corresponding Microsoft evidence. Not a generic "Microsoft is compliant" statement — an explicit per-control mapping that the inspector can read line-by-line. We build this mapping as part of the landing-zone delivery and update it annually as Microsoft re-attests.
Payment systems isolation
Payment systems carry the highest regulatory weight in CB IBR. The reference design isolates payment-systems workloads in their own subscription within a dedicated management group, with the strictest Azure Policy set, the dedicated network spoke described above, and a separate identity boundary that requires additional approval workflows beyond the standard PIM elevation.
UAE-specific payment systems (UAEFTS, AANI, the UAE Direct interfaces) have their own connectivity and operating requirements that overlay onto the Azure architecture. ExpressRoute private peering to the relevant payment-network endpoints, with redundancy and the BGP routing configured for the failover characteristics the payment system expects.
What we would do differently
Three things we have learned across CB IBR cloud engagements that did not make it into the initial reference. Stage the policy enforcement. Applying the full CB IBR policy set on day one to a non-greenfield estate produces an avalanche of exceptions that obscures the real findings. Phase it: start with the highest-severity policies, get to clean state, then add the next tier. Build the Microsoft control mapping early. The mapping is not glamorous work and tends to be left until pre-audit. By then the documentation team is under pressure. Better to build it during the design phase. Treat the inspector relationship as continuous. Central Bank inspections are easier when the inspector has working history with the engagement. Annual touchpoints, not just inspection-time, pay off.
Bottom line
CB IBR-compliant cloud is not technically hard. It is architecturally specific. The decisions that matter (management group hierarchy, identity segregation, network topology, audit logging, third-party control mapping, payment systems isolation) are easier to make once with the regulation in front of you than to retrofit after the inspection.
For UAE banks planning their cloud journey or facing a CB IBR audit, the lesson from this reference is that the architectural pattern transfers. The specific control configurations are CB IBR-specific. The operating model that produces clean inspections is consistent across the banks we deliver into.
