--- title: "Sovereign and regulated cloud" description: "Data residency, customer-held keys, sovereign cloud offerings, regulated landing zones and exit plans for financial services, healthcare and the public sector." url: https://www.expandware.com/services/cloud/sovereign-and-regulated-cloud/ section: "Services" topics: ["Cloud", "EU Data Act", "DORA", "EBA outsourcing guidelines", "UAE PDPL"] publisher: "Expandware Private Limited" --- # Sovereign and regulated cloud Data residency, customer-held keys, sovereign cloud offerings, regulated landing zones and exit plans for financial services, healthcare and the public sector. Cloud for workloads that answer to a regulator. Regulated organizations can use the cloud, but they have to be able to show where data lives, who can reach it, who holds the keys and how they would leave. We design for those questions from the first decision: regions and residency, encryption with keys you control, sovereign and in-country offerings where the law requires them, operator access that is logged and limited, and an exit plan a supervisor will accept. Where it usually starts: - A regulator or customer requires data to stay in a specific country. - Outsourcing rules require an exit strategy for every critical cloud service. - Encryption keys are held by the provider, and that is no longer acceptable. - A public sector contract requires a sovereign or government cloud offering. What is included: - Residency design: Regions, replicas, backups and logs placed where the law or the contract requires. - Key custody: Customer-managed and externally held keys, with hardware security modules where needed. - Regulated landing zones: Guardrails, logging and access controls mapped to your regulator's rules. - Sovereign offerings: In-country and sovereign cloud services assessed and implemented. - Operator access controls: Support and administrative access limited, approved and logged. - Exit planning: Documented, tested plans for leaving each critical provider. Where it sits: Sovereign and regulated cloud governs two parts of the cloud architecture: the identity and policy that decide who and what may run where, and the sovereign region where data that must stay in a jurisdiction lives. Decisions to settle early: - Sovereign offering or standard region. Sovereign services cost more and offer less; standard regions may meet the law with the right controls. Only workloads that need sovereignty use it. - Who holds the keys. Provider-managed keys are simplest; customer-managed or external keys give more control and more responsibility. The regulator's expectations decide. - How far to plan the exit. An exit plan must be credible to a supervisor without becoming a second migration project. We plan to the depth your regulator expects. How the work runs: Map, Obligations, data and jurisdictions. Design, Residency, keys and access. Build, A regulated landing zone as code. Evidence, Controls documented for supervisors. How it is bought: - A fixed-fee assessment: We map the obligations that apply to your data and workloads and review the current design against them. You receive the requirements map, the gaps and a fixed price for the regulated landing zone. - A fixed-price build: Residency design, key management, the regulated landing zone as code and exit plans for each critical provider, at a fixed price. - Running it afterwards: Ongoing operation can include evidence upkeep for supervisors and periodic exit plan tests, under a monthly retainer. Worked example, data that must stay in the country. Say a payments company in the Gulf wants to move workloads to the cloud, but its regulator requires customer data to stay in the country, keys to be under its own control, and an exit plan for every critical provider. - Map: We record each obligation from the regulator, the data protection law and customer contracts, and map them to the data each workload holds. - Design: Regions, backups and logs are placed in the country, and encryption keys are held in hardware security modules the company controls. - Build: A regulated landing zone is built as code, with residency guardrails that stop resources being created anywhere else. - Evidence: Controls are documented against each obligation, and an exit plan for each critical provider is written and tested before the supervisor reviews it. At the end, the company can show its regulator where every copy of its data lives, who can reach it and how it would leave, and the guardrails keep the design from drifting. (An illustration, not a client account.) What you have at the end: - Regulatory requirements map: Each obligation that applies to your data and workloads, where it comes from, and how the design meets it. - Data residency and flow diagrams: Where data, replicas, backups and logs are stored and processed, and every path by which they move. - Key management design: Who holds which keys and where, how they are rotated, and how access to them is controlled and logged. - Regulated landing zone as infrastructure code: The cloud foundation with residency, access and logging controls built in, defined in code. - Exit plan for each critical provider: How each critical service would be moved or replaced, with the data, time and contracts involved. Standards and platforms worked with: EU Data Act, DORA, EBA outsourcing guidelines, UAE PDPL, SBP cloud outsourcing framework, ISO/IEC 27017, ISO/IEC 27018, Hardware security modules. Where it goes wrong, and what we design out: - Residency for the data, not its copies. Backups, logs and support diagnostics often leave the jurisdiction unnoticed. Every copy is placed deliberately. - Keys held by the provider. Provider-held keys can fall short of what a regulator expects. Customer-held or external keys keep that control with you. - An exit plan never tested. A supervisor expects an exit to be credible. Plans are tested before they are relied on. What it changes: - Residency you can prove. Diagrams and configuration show exactly where each data set lives and moves. - Keys under your control. Encryption keys are held where the provider cannot use them without you. - An exit you could execute. Leaving a provider is planned and rehearsed, which is what supervisors now ask to see. How you will know it is working: - You can show where every copy of regulated data lives. - Guardrails stop resources being created outside permitted regions. - Key access is logged and controlled by you. - Each critical provider has a tested exit plan. Who you work with: - Regulated cloud architect. Maps obligations to design and owns the residency and key management architecture. - Cloud engineers. Build the regulated landing zone and its guardrails as code. - Compliance specialist. Documents controls against each obligation and prepares evidence for supervisors. What we need from you: - The regulations and contracts that apply to your data. - Access to the cloud accounts in scope. - Your risk and compliance owners. - Contracts with the cloud providers involved. Common questions: Q: Is a sovereign cloud different from an ordinary cloud region? A: Usually, yes. A region places data in a country; sovereign offerings add commitments about who operates the service, which law governs access and where support staff are located. Whether you need one depends on your regulator and your contracts. Q: Can we hold our own encryption keys? A: Yes. All the major providers support customer-managed keys, and several support keys held outside the provider in your own hardware security module, which prevents the provider using them without you. Q: What does an exit plan need to contain? A: The data and services involved, how data would be extracted and in what format, the target platform, timelines, costs and the people responsible, tested at least in part so the plan is known to work. Q: Can you support data residency in the UAE or Pakistan? A: Yes. Major providers and local operators offer in-country capacity in both, and we design residency, backup and support access around the specific rules that apply to you. Q: Can logs and backups stay in the same jurisdiction as the data? A: Yes, and they should be designed with it from the start, because they are the copies most often overlooked. Logs, backups, replicas and support diagnostics are all placed deliberately, and guardrails block services that would send them elsewhere. Q: What is an external key manager? A: A key management system outside the cloud provider, held by you or a third party, which the provider's services call whenever they need your keys. The provider cannot read protected data without a request your key manager can refuse, which gives you a control the provider cannot override. Q: How do regulators view cloud outsourcing? A: Most financial and public sector regulators permit it, with conditions: a risk assessment, a register of outsourcing arrangements, contractual rights of audit and access, resilience, and an exit strategy. The details differ by regulator, so the requirements map lists your regulator's rules specifically. Q: Does sovereign cloud cost more? A: Often somewhat more, and it may offer fewer services or regions. The real question is which workloads need it. We place only the data and workloads that require sovereignty in those offerings and keep the rest on standard services, so the premium is paid only where the law demands it. Often paired with: Governance, risk and compliance, Hybrid and private cloud, Colocation, remote and smart hands. --- Canonical page: https://www.expandware.com/services/cloud/sovereign-and-regulated-cloud/ Site index for machines: https://www.expandware.com/llms.txt Full site text: https://www.expandware.com/llms-full.txt Expandware Private Limited. Inquiries: solutions@expandware.com, +92 (333) 32 11011.