You select a European cloud region. Your application database is there. Its backups may use a separate service; logs may leave through a monitoring agent; a support ticket may contain a customer record. The region setting describes one part of that arrangement.
A useful sovereignty review starts with one dataset and follows it through the system. A customer record, an uploaded document, or an AI prompt is small enough to trace and specific enough to expose gaps.
Follow the copies
Write down where the data is stored, processed, cached, and backed up. Include exports to analytics tools and copies in development environments. For AI applications, include the prompt, retrieved documents, response, and conversation history.
For each destination, record the service, location, retention period, and responsible team. Where an answer is unknown, leave it marked as unknown. An assumption that a backup uses the same region as the database is something to verify.
The result can be a short table. It needs to describe the system you run today, including the integrations added after the original architecture was approved.
Name the people and systems with access
Check customer administrators, provider operators, support staff, service accounts, and subcontractors. Distinguish access that is permanently available from access granted for a specific task. Find out how it is approved, recorded, and revoked.
Encryption also needs a more precise description than “encrypted at rest.” Who holds the keys? Can the provider obtain plaintext while operating or supporting the service? What happens if your team loses access to the key service?
Take those answers to whoever handles contracts and data protection. A data-centre address does not settle the legal questions about access or international transfers. The EDPB's guidance on transfers explains why making data available to another organisation outside the EEA can matter, even without moving the primary database.
Try an export that you could actually use
Choose a representative sample and export it. Check whether the output includes attachments, metadata, permissions, and the relationships between records. Load it into a separate environment and see what is missing.
An application may store its main data in PostgreSQL while depending on a proprietary identity service or job runner. Exporting the database gets you part of the way. Record the other dependencies and the work needed to replace them.
Keep the export commands, elapsed time, and any charges with the review. The private and public cloud comparison looks at these operational choices in more detail.
Turn the gaps into specific changes
You might decide to move backups, reduce support access, change a retention setting, or replace one integration. A full migration is only one possible outcome.
At Anchras, we host the control plane in the EU and let customers choose workload placement. That still leaves a data-flow review to do: the control plane, customer infrastructure, and any connected external services each have a role. For AI traffic, the gateway architecture shows where requests are processed before they reach a model.
Keep the map alongside the system documentation. Revisit it when you add a provider, change a route, or give another team access. Those are the moments when the answers can change.