Schrems II in 2026: US Data Transfers That Survive a Supervisory Authority Audit

Schrems II compliance 2026 is no longer a checkbox exercise. Supervisory authorities across Germany, France, Austria, and the Netherlands have moved from issuing guidance to opening active enforcement proceedings against companies that cannot demonstrate how their US data transfers are actually secured. If your answer to a DPA inquiry is "we signed SCCs," you are likely to leave that conversation with a corrective order.

This post is about what a defensible US transfer programme actually looks like when a regulator asks to see it - the documentation, the technical controls, and the architecture choices that hold up under real scrutiny.

What Changed Between 2020 and Now

The Schrems II ruling from July 2020 invalidated Privacy Shield and made Standard Contractual Clauses conditional - valid only where a Transfer Impact Assessment confirmed that the third country's laws did not undermine the protections the clauses promised. At the time, most organisations did one of three things: signed updated SCCs, filed a TIA that concluded "SCCs are sufficient" without a genuine legal analysis, or quietly did nothing.

Regulators initially lacked bandwidth for systematic enforcement. That changed. The Irish DPA, long criticised for slow-walking Meta investigations, concluded major proceedings. German state DPAs have published enforcement notices against companies using Google Analytics, Cookiebot loaded from US servers, and US-hosted font CDNs. The CNIL in France and the DSB in Austria have been particularly active on cookie-adjacent transfers. The pattern is consistent: regulators are no longer waiting for complaints. They are auditing sectors proactively.

In 2026, the EU-US Data Privacy Framework provides an adequacy mechanism for transfers to certified US companies. But adequacy is not a blanket pass. It covers transfers to the specific certified entity, not every US-based subprocessor that entity uses downstream. And adequacy decisions can be challenged - the Schrems III litigation is already underway in EU courts. Organisations that built their compliance programme entirely on the adequacy decision are exposed if it falls.

The companies that are in the best position today built their programmes on SCCs with real TIAs, then used the adequacy decision as a supplementary layer - not the foundation.

What a Transfer Impact Assessment Actually Requires

A TIA is not a self-certification form. It is a documented legal analysis of three things: what data is transferred, under what legal basis, and whether the destination country's surveillance laws give authorities access that would undermine the contractual protections.

For US transfers, the relevant laws are FISA Section 702, Executive Order 12333, and the reforms introduced by Executive Order 14086 and the Data Privacy Framework. A credible TIA needs to engage with all of them - not just assert that EO 14086 fixed the problem.

The European Data Protection Board's recommendations on supplementary measures (adopted June 2021, updated since) set out the minimum structure. For each transfer, you need to document:

• The data categories being transferred and their sensitivity level
• The transfer mechanism (SCCs, adequacy, Binding Corporate Rules)
• An assessment of the destination country's legal framework - specifically whether authorities can access data in ways that go beyond what is necessary and proportionate under EU standards
• Whether the identified risks can be reduced to a level that makes the transfer lawful
• Which supplementary technical or organisational measures close the gap

The key question for US transfers under FISA 702 is whether the US vendor's services are subject to foreign intelligence collection orders. For hyperscalers - AWS, Azure, GCP - and major SaaS platforms, the honest answer is that they can receive such orders and are legally required to comply. A TIA that ignores this and concludes the transfer is clean without any supplementary measures is not going to survive regulatory scrutiny.

Supplementary Technical Measures That Actually Hold Up

The EDPB identifies three categories of technical supplementary measures that can reduce exposure to a level where a transfer becomes defensible, even where the destination country's laws are problematic.

Encryption where the data importer cannot access the keys. If you transfer data to a US-hosted service but hold the encryption keys in the EU yourself, a FISA 702 order served on the US provider delivers ciphertext. This only works if the key management architecture genuinely prevents the provider from accessing plaintext - cloud-managed encryption, where the provider holds or can access the keys, does not count. True end-to-end encryption with EU-side key management is difficult to implement for most SaaS use cases because it requires the provider to operate on encrypted data, but it is viable for backup storage and archival transfers.

Pseudonymisation before transfer. Replacing direct identifiers with tokens before data crosses the border reduces risk where the re-identification mapping stays in the EU. The transferred dataset still contains pseudonymous data, but without the mapping table, a surveillance authority receiving it cannot link records to specific individuals without additional access. This measure is most effective for analytics workloads - you transfer aggregated or pseudonymised event data to a US analytics platform while retaining the identity mapping in an EU-hosted data store.

Routing only through EU regions of US-controlled infrastructure. AWS eu-central-1, Azure West Europe, and GCP europe-west4 are physically located in the EU and subject to EU jurisdiction for data at rest. However, the parent company remains a US entity subject to FISA 702. The EDPB's position is that routing to EU data centres reduces risk but does not eliminate it, because a FISA order could in principle compel the US parent to provide access even to EU-region data. The practical risk is lower - and most regulators treat EU-region hosting as a meaningful risk reduction - but it should not be presented as making the transfer equivalent to an intra-EU transfer.

Contractual measures alone are not supplementary technical measures. This is a common mistake. Adding clauses to a DPA, negotiating audit rights, or requiring the provider to notify you of orders are organisational measures. They reduce the risk of a breach going undetected; they do not prevent a technically capable surveillance authority from accessing data. A well-documented TIA needs to be honest about this distinction.

The Architecture Choices That Reduce Your Exposure

Beyond per-vendor TIAs, the architecture of your product determines how much risk you are carrying and how reducible that risk is.

Map your actual data flows, not your intended ones. Article 30 records of processing activities frequently underrepresent the real number of cross-border transfers. Error monitoring tools like Sentry or Datadog receive exception payloads that often include user identifiers, session data, or raw request parameters. Session replay tools receive partial DOM snapshots that may contain form inputs. Email delivery platforms receive recipient addresses, subject lines, and in some configurations, body content. None of these typically appear in the ROPA next to "transfer to US under SCCs" but all of them transfer personal data.

A full data flow map starts with the product - every outbound network call from backend services, every third-party script loaded in the frontend, every webhook or API call from infrastructure tooling - and traces what data each call carries. This is an engineering exercise as much as a legal one. Code quality reviews frequently surface undocumented third-party integrations that have been added incrementally without a corresponding compliance review.

Prefer EU-hosted alternatives for high-risk categories. Not every US tool has an EU equivalent, but more do than most teams realise. Plausible Analytics (EU-hosted, privacy-first), Matomo (self-hostable), Hetzner and OVH for cloud infrastructure, Mailpace for transactional email, Sentry self-hosted on EU infrastructure - these options require evaluation on product fit, but for categories where the transferred data is sensitive (authentication events, payment metadata, health-adjacent data), the overhead of switching is lower than the compliance exposure of staying.

Build abstraction layers now, not when you need them. If your application code calls third-party SDKs directly, swapping a US-hosted vendor for an EU alternative requires a codebase change. If the integration is behind a thin interface or adapter, swapping the vendor is a configuration change. The cost of adding that abstraction is low when the integration is first built and significant when you are responding to a regulatory inquiry on a tight deadline. Custom software development engagements with a compliance-aware brief should include this pattern as a default, not an optional extra.

Separate your data residency question from your legal basis question. These are related but distinct. Data residency - keeping data physically in EU data centres - reduces the risk of surveillance access and satisfies contractual requirements from enterprise customers. Legal basis for the transfer - the SCCs, adequacy decision, or BCRs - determines whether the transfer is lawful regardless of where the data physically lands. You can have EU-resident data transferred under an inadequate legal basis, or US-resident data transferred under a solid legal basis with strong supplementary measures. The compliance programme needs to address both.

What Regulators Are Actually Looking For in 2026

Based on published enforcement decisions and regulatory guidance, the questions a supervisory authority inspection is likely to include:

• Can you produce a current Article 30 record that includes all US-directed transfers, not just the primary data processor?
• Do you have signed SCCs with each vendor, and are they the current ESCC clauses (June 2021 version)?
• Do you have a completed TIA for each transfer, and does it genuinely engage with FISA 702 exposure or does it simply assert that SCCs are sufficient?
• What supplementary technical or organisational measures did the TIA identify, and have you implemented them?
• How do you monitor for changes in destination-country law that would invalidate the TIA?
• What is your procedure for responding to a vendor's notification that they have received a government access request?

The last two questions catch many organisations off guard. A TIA is not a one-time document - it needs a review trigger tied to material changes in the legal environment. And most SaaS companies have no documented procedure for handling government access notifications, even though their DPAs with US vendors typically require the vendor to notify them.

Putting It Together

A defensible Schrems II programme in 2026 has these elements: a complete data flow inventory at the application level; SCCs with every US vendor, on the current clause templates; TIAs that honestly assess FISA exposure and document what supplementary measures close the gap; genuine technical measures where the risk is high enough to require them; and a review process with defined triggers.

None of this requires a team of lawyers or a six-figure compliance tool. A well-structured spreadsheet and the EDPB's published guidelines cover most of it. The limiting factor is usually the data flow inventory - and that requires someone with enough access to the codebase and infrastructure to trace where data actually goes, not just where the architecture diagram says it should go.

If you are not sure where your product is sending personal data across borders, or you need to assess whether your current legal basis documentation would survive scrutiny, that is the right place to start. We have helped SaaS teams work through exactly this kind of audit-readiness exercise as part of code quality consulting and web application development engagements.

Get in touch at hello@wolf-tech.io or visit wolf-tech.io to talk through where your programme currently stands.