Cloud and security · Sovereignty
Sovereign cloud and data residency
We provide sovereign cloud and data residency engineering for enterprises that must control where their data lives and who can reach it: classification of data and the rules that attach to each class, choice of regions and providers, encryption with keys you control, access controls that limit support staff and foreign access, transfer mechanisms where data must cross borders, and evidence for regulators. Sovereignty becomes a set of technical controls and not a claim, and you own the designs and the code.
Checklist · Cloud and resilience
Cloud migration and resilience checklist for regulated firms
A checklist for regulated firms planning a cloud migration, a resilience programme or a security uplift: workload assessment, landing zone, data residency, resilience, security, delivery, third-party risk and evidence.- 01Eight areas that supervisors and auditors ask about, with testable checks.
- 02Resilience and recovery items that are easy to leave untested.
- 03Third-party, exit and data residency questions for the board.
- 04Seven questions to put to any vendor or engineering partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Data classification and obligations
A classification of data by sensitivity and legal regime, with the residency, access and transfer rules that apply to each class and country. - 02
Region and provider strategy
Assessment of cloud providers and sovereign offerings against jurisdiction, ownership, operational control and legal exposure, with a placement decision per workload. - 03
Architecture for residency
Designs that keep data, backups, logs and metadata in the permitted regions, including the services that replicate data globally by default. - 04
Key management and encryption
Customer-managed keys held in hardware security modules under your control, bring-your-own or hold-your-own-key models and separation of key custody from the provider. - 05
Confidential computing
Where needed, workloads that run in hardware-protected enclaves so that data is protected even from the infrastructure operator. - 06
Operational access controls
Limits on provider support access by location and nationality where required, just-in-time approval and logging of every access to your environment. - 07
Cross-border transfer mechanisms
Where data must move, the legal and technical mechanisms, such as standard contractual clauses, transfer impact assessments and pseudonymisation, applied as designed controls. - 08
Multi-cloud and exit
Portability and exit planning so that a change in law, provider ownership or risk can be answered by moving workloads. - 09
Evidence and compliance reporting
Continuous proof of where data is stored and processed and who accessed it, mapped to the regulations and audit questions.
Reference architecture.
Standards and interfaces
What we design against.
- GDPR and cross-border transfer rules
- EU rules on transfers of personal data, including adequacy decisions, standard contractual clauses and transfer impact assessments.
- National data localisation and sector rules
- Requirements in countries and sectors that require data, or copies of it, to stay in-country, such as for banking, health and critical infrastructure.
- Sovereign cloud schemes
- National and EU schemes and criteria such as C5 in Germany, SecNumCloud in France and the EU cybersecurity certification scheme work for cloud services.
- ISO/IEC 27001, 27017 and 27018
- Information security and cloud privacy controls that underpin provider and customer assurance.
- Confidential computing standards
- Hardware-based trusted execution environments and attestation used to prove the state of a protected workload.
- Foreign access laws
- Laws that may compel provider access to data, assessed as part of provider choice and key management.
Data model
The core entities.
- Data class and rule
- Class, legal basis, residency, access and transfer rules by country.
- Workload and placement
- Workload, data classes held, region, provider and approval.
- Key and custody
- Key, purpose, holder, location, rotation and the data it protects.
- Access event
- Actor, role, location, reason, approval, duration and actions taken.
- Transfer record
- Data, origin, destination, mechanism, assessment and approval.
- Provider assessment
- Ownership, jurisdiction, certifications, operational control and exit options.
- Evidence item
- Requirement, control, proof of state, time and reviewer.
When custom development is the right call.
Controls designed in, not added later.
Keys under your control
Encryption keys are generated and held where you decide, with the provider unable to read data without your participation.Restricted provider access
Support and administrative access by the provider is limited, approved case by case and logged.Policy as code
Region, service and configuration rules are enforced automatically, so a developer cannot place data in the wrong region.Data that travels
Backups, logs, telemetry and AI prompts are included in the controls, not only the main database.Verifiable posture
Attestation and continuous checks show the state of the environment to auditors and customers.
From discovery to a system you run.
- 01
Obligations and data review
We map the laws, contracts and sector rules that apply and classify the data and workloads with legal, security and the business. - 02
Provider and architecture options
Providers and designs are compared against the obligations and risk appetite, with cost and capability trade-offs. - 03
Build the controlled foundation
Regions, keys, access controls and policy as code are built and tested, with evidence collection from the start. - 04
Migrate and verify
Workloads are placed according to the design and verified, including backups, logs and metadata. - 05
Operate, report and review
Evidence is produced continuously, and the design is reviewed as laws, providers and offerings change.
Relevant work
Where to see our work.
Related
Keep reading.
Common questions.
- What is the difference between data residency and data sovereignty?
- Residency is where data is stored and processed. Sovereignty is about who has legal and operational control over it, including which laws can reach it. A region in your country operated by a foreign provider gives residency but may not give full sovereignty.
- Does a customer-managed key make a cloud sovereign?
- It is a strong control, because the provider cannot read the data without your key. It does not by itself resolve all questions of jurisdiction, support access or metadata, so we design it together with the other controls.
- Can we use AI services under residency rules?
- Yes, with attention to where prompts, outputs, logs and any fine-tuning data are processed and stored. Private deployments and regional endpoints meet many requirements.
- How do you prove where data is?
- By enforcing region rules in code, continuously checking the configuration and storing evidence of locations and access, which can be shown to regulators, auditors and customers on request.
- Who owns the designs and code?
- You do. The designs, the policies and the code stay yours.