Organisations operating at scale across US federal, UK, and UAE markets face a compliance architecture challenge that single-jurisdiction organisations do not: three regulatory regimes with different data residency requirements, different encryption standards, different audit log retention periods, and different breach notification timelines. The naive solution is to run three separate production stacks, one per jurisdiction. The operational cost — three times the infrastructure, three times the deployment complexity, three times the monitoring surface area — is prohibitive. The architecture that satisfies all three regulators with a single shared codebase and jurisdiction-specific configuration exists, but it requires explicit design.
The Three Regimes and Their Non-Negotiables
FedRAMP (US federal) requires: data processed and stored exclusively in FedRAMP-authorized regions (specific AWS GovCloud, Azure Government, or GCP government cloud regions), encryption using FIPS 140-2/140-3 validated modules, audit log retention for a minimum period defined by the security baseline (typically three years for Moderate), and continuous monitoring with defined reporting cadences to the authorising official. UK NCSC Cloud Security Principles require: demonstrable control over data location (principle 2), supply chain security evidence (principle 9), and audit trail availability to the customer (principle 13). UAE NESA standards require: data classification of all processed data into defined sensitivity categories, localisation of certain classified data within UAE data centres, and implementation of NESA-aligned security controls for each classification level.
The apparent conflicts are in data residency: FedRAMP requires US-only processing for federal data. UAE NESA requires UAE-resident processing for certain data categories. UK NCSC requires data location control without mandating UK-only processing. The architecture must route data to the appropriate residency zone based on data classification and originating jurisdiction, while sharing as much non-regulated infrastructure as possible.
The key architectural insight for multi-jurisdiction compliance is separating the data plane from the control plane. The control plane — the code, the CI/CD pipeline, the monitoring infrastructure, the secrets management system — can be shared across jurisdictions if it does not process regulated data. The data plane — the compute and storage that handles customer data — must be jurisdiction-specific. This separation is what makes a shared codebase with jurisdiction-specific deployment viable.
Data Classification as the Routing Layer
Every piece of data that enters the system must be classified at ingestion with a residency requirement: US-FedRAMP-required, UAE-localised, UK-only, or unrestricted. This classification drives all subsequent routing decisions — which data store the data is written to, which compute processes it, which region it is replicated to. The classification must be enforced at the infrastructure layer, not the application layer: application-layer enforcement can be bypassed by bugs or developer errors; infrastructure-layer enforcement via IAM policies and network controls is enforced by the cloud provider.
Encryption Architecture Across Three Regimes
FedRAMP requires FIPS 140-2/140-3 validated cryptographic modules. UK NCSC requires encryption using approved algorithms (FIPS-validated algorithms satisfy this). UAE NESA requires encryption but does not mandate FIPS validation, accepting AES-256 and RSA-2048 or better. FIPS 140-2/140-3 validated implementations of AES-256 and RSA-2048 satisfy all three requirements simultaneously. The practical implication: deploy FIPS-validated cryptographic libraries across all environments, not just the US FedRAMP environment. This eliminates the need to maintain different encryption implementations per jurisdiction.
Audit Log Architecture
The three regimes have different audit log retention requirements. FedRAMP Moderate baseline requires three years. GDPR (applicable in the UK context) does not mandate a specific retention period for security logs but most organisations interpret it as one to three years. UAE NESA requires retention periods aligned with the data classification of the logged data. A three-year retention baseline applied uniformly across all environments satisfies the most stringent requirement and avoids managing different retention policies per jurisdiction.
- Separate data plane (jurisdiction-specific) from control plane (shared) — this is the foundational architectural decision
- Implement data classification at ingestion with residency tags enforced at the infrastructure layer, not the application layer
- Deploy FIPS-validated cryptographic libraries across all environments — this satisfies FedRAMP, UK NCSC, and UAE NESA simultaneously
- Use three-year log retention as the baseline across all jurisdictions — align to the most stringent requirement
- Build jurisdiction-aware data routing into the infrastructure provisioning process, not into application code
- Test residency enforcement quarterly: attempt to write UAE-classified data to a US environment and verify the attempt fails
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.