This guide details the blind spots that the region box leaves open, with a concrete method for checking them yourself, supplier by supplier. For the complete GDPR and CLOUD Act framework, see our guide GDPR compliant and EU sovereign backend. Here, the angle remains practical: what is really missing from the region selector, and how to check it in less than an hour.
The essentials
A cloud provider's region selector typically configures the primary base, not the other four layers that determine actual exposure: backups and recovery plan, logs and telemetry, third-party contractors (support, emailing, analytics), and the nationality of the operating company. A six-step checklist allows you to verify these points using public documents: DPA, privacy policy, technical documentation. Checked in the Aurabase deployment repository: production backups point to Falkenstein's Hetzner object storage, not to a third-party bucket located outside the EU.
What the region box actually configures
A cloud provider's region selector usually changes one specific thing: the geographic area where the primary database stores its files. AWS RDS in eu-west-1, Cloud SQL in europe-west1, or the equivalent in a BaaS: this setting determines the datacenter which hosts the tables and indexes in normal operation. This is real and verifiable information, but it only covers a fraction of the processing chain of personal data.
A Postgres project produces data elsewhere than in its main tables: query logs, monitoring metrics, debug traces, application caches, backups. Each of these flows can follow a location policy distinct from the primary database, configured separately, sometimes even by default without a dedicated screen in the console. The region setting does not automatically cover them.
A good practice is to ask the provider for an exact diagram of their data architecture, not just the name of the region displayed in the dashboard. A serious supplier documents this architecture. A supplier who only responds “we are GDPR compliant”, without verifiable technical details, leaves a signal to be questioned.
The nationality of the company weighs as much as the geography of the server
Even with a database and backups physically in the EU, a provider remains subject to the American CLOUD Act as soon as the company operating it has a legal presence in the United States. The law targets the legal entity, not the data center: it is the nationality of the company that triggers the obligation, not the location of the hard drive.
This mechanism is detailed in our analysis why the CLOUD Act changes the choice of your BaaS and in our article dedicated to the nationality of the provider. This section is limited to the quick check method.
To verify this point without prior legal advice, look for the words “data controller” or “data controller” in the provider’s privacy policy, and the applicable law clause in its general conditions. These two lines are generally sufficient to identify the actual contracting entity, regardless of the brand name displayed on the site.
A managed Postgres database generally replicates its backups to object storage separate from the primary machine, for durability and disaster recovery plan reasons. This storage follows its own network configuration (endpoint, bucket, sometimes region), which is not automatically the one displayed in the main console selector.
Checked in the Aurabase deployment repository (values.hetzner.yaml): the variable that points CloudNativePG backups to the storage object reads fsn1.your-objectstorage.com, the Hetzner endpoint of Falkenstein, in the same German perimeter as the primary cluster, not a third-party bucket located elsewhere. This is exactly the type of configuration line to ask any vendor before signing: not "are your backups secure", but "what endpoint URL do they point to".
If a vendor can't answer this specific question, or only links to a general marketing page, treat the answer as unverified rather than reassuring.
Sub-processors: support, emailing, analytics
A backend is almost never an isolated service. It relies on subcontractors: a customer support tool, a transactional email sending service, an analytics or error tracking platform. Each of these tools can process, even briefly, data passing through your application, with its own location, independent of the region chosen for the database.
The GDPR requires the data controller to know this string (Art. 28 and 30). A serious supplier publishes the list of its own sub-processors, with their role and location. A missing or obsolete list is a signal to question before signing, not after a compliance audit imposed by a client. See the DPA Aurabase page for an example of this type of document.
A US support tool with access to customer tickets may expose personal data to a different jurisdiction than the database, even if the database remains physically in the EU. Explicitly ask which third-party tools have access to production data, and under what jurisdiction they operate.
The six-step checklist for checking beyond the region box
This is the method used to verify the facts cited in this guide, applicable to any cloud or BaaS provider in less than an hour, without prior legal advice.
| Step | Where to check | What should appear |
|---|---|---|
| 01 · Primary base | Vendor console, region page | The exact name of the data center, not just the “EU” label |
| 02 · Backups and DR | Technical documentation, doc backup | The endpoint or destination region of the backups |
| 03 · Logs and telemetry | Privacy policy, doc monitoring | Location of logs, metrics and traces collected |
| 04 · Subprocessors | “Sub-processors” or DPA page | A dated, up-to-date list with the jurisdiction of each |
| 05 · Operating company | Privacy policy (“data controller”) | The legal name and country of incorporation of the company |
| 06 · Applicable law | General conditions, “governing law” clause | The jurisdiction under which the contract is signed |
These six answers generally fit on a single page, when collected. Keep them: they also serve as proof during a compliance audit or a review by a DPO.
What this changes for your Art register. 30 and a DPIA
The register of processing activities (Art. 30 GDPR) requires documenting, for each subcontractor, its location and the applicable transfer guarantees. A region box checked without details of backups, logs and subsequent subcontractors leaves this register incomplete, a point that is generally noted by the first visit by an auditor or an external DPO.
For high-risk processing, health data, biometrics, large-scale profiling, a data protection impact analysis (DPIA, Art. 35) becomes mandatory. The six answers from the previous checklist provide a direct basis for this analysis: they answer its central question, where the data actually goes, and under what authority.
This checklist is used to quickly qualify a supplier before investing time in technical integration. For high-risk treatment or a multi-year contract, a review by a DPO or a specialist lawyer remains recommended before signing.
For the full GDPR framework and self-hosting vs sovereign BaaS arbitration, see our GDPR compliant and EU sovereignguide. For Aurabase compliance documentation, see GDPR.
FAQs
A checked region box is not proof of GDPR compliance. This is a starting point, not a conclusion. The complete verification covers five distinct layers: the primary database, backups, logs, subcontractors and the operating company.
The method described here takes less than an hour and relies solely on public documents. Apply it before signing, not after an audit imposed by a client or a regulator.