Business intelligence on sovereign cloud: a data warehouse architecture that keeps your analysts and your auditors happy

Finance, legal, and energy teams have spent years building capable BI stacks on hyperscaler infrastructure, and most of those stacks work well technically. The problem surfaces when the auditor arrives, or when legal counsel starts asking where the data actually lives and who can compel access to it. At that point, a well-tuned cloud data warehouse architecture becomes a compliance liability, not because the engineering is wrong, but because the contractual and jurisdictional foundations were never designed with sovereignty in mind.

This post is about closing that gap without rebuilding from scratch. The architecture decisions are tractable. The compliance picture is more nuanced than most BI teams realise, and getting the nuance right is what separates a platform that satisfies auditors from one that creates new questions every quarter.

What GDPR actually requires from an analytics workload

GDPR is routinely described as a data residency law. That description is technically imprecise and leads teams to make the wrong architectural bets. GDPR does not prohibit storing EU personal data outside the EU; it requires that any transfer to a third country have an appropriate mechanism behind it: an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules, backed by a transfer impact assessment where the destination’s legal environment warrants one.

For analytics specifically, Article 30 is the clause that bites hardest. It requires documented records of processing activities, which means your data warehouse needs a lineage model that can answer, at any moment, what data entered the system, from which source, under which legal basis, and what transformations it has undergone. Most hyperscaler-hosted BI deployments treat lineage as a nice-to-have. For any organisation processing EU personal data at scale, it is a legal requirement.

Pseudonymisation and tokenisation are the practical tools here. Tokens replace sensitive fields in the analytical layer; the mapping table stays in a jurisdiction-controlled store. Analysts work with tokens across aggregations and dashboards; the original identifiers never leave the compliant boundary. This is not a workaround: it is the architecture the regulation is designed to encourage.

The Schrems II problem that EU-region hosting does not solve

The more structural issue for sovereign BI platform design is not GDPR residency; it is the US CLOUD Act. The CJEU’s 2020 Schrems II ruling invalidated the EU-US Privacy Shield and placed Standard Contractual Clauses on probation, on the grounds that a contract cannot shield data from a foreign state’s surveillance apparatus. The ruling’s core finding has not been reversed. The EU-US Data Privacy Framework that replaced Privacy Shield in 2023 survived its first legal challenge in September 2025 but remains under appeal, and organisations relying solely on it are advised to maintain SCC backup mechanisms.

The CLOUD Act reaches any provider with a US parent regardless of where the servers physically sit. Data residency in an EU region does not remove the transfer risk; it just changes the label on the problem.

Schrems II compliance requires that data be unintelligible to government authorities. Provider-managed encryption fails this test because a cloud vendor can be compelled to decrypt. The architecture that removes the question entirely is infrastructure operated by an EU-jurisdiction entity with encryption keys in the customer’s own custody. There is then no US nexus to compel and, in law, no third-country transfer at all. That is not a marketing position; it is the logical conclusion of the case law.

DORA and the outsourcing accountability trap

Financial institutions running BI workloads face a second layer of obligation since January 2025, when DORA (Regulation EU 2022/2554) became applicable. DORA treats cloud contracts as outsourcing arrangements, and the EBA’s guidelines on outsourcing are explicit: a financial institution’s responsibility for its own activities cannot be outsourced, regardless of a provider’s certifications. Your cloud vendor’s ISO 27001 certificate does not transfer accountability to them.

DORA also requires financial entities to map their third-party ICT dependencies and avoid excessive concentration with a single provider or small group of providers. A BI stack that runs entirely on one hyperscaler, using that hyperscaler’s proprietary warehouse, query engine, and visualisation layer, is exactly the concentration risk the regulation is designed to limit. The audit right must be contractually guaranteed; the data residency and processing locations must be documented; subcontractor relationships must be understood and disclosed.

For EU data residency analytics in the financial sector, this means the architecture choice and the vendor contract are inseparable. A technically sound warehouse on infrastructure that cannot satisfy DORA’s audit and concentration requirements is not a compliant deployment.

A reference architecture for compliant EU BI

The architecture that satisfies both analysts and auditors has five layers, and sovereignty is a property of the stack as a whole, not any single component.

• Ingestion and pseudonymisation boundary: Data enters through a pipeline that applies tokenisation before anything reaches the warehouse layer. The token vault lives on storage with contractually guaranteed EU jurisdiction. This is where GDPR Article 30 lineage records are generated.
• Warehouse layer: Open-standard columnar formats (Parquet, ORC) on object storage you control, queryable via an engine you can run on your own infrastructure. Avoiding proprietary warehouse lock-in is both a DORA concentration requirement and a practical migration hedge.
• Compute layer: Separated from storage so you can scale query capacity independently. Managed Kubernetes or bare metal depending on query latency requirements. The key property is that compute runs in an environment where you hold the encryption keys.
• Semantic and access layer: Role-based access control tied to a corporate identity provider, with column-level and row-level security enforced at the engine, not the application. Every query is logged with the identity that issued it: this is your Article 30 audit trail in operational form.
• Observability and lineage: Data lineage tooling that traces every transformation from source to dashboard, exportable in a format your auditors can read without vendor tooling. OpenLineage is the open standard worth building around.

What the infrastructure contract needs to say

The architecture above only delivers its compliance properties if the infrastructure underneath it is governed by the right contract. This is where the operational and contractual terms matter as much as the technical design.

We run this class of workload on Tier III, carrier-neutral infrastructure certified to ISO 27001, with a contractual 99.9% uptime SLA. The word contractual matters: a hyperscaler’s SLA is typically a credit mechanism, not a legal commitment. When an auditor or a regulator asks for evidence of resilience, a contractual SLA backed by an EU-jurisdiction entity is a different document from a service credit table in a US company’s terms of service. Sovereignty here is not a feature flag; it is a term in the agreement.

NIS2 (Directive EU 2022/2555, which replaced the original NIS Directive in October 2024) brings data centres and cloud computing services into scope as essential entities under digital infrastructure, with proactive supervision, reporting obligations, and supply chain audit requirements. That means your cloud provider’s security posture is now part of your own NIS2 compliance evidence. An ISO 27001-certified provider operating under EU law, with contractual audit rights, closes that supply chain loop cleanly.

Migration without a rewrite

The most common objection to moving a BI stack to sovereign infrastructure is the cost of rebuilding. In most cases, the rewrite is not necessary. If the warehouse layer is already on open formats, the migration is a data movement exercise with a configuration change at the query engine. The pseudonymisation boundary can be inserted as a pipeline stage without touching downstream dashboards. The access control model maps to any OIDC-compatible identity provider.

What does require deliberate effort is the contract layer: renegotiating or replacing vendor agreements to include the audit rights, residency guarantees, and concentration disclosures that DORA and NIS2 now require. That work is not optional, and it is easier to do it once, on infrastructure designed for it, than to retrofit contractual sovereignty onto a stack built for scale without it.

Analysts want fast queries and stable dashboards. Auditors want documented lineage, jurisdictional clarity, and contractual accountability. These requirements are not in tension; they point to the same architecture. Build the stack on open standards, put the keys in your own custody, and make sure the infrastructure contract says what your legal team needs it to say.