Is business intelligence on shared cloud infrastructure a compliance risk for regulated European firms?

Most regulated European firms treat their BI platform as an analytics problem, not a compliance one. That framing is becoming expensive. When a business intelligence stack sits on shared, hyperscaler-managed infrastructure, it pulls in a set of legal and operational exposures that finance, healthcare, and energy teams are only now mapping properly — often because an auditor or regulator forced the question.

The short answer is yes, shared cloud BI creates genuine compliance risk. But the nature of that risk depends on which regulation governs you, what your BI platform actually does with data in transit, and whether your vendor contracts give you the audit and exit rights the law now requires.

Here is a clear-eyed assessment of where the exposure sits and what a sovereign alternative changes.

Where shared infrastructure creates real exposure

The most common misconception about BI platform data residency is that it is purely a GDPR question, and that GDPR is a data residency law. Neither is accurate. GDPR does not prohibit storing EU personal data outside the EEA; it prohibits transferring it there without an adequate legal basis. When your BI platform ingests query logs, user behaviour, or operational datasets and routes them through processing nodes in a US-based region, that routing constitutes a transfer. Standard Contractual Clauses can cover it, but only if a Transfer Impact Assessment confirms that the laws of the receiving country would actually allow those SCCs to hold. Given US surveillance statutes, that assessment is not a formality.

The enforcement record makes the stakes concrete. Meta’s €1.2 billion fine for unlawful EU-US transfers remains the largest single GDPR penalty. TikTok absorbed €530 million in 2025 for failing to protect EEA user data from unauthorised access in China. Cumulative GDPR fines have now crossed €7.1 billion. Regulators are not treating transfer violations as procedural oversights.

GDPR Article 30 adds a documentation obligation that many BI deployments quietly fail: every processing activity, including analytics and BI workloads, must appear in the Record of Processing Activities. A shared-cloud BI platform where you do not control the underlying compute makes that record harder to produce and harder to defend.

DORA has changed the rules for financial BI specifically

For financial firms, the more operationally demanding framework is now DORA. It entered into effect on 17 January 2025 and applies to approximately 22,000 financial entities across the EU. Its reach is broader than most compliance teams initially assumed: DORA explicitly covers firms that provide critical third-party information services, including data analytics providers. Your BI platform vendor is in scope.

DORA requires financial entities to ensure that contractual arrangements with ICT providers include data processing locations, key subcontractor management, audit rights, and credible exit strategies. A multi-tenant SaaS BI contract that lacks those terms is not a minor gap; it is a reportable deficiency.

On 18 November 2025, the European Supervisory Authorities designated 19 ICT providers as critical under DORA, including AWS, Microsoft Azure, and Google Cloud, subjecting them to direct EU supervision for the first time. That designation matters for regulated firms because it changes the due diligence burden: you now need to actively manage those relationships as third-party ICT risks, not treat them as commodity utilities. According to Deloitte’s Wave 3 survey, only 50% of financial institutions expected to reach full DORA compliance by end of 2025, with 38% pushing into 2026. A subsequent Deloitte Luxembourg survey found just 25% of institutions confident in their compliance. The Register of Information dry run in 2024 found only 6.5% of firms passed all 116 data quality checks. The compliance gap is not theoretical.

Multi-tenant BI security risks go beyond the contract

Legal exposure aside, multi-tenant BI security risks have a technical dimension that regulated industry cloud BI teams need to evaluate directly. In a shared-tenancy environment, query engines, caching layers, and metadata stores are partitioned logically, not physically. Misconfiguration events, privilege escalation vulnerabilities, and noisy-neighbour conditions in storage I/O are all more likely than in a dedicated deployment. For healthcare firms processing patient cohort data or energy operators running operational analytics on grid infrastructure, the blast radius of a cross-tenant exposure is not acceptable.

NIS2, which expanded to 18 sectors and became applicable from October 2024, requires essential and important entities to assess ICT supply chain security under Article 21. That assessment must include the provider’s exposure to non-EU government access demands. An organisation that has not evaluated whether its US cloud BI vendor’s CLOUD Act exposure constitutes a supply chain risk is potentially non-compliant with NIS2 risk management obligations, regardless of whether any actual demand has ever been made. The obligation is to assess the risk, not to wait for an incident.

What a sovereign, single-tenant BI architecture actually changes

Moving business intelligence GDPR compliance from a contractual exercise to an architectural one requires three things: data that does not leave the EEA, compute that is not shared with unknown tenants, and vendor contracts that satisfy DORA’s third-party requirements. Those three conditions are easier to meet on dedicated infrastructure under European jurisdiction than on shared hyperscaler tiers.

Network architecture matters more here than it is usually given credit for. When BI pipelines pull from multiple source systems — ERP, CRM, operational databases across sites — latency in the data path affects query freshness and pipeline reliability. We operate 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at all sites. That peering means regulated firms can keep their BI workloads on sovereign infrastructure without sacrificing the low-latency connectivity to hyperscaler-hosted source systems they already depend on. Sovereignty does not require isolation from the rest of the stack.

Single-tenant deployments also simplify the Article 30 record: you know exactly where data is processed, who has access, and what the subprocessor chain looks like. That is not a minor administrative convenience; it is the foundation of a defensible compliance posture when a regulator or auditor asks.

The practical checklist for IT decision-makers

• Audit your BI vendor contract against DORA’s third-party requirements: data processing locations, subcontractor management, audit rights, and exit provisions must all be explicit.
• Run a Transfer Impact Assessment for any BI pipeline that routes EU personal data through US-based processing nodes, even temporarily.
• Map your BI workloads to Article 30 records and verify that the record reflects the actual processing topology, not the contractual one.
• Assess CLOUD Act exposure as a NIS2 supply chain risk, document the assessment, and keep it current.
• Evaluate single-tenant options not only on isolation grounds but on the network performance case: dedicated infrastructure with dense peering can match or beat shared-cloud latency for EU-to-EU BI pipelines.

Regulated firms that have treated shared-cloud BI as a default are now discovering that the compliance cost of unwinding those deployments is higher than building on dedicated, sovereign infrastructure from the start. The question for 2026 is not whether to act, but how quickly the audit timeline forces the issue.