Embedded analytics for EU data sovereignty

Map every flow before you choose a platform. In a typical embedded BI stack, data moves through at least five places: the source databases that hold customer records, the analytics database or cache that serves queries, the BI application database that stores dashboards, users, groups, row-level rules and embedding settings, and the outputs the tool produces, including query logs, scheduled alerts and reports, and dashboard thumbnails. Each of these can sit on different infrastructure, and a US-hosted tool may write to any of them. Support tooling adds another path: a vendor engineer who views a customer dashboard from outside the EU is making a transfer under EDPB Guidelines 05/2021, even if nothing is stored there. Ask your current vendor where each item lives, who can access it and from which countries.

Pay particular attention to the vendor's own metadata. A US-headquartered SaaS BI product may keep usage analytics, error telemetry, account records or embedding configuration in its own cloud, outside the EU, even when your query data stays in your database. Ask for the vendor's data location list by category, its sub-processor list and whether support staff can reach your tenant from outside the EEA. For a self-hosted option such as Apache Superset or Metabase, the same questions still apply to the components you deploy, such as the caching layer and the worker processes that generate alerts, reports and thumbnails, because they handle the same customer data. Confirm the exact components for the version you plan to run, since the Superset architecture documentation describes them.

Turn the map into a decision record. For each flow, note the data category, the storage location, the processing location, the role of the party that accesses it, and the legal basis for any transfer. Flows that cross the EEA boundary need a transfer mechanism or a decision to remove them. Flows that stay in your EU account, with EU-based operators and no remote access from third countries, are the ones a self-hosted design can keep inside the boundary. Use this map as the input to your processor assessment and your data processing agreement, and reuse it when you evaluate platforms, so the comparison is based on your flows rather than on vendor claims.

The data processing agreement is only as strong as the isolation behind it. If one customer's dashboard can return another customer's rows, no contract clause fixes that. Each customer's rows must be filtered at query time, through row-level security or an equivalent mechanism, and the filter value must come from a trusted identity claim set by your authentication system, never from a parameter the browser or the user can edit. Decide early which identity source is authoritative (your SSO provider, your application's session, or a signed token your backend issues) and make the filter key, such as a tenant or account identifier, come only from that source. The two platforms reach this in different ways, and you should not assume parity. In Apache Superset, row-level security rules are defined in the application and attached to roles, so the filter applies to users who hold a role, and group or OAuth role mapping through AUTH_ROLES_MAPPING determines who gets which role. In Metabase, row-level permissions are a paid capability on the Pro and Enterprise plans, and per-customer isolation for external viewers is usually built with signed (guest) embedding, where the backend signs a token that carries the filter values. Confirm in your chosen versions how each mechanism passes the tenant value, how it behaves when a claim is missing (it should deny, not show everything), and whether dataset-level caching or saved questions can bypass the filter. Treat cross-tenant leakage as a test you run, not an assumption you hold. Create at least two test tenants with distinct data, then try every path a viewer can reach: direct dashboard URLs, filter parameters edited in the browser, exports, scheduled reports, alerts, cached query results and API calls. Record the results as evidence for your assessor. Ask your implementation partner to show the test cases, the expected and actual results, and who re-runs them after each upgrade, because a version change can alter how these mechanisms behave.

Start the data processing agreement with a processing location clause that names the EU data centers or cloud regions where the Superset or Metabase application servers, the metadata database, the cache and any analytics database run, and that forbids moving any of them without written notice. Add the same specificity to backups, log storage and dashboard thumbnail caches, because Superset's alerts, async queries and thumbnails depend on the caching layer and Celery workers, and each of those components holds query results or rendered data. Next, restrict remote access from third countries, and say expressly that screen sharing, live support sessions and vendor engineers viewing data in a console count as access. The EDPB guidance treats displaying data on a screen from a third country as a transfer, so the clause should cover support staff located outside the EEA, follow-the-sun rotations and break-glass accounts. Ask counsel whether the controller also wants an incident process for any unplanned access.

Require a sub-processor list that gives each party's legal entity, service, hosting location and access type, plus a notice period before any change. Cover the managed hosting, managed database, email relay and support tooling vendors, not only the software publisher. For government access, draft a clause requiring the processor to notify the controller of any request from a public authority, to challenge overbroad requests where it lawfully can, and to disclose only the minimum data. Name GDPR Article 48 in the clause so recognition of a third-country order depends on an international agreement. The CLOUD Act provision at 18 U.S.C. 2713 applies to US providers regardless of data location, so ask any US-parented vendor for its written position on that exposure. This is a legal and transfer-impact decision for the controller and counsel, as are any standard contractual clauses under Decision (EU) 2021/914.

Add switching and exit commitments under the EU Data Act, which gives customers the right to move to another provider or to on-premises infrastructure on a maximum two-month notice period with a 30-day transition, and which bans switching charges from 12 January 2027. Because the platform is self-hosted, the practical exit is a data export of the metadata database, dashboards, datasets and row-level security rules, so write the export format and the deadline into the agreement. Finally, specify deletion or return on exit: the date for return, the certified deletion of the application database, backups, caches and logs, and the evidence the controller will receive. Confirm with counsel how these clauses map to the controller's own records of processing and whether any sector rules, such as DORA for financial entities, add terms.

Start with where data and people can reach it. Ask the partner to name every location where the dashboard data will be stored, cached, backed up and processed, including the Superset metadata database, any caching layer, Celery workers, logs and the Metabase application database. Then ask who holds administrative access, from which countries those staff connect, and whether any support session can display customer rows on a screen from outside the EEA, since the EDPB guidelines treat that as a transfer. Ask how access is granted, logged and reviewed, and whether the partner will commit to these answers in the agreement rather than in a sales call.

Ask how row-level security is enforced and how it is tested per tenant. For Superset, ask whether row filters are applied through the embedding token or through a role-based rule, and who verifies that a customer token cannot widen its own filter. For Metabase, ask which plan they assume: row and column level permissions, multi-tenant data segregation and SSO are included only in the Pro and Enterprise plans, so the license cost belongs in the quote. Ask for the test cases they will run against two sample tenants, the written results they will deliver, and how a new tenant is onboarded without a manual step that could leak data. Ask how the Superset SECRET_KEY and PREVIOUS_SECRET_KEY rotation will be handled, and who holds those secrets.

Ask how upgrades will be run and what evidence each change leaves behind. The partner should describe backing up the metadata database, running superset db upgrade and superset init in staging first, and reading UPDATING.md for breaking changes. For Metabase, ask how they will plan around the migration lock and the release-by-release upgrade path, and which LTS line they will pin. Ask which Kubernetes option they recommend, since the Helm chart is marked deprecated in current documentation in favor of the Apache Superset Kubernetes Operator. Finally, ask what they will not do: they should state plainly that they prepare controls and evidence for a DPA review but do not issue certifications, audit reports or attestations, and that a fixed-scope written statement of work defines deliverables, acceptance tests and exclusions before work starts.

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, which for this topic means your EU cloud accounts, data centers or private network. For an embedded analytics deployment that usually covers the Superset or Metabase application tier, its metadata database, the caching and worker components if alerts, async queries or thumbnails are in scope, the SSO integration with your identity provider, and the analytics database connections. The first decision is where each of those components runs and who holds administrative access to them, because a self-hosted stack moves the data-processing question to your own infrastructure only if the hosting, backups, logs and support access all stay in the EU as well. Write that boundary into the scope before any build work starts.

Engagements are fixed-scope. Scope, deliverables, environments, acceptance criteria and timelines are agreed in writing before work begins, and the written scope is also the basis for a quote, since DeployOpen does not publish a price list. For this use case, that scope should name the row-level security model per customer, the guest token or SSO embedding flow, the test environment used for upgrades, and the backup and restore procedure for the metadata database. Security testing of the embedded surface can be included in the same scope, covering the application, its APIs and the tenant boundary, so that cross-tenant access is tested before customers see it. Ongoing upgrades, monitoring and support are available as retainers, which matters because Superset and Metabase both ship releases that require database migrations and staged testing. DeployOpen prepares systems, controls and evidence that your team can use in a data processing agreement review, a transfer impact assessment or an audit, including configuration records, access reviews, backup and restoration logs, and documentation of where each component runs. It does not issue audit reports, attestations or certifications, and it does not decide whether your processing is lawful. Those conclusions belong to your data protection officer, legal counsel and the independent auditor or certification body you engage. Confirm in writing which artifacts DeployOpen will deliver, in what format, and who signs off on them.