UK GDPR vs. GDPR: vendor registry differences that matter to your client base

What is being compared

UK GDPR and GDPR share a common legislative ancestry and an identical document checklist, but they are distinct legal frameworks administered by different authorities across different territories. GDPR covers 30 EEA jurisdictions — all EU member states plus Iceland, Liechtenstein and Norway [src:regime/gdpr]. UK GDPR covers one jurisdiction: Great Britain [src:regime/uk_gdpr].

Both regimes are triggered in the same functional way. GDPR is triggered by registration in the EEA or by having customers in the EEA [src:regime/gdpr]. UK GDPR is triggered by registration in the UK or by having customers in the UK [src:regime/uk_gdpr]. A client with a UK entity that also sells to EEA customers may be in scope for both simultaneously, requiring vendor DPA coverage under each legal framework [src:regime/gdpr] [src:regime/uk_gdpr].

The document sets required under each regime are identical: privacy policy, cookie policy, DPA, subprocessor list, ROPA, retention schedule, and DSAR procedure [src:regime/gdpr] [src:regime/uk_gdpr]. That surface similarity is where the trouble starts. Consultants working from a document checklist alone will not see the divergences that sit underneath it — in transfer mechanisms, supervisory authority scope, and whether a vendor's published DPA actually covers the UK legal framework at all.

Where they differ

Supervisory authority and breach notification

Both regimes impose a 72-hour breach notification deadline [src:regime/gdpr] [src:regime/uk_gdpr]. The recipient differs. Under GDPR, notification goes to the competent EEA supervisory authority — whichever national authority has jurisdiction over the controller [src:regime/gdpr]. Under UK GDPR, it goes to the Information Commissioner's Office [src:regime/uk_gdpr]. Both regimes also require notification to affected individuals without undue delay where there is a high risk to those individuals [src:regime/gdpr] [src:regime/uk_gdpr]. A client in scope for both regimes at the same time must be prepared to notify two separate authorities from a single incident. Your GDPR breach register template will need a column for which authority received which notification.

Transfer mechanisms

This is the most consequential practical difference in vendor management. Post-Brexit, the UK operates its own transfer regime. EU Standard Contractual Clauses do not automatically extend to transfers from UK controllers to third-country processors. A UK client needs either a UK Addendum to the EU SCCs or an International Data Transfer Agreement (IDTA) — the UK's own transfer instrument.

Supabase uses SCCs as its transfer mechanism and offers data regions in the EU, US and APAC [src:vendor/supabase]. Metabase Cloud also uses SCCs and offers data regions in the US, EU, LATAM and APAC [src:vendor/metabase-cloud]. Neither vendor records a distinct UK transfer mechanism in the source data [src:vendor/supabase] [src:vendor/metabase-cloud]. That does not mean one is absent from their DPAs — it means a consultant cannot confirm it from the published record alone and must read the DPA text directly.

Where a vendor lists an EU data region but not a GB data region, a UK-entity client placing data in that region should verify whether the contractual and transfer mechanism terms extend to UK law [src:vendor/supabase] [src:vendor/metabase-cloud]. Selecting an EU data region on a self-service dashboard does not resolve the question of which legal instrument governs the transfer.

Baseten presents a more acute version of this problem. Its DPA is accessible at a public URL [src:vendor/baseten], but no transfer mechanism, subprocessor list or data region is recorded in the source data [src:vendor/baseten]. A consultant cannot confirm from the published record whether UK or EU transfer requirements are met and must review the DPA document directly before advising any client — UK or EEA. See the notes on when a vendor has no public data processing agreement for how to frame that conversation.

Subprocessor lists and regime-specific coverage

Supabase publishes a subprocessor list [src:vendor/supabase]. Metabase Cloud publishes a subprocessor list [src:vendor/metabase-cloud]. Baseten does not record a subprocessor list URL [src:vendor/baseten].

A shared subprocessor list covering both EU and UK clients may still leave a gap if the vendor's DPA terms differ by regime [src:vendor/supabase] [src:vendor/metabase-cloud]. The list tells you which sub-processors exist. It does not tell you whether the contractual chain — controller to processor to sub-processor — is legally sound under UK GDPR as opposed to GDPR. That determination requires reading the DPA, not just confirming a URL exists. The article on subprocessor lists and what changes when a vendor updates its DPA covers what to look for when those documents change.

Legal entity and counterparty

Supabase's legal entity is Supabase Pte. Ltd, incorporated in Singapore [src:vendor/supabase]. Metabase Cloud's legal entity is Metabase, Inc., incorporated in the US [src:vendor/metabase-cloud]. Baseten's legal entity is Baseten Labs Inc, incorporated in the US [src:vendor/baseten]. None of these vendors is incorporated in the EEA or the UK. That means every client — whether UK or EEA — is engaging a third-country processor, and the transfer mechanism question applies regardless of which regime is in scope. The piece on the brand not being the counterparty is worth reading before you advise on which entity your client is actually contracting with.

Which to pick when

The framing of "which to pick" only applies to clients whose circumstances bring one regime into scope but not the other. For most clients you will encounter, the more useful question is: which additional obligations does the second regime add, and does the vendor documentation cover both?

Client registered only in the UK, no EEA customers

UK GDPR applies. GDPR does not [src:regime/uk_gdpr]. Your review of vendor DPAs should focus on whether the UK transfer mechanism is in place — UK Addendum or IDTA — and whether the subprocessor list is accessible. For Supabase and Metabase Cloud, you will need to confirm from the DPA text whether UK-specific transfer provisions exist, because neither records one in the source data [src:vendor/supabase] [src:vendor/metabase-cloud]. For Baseten, the absence of a recorded transfer mechanism or subprocessor list means the DPA text itself is the only starting point [src:vendor/baseten].

Client registered only in the EEA, no UK customers

GDPR applies. UK GDPR does not [src:regime/gdpr]. EU SCCs are sufficient as a transfer mechanism where the vendor relies on them. Supabase and Metabase Cloud both record SCCs [src:vendor/supabase] [src:vendor/metabase-cloud]. An EU data region is available from both vendors for clients who prefer to keep data in-region [src:vendor/supabase] [src:vendor/metabase-cloud]. Baseten records no transfer mechanism, so the same DPA review obligation applies [src:vendor/baseten].

Client in scope for both regimes

This is the case that generates the most work. The client needs vendor DPAs that are valid under both frameworks — which in practice means the vendor's DPA must reference either the UK Addendum or the IDTA in addition to the EU SCCs, or it must contain separate UK-specific terms. A single DPA referencing EU SCCs alone is not sufficient to cover a UK controller.

For Supabase and Metabase Cloud, you would need to review the DPA documents at their published URLs to establish whether UK provisions are present [src:vendor/supabase] [src:vendor/metabase-cloud]. Neither vendor records a separate UK data region, so a client who places data in the EU region should also verify whether that contractual coverage extends to UK law [src:vendor/supabase] [src:vendor/metabase-cloud].

For Baseten, the absence of any recorded transfer mechanism, subprocessor list or data region means you are starting with a blank slate on both fronts [src:vendor/baseten]. That is a gap to surface to your client before they sign the vendor agreement, not after. The workflow in answering vendor security questionnaires at scale describes how to handle that triage efficiently across a larger client base.

A note on regime configurations in practice

Maintaining separate regime configurations for UK and EU clients — rather than treating them as a single "GDPR" bucket — makes the divergences visible rather than assumed [src:regime/gdpr] [src:regime/uk_gdpr]. Where a vendor record shows SCCs but no UK Addendum, that entry flags a gap for UK clients while remaining clear for EEA ones [src:vendor/supabase] [src:vendor/metabase-cloud]. The same applies to data region availability: an EU region noted without a corresponding GB region is informative only if you are tracking regimes separately. If you are scaling a privacy practice across more than a handful of clients, that separation pays for itself quickly. See the notes on how to scale a privacy practice past 20 clients for the structural approach.