all posts

compliance

EU-resident observability and the Data Privacy Framework — survival strategy

Post-Schrems II, the legal architecture for EU customer data is not "trust the DPF." It's belt-and-braces — EU residency by default, 2021 SCCs as the legal mechanism, UK IDTA and Swiss FDPIC overlay, and zero reliance on a single transfer mechanism.

By Akshay Sarode· November 14, 2025· 12 min readgdprdpfschremsscc

EU-resident observability and the DPF — survival strategy

The single biggest mistake I see B2B SaaS vendors make in 2026 is over-reliance on the EU-US Data Privacy Framework. The pitch from US-headquartered vendors goes: "We're DPF-certified, so EU customer data can transfer to our US infrastructure under GDPR." Technically correct, today. Legally robust, in five years? Roll your dice. Schrems II nuked Privacy Shield in 2020. The DPF is the third attempt at the same problem with different paint, and there is an active Schrems III case at the CJEU. The smart architecture is the one that survives whatever happens to the DPF — and that means not transferring EU data to the US in the first place.

This post is what we tell customers when they ask: "What's your data residency story, and what happens if Schrems III lands?"

The short version of the legal landscape

The relevant pieces:

GDPR Article 44 prohibits transfers of personal data to third countries unless one of several conditions is met. Article 45 allows transfers under an adequacy decision. Article 46 allows transfers "subject to appropriate safeguards" — most commonly, 2021 EU Standard Contractual Clauses.

Schrems II (CJEU C-311/18, July 2020) invalidated the Privacy Shield adequacy decision and made clear that Article 46 SCCs are valid in principle but require supplementary measures when the destination country's surveillance laws fail to meet EU "essential equivalence" — which for the US, the court found they did not.

The Data Privacy Framework (July 2023) is the new adequacy decision for US-based organisations that self-certify under the DPF principles. It addresses some of the concerns Schrems II raised — notably US Executive Order 14086 establishing a Data Protection Review Court and curtailing some bulk-collection programs. NOYB (Schrems's organisation) has filed a Schrems-III-style challenge; a CJEU ruling is expected in 2026 or 2027.

UK GDPR post-Brexit is structurally similar to EU GDPR but treated as a separate transfer destination. Transfers from UK to third countries use the ICO IDTA (International Data Transfer Agreement) or the UK Addendum to the 2021 EU SCCs.

Swiss FADP (Federal Act on Data Protection, revised 2023) is similar in shape to GDPR. The Swiss Federal Data Protection and Information Commissioner (FDPIC) has its own determinations on third-country adequacy that don't always match the EU Commission's.

The architectural decision that matters

You can either:

A. Build US-resident, certify under DPF, and hope. Cheap engineering. Vulnerable to Schrems III. Many US vendors do this; many of their EU enterprise customers are quietly looking for replacements as a hedge.

B. Build EU-resident with belt-and-braces fallbacks. More expensive infrastructure (limited region selection, no us-east-1 cost arbitrage). Robust to any single mechanism failing.

Sutrace is option B. The data plane is europe-west3 (Frankfurt). Auth provider is Firebase Identity Platform configured for EU residency. Backups are within the EU. There is no US logging tier. Even our marketing analytics (PostHog) is the EU instance.

This isn't because we hate the DPF. It's because if a customer's compliance team has to tick "data leaves the EU" in their DPIA template, they're going to have a much harder conversation internally — particularly if the customer is in NIS2 scope or DORA scope, where data location is increasingly a hard requirement, not a preference.

Why europe-west3 specifically

We chose Frankfurt over Belgium (europe-west1), Netherlands (europe-west4), London (europe-west2), and Ireland (eu-west-1 in AWS terms) for four reasons:

  1. It's a proper EU region post-Brexit. London is out for EU-only customers. Frankfurt isn't.
  2. German data protection authorities are the strictest in the EU. BfDI and the Länder authorities set tone for what "appropriate measures" looks like. If the architecture passes German inspection, it passes everywhere else in the EU.
  3. Latency to most of Continental Europe is excellent. Sub-30 ms from any major German, French, Dutch, Belgian, Czech, Polish, Italian, or Austrian city.
  4. Frankfurt has multiple internet exchange points (DE-CIX is the largest in Europe), meaning the network paths are dense and recovery from a major peering incident is fast.

We replicate to a second EU region (europe-west1, Belgium) for disaster recovery. Both are EU. Both are subject to the same legal regime. Failover never crosses the border.

The 2021 SCCs as belt-and-braces

Even though our default architecture doesn't require third-country transfer, we sign the 2021 SCCs anyway, because:

  • Customers want them on file regardless. It's standard kit in any GDPR DPA.
  • If a customer specifically requests a US-resident sub-processor (we don't have one in the default config, but theoretical scenarios get raised in due diligence), we have the framework ready.
  • It costs us nothing to sign and it removes a procurement objection.

We sign Module 2 (controller-to-processor) for our normal customer relationships and Module 3 (processor-to-sub-processor) for the rare cases where a customer wants us to onward-transfer to a vendor of theirs. Module 1 (controller-to-controller) and Module 4 (processor-to-controller) don't apply to our setup.

The signed SCC document references our DPA for the technical and organisational measures (Annex II) and our trust page for the architectural detail.

UK Addendum and Swiss Overlay

For UK customers, we sign the ICO IDTA or the UK Addendum to the 2021 SCCs. Either works under UK GDPR. Most enterprise customers prefer the Addendum because it's a one-page bolt-on rather than a separate agreement.

For Swiss customers, we sign a Swiss FDPIC overlay to the 2021 SCCs. The overlay (a) replaces "EU Member State" with "Switzerland" where relevant, (b) substitutes the FDPIC for the EU supervisory authority where the SCCs reference one, and (c) acknowledges Swiss FADP definitions where they differ from GDPR. Three pages, signed alongside the SCCs.

The reason this matters: after Brexit and after the FDPIC's adequacy redetermination process, the UK and Switzerland are technically third countries from an EU GDPR perspective and vice versa. Belt-and-braces means having the right paperwork for all four directions — EU↔UK, EU↔CH, UK↔CH, and the trivial intra-EU case.

What we don't rely on

The DPF for outbound transfers. Our service does not transfer customer data out of the EU. The DPF doesn't matter for us in our standard configuration.

An adequacy decision for any country. Adequacy decisions can be revoked. Schrems II revoked Privacy Shield. A future Schrems III could revoke the DPF. Building on adequacy alone is fragile.

A "data residency commitment" that's a marketing line, not a technical control. We back the residency claim with infrastructure-as-code that allowlists only EU regions. New regions don't get added without an architectural review and a customer advisory.

What about encryption keys?

A common follow-up: where are the encryption keys?

Customer data at rest is encrypted with Google Cloud's customer-managed encryption keys (CMEK), with the keys stored in Google Cloud KMS in the same europe-west3 region. We do not export the keys. Google Cloud's encryption documentation describes the chain. The combination — EU-resident keys, EU-resident data — is the architecture EDPB's recommendations on supplementary measures explicitly contemplates as compliant.

Customers who want customer-controlled keys (CCK) — i.e., the key never leaves the customer's own KMS — can request that on the enterprise tier. We support External Key Manager (EKM) integration with on-prem HSMs. The vast majority don't need it; the option exists for the few that do.

Encryption export controls

A regulatory adjacency people occasionally ask about: US encryption export controls under BIS EAR. For Sutrace, this doesn't bind us materially because we don't ship encryption products to controlled destinations. The encryption is a feature of a SaaS hosted in the EU. The relevant regime is GDPR Article 32 (security of processing), not US EAR.

If you're a vendor with US ties whose customers are asking about encryption export, you may have a different conversation. We don't.

What happens if Schrems III lands

Three scenarios, in decreasing order of likelihood:

Scenario A: DPF is invalidated, SCCs survive (most likely). This is the Schrems II rerun. Vendors using SCCs with supplementary measures (encryption-at-rest, encryption-in-transit, contractual transparency reports) carry on. Vendors who only had DPF certification scramble. For Sutrace customers, nothing changes — we don't transfer to the US in the first place.

Scenario B: DPF and SCCs both invalidated for US transfers (less likely but possible). This would require the CJEU to find that no supplementary measure is sufficient. Vendors with US infrastructure suddenly cannot lawfully serve EU customers. For Sutrace customers, again nothing changes — EU residency is intact.

Scenario C: DPF survives, SCCs strengthened (also possible). The CJEU finds the EO 14086 reforms adequate. The DPF carries on. Some vendors stop using SCCs and rely on DPF; others keep both. For Sutrace, no change — we still don't transfer.

In all three scenarios, customers using Sutrace's EU-resident default see no service interruption, no architectural rework, no DPIA rewrite. That is the value of belt-and-braces.

What we ask customers to do

For the customer-side of GDPR compliance with our service:

  1. Read and counter-sign our DPA. It's GDPR-compliant standard kit.
  2. Review our trust page for the technical and organisational measures (Annex II of the SCCs).
  3. Don't enable any third-country sub-processor unless you specifically need one — the defaults keep you EU-only.
  4. Configure your retention policies to match your DPIA. Defaults are sensible (90 days for application logs, customer-configurable for telemetry).

That's the whole survival strategy. It's not flashy. It's belt-and-braces, EU-default, multi-mechanism, and — most importantly — it doesn't depend on the political weather between Brussels and Washington.

External references