Cloud Security in Abu Dhabi · ADDA, Sovereign Cloud & ADHICS

Abu Dhabi’s cloud adoption is led by the entities with the strictest residency and assurance needs — government on ADDA-aligned and sovereign-cloud platforms, the ADNOC ecosystem migrating analytics and corporate workloads to cloud, ADGM fintechs on Al Maryah Island, and DoH healthcare moving patient and tele-health systems. Macksofy reviews these against the standards that actually govern them: ADDA information-security standards and NESA / UAE IAS at the government and federal level, ADHICS for healthcare, and FSRA / ADGM data-protection for the financial free zone.

Residency is the defining constraint in the capital. Abu Dhabi government and sovereign-investment workloads frequently must remain in-country — Azure UAE Central (physically in Abu Dhabi), AWS me-central-1, or a sovereign-cloud platform such as Core42 — and for some classifications cannot use a hyperscaler at all. Our landing-zone review explicitly verifies region pinning for every regulated workload and its backups, flags default-region drift and cross-region replication that would export data, and validates the documented residency posture against ADDA and NESA expectations.

The assessment starts at the landing zone and identity, not the workload. We review the AWS Organizations / Azure management-group hierarchy, the account/subscription segmentation, the guardrails (SCPs, Azure Policy, deny-by-default networking) and the centralised-logging and break-glass design — then graph the full IAM blast radius: every privilege-escalation path from a low-trust principal to a tenant or org-management account across trust policies, permission boundaries, Azure RBAC and PIM eligibility. In a regulated Abu Dhabi tenant that blast-radius graph is what an internal-audit or NESA reviewer most wants to see.

Posture management runs at breadth, then manual validation. CSPM tooling (Prowler, ScoutSuite, Security Hub / Defender for Cloud) enumerates misconfiguration; we validate and prioritise against the ADDA / NESA control set and the workload’s data classification — public storage, unencrypted volumes, exposed management planes and permissive networking triaged by exploitability and by whether the data is government-sensitive, ADHICS-scoped patient data, or FSRA-regulated. For healthcare we map cloud controls explicitly to ADHICS so the migration doesn’t break the standard.

Workload, container and data-plane review follows. Kubernetes posture (AKS/EKS RBAC, pod-security, node-to-control-plane trust, image provenance), serverless permissions, the secrets-management chain, and the data layer — encryption at rest and in transit, KMS/Key Vault key custody and rotation, and database authentication — are all in scope. For energy clients moving OT-adjacent analytics to cloud, we pay particular attention to the boundary between the cloud analytics estate and the on-prem process network so a cloud foothold cannot become an OT path.

The deliverable is built for the Abu Dhabi reviewer. Findings carry a manually-validated proof, a severity, a data-class-and-regulator-tied business-impact score, and remediation as deployable infrastructure-as-code where possible. The executive summary maps to the ADDA / NESA cloud controls (and ADHICS or FSRA where relevant) and includes the in-country residency attestation and shared-responsibility matrix that government, energy and healthcare governance reviews expect.

Delivery blends remote assessment with capital presence. The review runs largely remotely against scoped read-only audit roles; senior consultants fly Mumbai BKC → AUH (~3.5 hours) for the kickoff, the landing-zone workshop and the exit readout, reaching Al Maryah Island, Masdar City or KIZAD in 30-45 minutes from the airport. For sensitive government and energy scope we agree the access and data-handling model before kickoff, and for sustained programmes we maintain an embedded UAE lead.

Most Abu Dhabi cloud programmes run as an initial deep-dive plus quarterly posture re-reviews tied to migration velocity, with continuous CSPM in between — so the residency, IAM and posture story stays true as the estate grows rather than drifting between annual audits.