Skip to content
OS Domains
Regulation

Schrems II compliant cross-border transfers, TIAs maintained.

OS Domains keeps cross-border email processing Schrems II compliant by defaulting to EU-only routing: message content, recipient data, and logs stay inside the EEA on points of presence the customer selects, operated by an Austrian company with no US parent in the corporate chain. The only cross-border flows are opt-in US or Panama PoPs and a small set of US sub-processors, each covered by one of four active Transfer Impact Assessments with documented supplementary measures (TLS 1.3, AES-256, pseudonymization) and the relevant Standard Contractual Clauses module. The EU-US Data Privacy Framework is treated as a secondary mechanism behind SCCs plus a current TIA, so a future invalidation changes paperwork rather than deliverability.

The Court of Justice of the EU ruled in Case C-311/18 on 16 July 2020 that EU-US Privacy Shield was invalid for cross-border data transfers, and that Standard Contractual Clauses can only be relied on after a Transfer Impact Assessment evaluating the destination country's surveillance laws. The EU-US Data Privacy Framework (2023) restored an adequacy mechanism for certified US recipients but does not eliminate TIA requirements in non-DPF transfers. We maintain four active TIAs for cross-border flows, with documented supplementary measures and SCC modules in our DPA.

By default, customer data stays within the EEA. Cross-border flows happen only with explicit opt-in (DFW and PTY PoPs) or through our US sub-processors, each covered by current TIAs available under NDA.

In short

  • EU-only mode keeps message content, recipient data, and logs inside the EEA; the operating entity is Austrian with no US parent, which is what the CLOUD Act test of possession, custody, or control actually follows.
  • Four active Transfer Impact Assessments cover every cross-border flow — the Cloudflare US entity, the Stripe US parent, and the optional Dallas and Panama PoPs — refreshed annually and on any material legal change.
  • SCC Module 2 (controller-to-processor) and Module 3 (processor-to-processor) under Decision (EU) 2021/914 are incorporated in the DPA; the repealed 2010 clauses are not used.
  • Supplementary measures answer FISA Section 702, Executive Order 12333, and the CLOUD Act directly: TLS 1.3 in transit, AES-256 at rest, and pseudonymization where the processing permits.
  • The Data Privacy Framework is held as a redundant secondary mechanism behind SCCs and a current TIA, because the two prior EU-US bridges (Safe Harbor, Privacy Shield) were each struck down after roughly five years.
Key numbers
CJEU ruling date
2020-07-16
TIAs maintained
4 active
Our SCC modules
Module 2 + 3
EU-only available
Default in EU mode

What does Schrems II require, and why did it change cross-border transfers?

On 16 July 2020 the Court of Justice of the EU ruled in Case C-311/18 (Data Protection Commissioner v Facebook Ireland and Maximillian Schrems) that the EU-US Privacy Shield was invalid for cross-border data transfers, and that Standard Contractual Clauses (SCCs) — the remaining primary mechanism — could only be relied on after the data exporter conducts a Transfer Impact Assessment (TIA) evaluating whether the laws of the destination country provide essentially equivalent protection. Where they do not, the exporter must implement supplementary measures (encryption, pseudonymization, contractual safeguards) to bridge the gap. For the US specifically, the CJEU found that surveillance laws including FISA Section 702 and Executive Order 12333 give US intelligence agencies access that does not provide equivalent protection. The EU-US Data Privacy Framework (effective July 2023) restored an adequacy mechanism for certified US recipients, but does not eliminate the need for TIAs in non-DPF transfers.

How we handle cross-border transfers.

By default, customer data and processing stay within the European Economic Area in PoPs the customer has selected. Cross-border transfers occur only in three scenarios: (1) customer explicitly opts into our Dallas (USA) or Panama City (Panama) PoPs; (2) sub-processors located outside the EEA process some data (Cloudflare US entity, Stripe US parent, etc.); (3) customer-uploaded data is by nature destined for a non-EEA recipient (sending a marketing email to a US recipient, for example — though the message itself is transferred via SMTP outside the EEA only because the customer chose that recipient, which is not a Chapter V transfer of the customer's data). For each cross-border flow, we maintain a current TIA documenting the destination-country legal analysis, the supplementary measures, and the SCC module used (Module 2 controller-to-processor, Module 3 processor-to-processor).

Our Transfer Impact Assessment for US sub-processors.

For our US-touching sub-processors (Cloudflare for edge and DDoS, Stripe for payments, PagerDuty for internal alerting), our TIA evaluates: applicability of FISA Section 702 (does the processor meet the "electronic communications service provider" definition; is the data type of foreign intelligence interest), applicability of Executive Order 12333 (does the processor route through facilities subject to upstream collection), CLOUD Act exposure (US-headquartered entity subject to US extraterritorial production orders). For each, we identify supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256) so that bulk collection yields ciphertext; pseudonymization where applicable; contractual NDA chains and transparency report commitments. The TIA conclusion supports continued use of these sub-processors with the documented supplementary measures. Customers can review our TIAs under NDA via [email protected].

Where does the Data Privacy Framework actually stand in 2026?

The framework that restored an adequacy route for certified US recipients survived its first court test and remains under a cloud. On 3 September 2025 the EU General Court upheld the Data Privacy Framework in the challenge brought by the French politician Philippe Latombe, and on 31 October 2025 Latombe appealed that ruling to the Court of Justice of the EU, where as of mid-2026 no hearing date has been set. A separate and broader challenge from noyb, the group behind Schrems I and Schrems II, has been signaled rather than filed, and Max Schrems has argued publicly that the changes the current US administration made to the independent oversight bodies underpinning the framework — including the removal of members tasked with the redress mechanism — may lead the European Commission to pause the deal on its own before any case reaches the Court. The framework rests on Executive Order 14086, which limits signals intelligence to twelve enumerated objectives, introduces a proportionality test, and stands up a Data Protection Review Court with the Privacy and Civil Liberties Oversight Board reviewing it; the fragility is that an oversight mechanism created and staffed by executive action can be unstaffed the same way. Our posture treats the framework as a redundant secondary mechanism and never the primary one, because Standard Contractual Clauses paired with a current Transfer Impact Assessment are the layer that survives a framework invalidation, and the sender who built on that layer does not scramble the week the next ruling lands.

Do the sovereign-cloud rebrandings remove the question?

Every US hyperscaler now offers something it calls sovereign. AWS brought its European Sovereign Cloud to general availability in Brandenburg on 15 January 2026, with separate German legal entities, EU-resident-only operations, an independent root certificate authority, and a contractual commitment that non-EU personnel have no technical access. Google runs a trustee model with T-Systems holding keys in Germany and a separate S3NS entity in France, and Microsoft operates its EU Data Boundary. Each is a genuine engineering effort, and each shares the same unresolved core: the operating entities remain owned by a US parent, so the CLOUD Act test of possession, custody, or control still points at the parent regardless of where the data sits or who runs the console. A contractual promise from a US-owned subsidiary is a strong answer for many buyers and an incomplete one for a procurement that requires a provider not subject to third-country law with extraterritorial reach. Our answer is structural rather than contractual. The company is incorporated in Austria with no US parent in the corporate chain, the EU-only mode disables the Dallas and Panama points of presence, and the sub-processor configuration excludes US-only operations where an EU alternative exists. That configuration does not reduce the third-country exposure on the email leg; it removes the third country from the chain, which is a different and stronger claim to make in front of a supervisory authority.

What belongs in your DPIA when email is the processor?

A data protection impact assessment for an email vendor comes down to a short, answerable set of questions, and the cleanest outcome is the one where most of them resolve to no transfer at all. First, locate where the data rests and who operates the infrastructure: with EU-only mode the message content, recipient data, and logs stay in the European Economic Area on points of presence you selected. Second, identify who owns the operator, because ownership rather than geography is what the CLOUD Act follows, and an EU-incorporated processor with no US parent closes that line of questioning. Third, name the legal basis for any flow that does leave the EEA: an adequacy decision where one applies, or Standard Contractual Clauses backed by a current Transfer Impact Assessment where it does not. Fourth, list the supplementary measures — TLS 1.3 in transit, AES-256 at rest, pseudonymization of recipient identifiers where the processing allows it — that bridge the gap the assessment identifies. Fifth, record the sub-processor chain and the residency option chosen. When a customer runs EU-only mode with EU sub-processors, the email leg involves no Chapter V transfer to assess, which is the shortest and least contestable section a DPIA can contain. We provide a TIA support pack and the relevant DPA annexes under NDA so the assessment is filled with documented facts rather than vendor assurances.

When is EU-only routing not enough?

EU-only routing satisfies most data-residency requirements, and some national rules go further and prohibit data leaving a specific member state. Germany applies stricter expectations to federal and public-sector data through the BSI framework, France layers ANSSI requirements and the SecNumCloud qualification on sensitive workloads, and individual sector regulators add their own constraints. For those cases, Enterprise accounts can pin all data and processing to a single EU country drawn from Austria, Germany, France, the Netherlands, Ireland, Belgium, Italy, or Spain, with the sub-processor set narrowed accordingly. The honest trade-off is resilience. A single-country pin limits failover to the points of presence inside that country, so the recovery plan is written against that constraint rather than implying a cross-border redundancy the rule forbids. We document that limit in the contract rather than after an incident, because an authority that learns of a resilience ceiling during a recovery is an authority that feels misled. The sovereignty requirement comes first and the architecture follows it, which is the order a public-sector or regulated buyer expects to see and the order their own auditors will check.

Which surveillance laws does the assessment have to answer for?

The Transfer Impact Assessment is only as current as the laws it analyzes, and those laws keep moving. Section 702 of the Foreign Intelligence Surveillance Act, the provision the Court found disproportionate in Schrems II, was reauthorized in 2024, which is exactly the kind of post-2023 factual development a future challenge to the adequacy framework is expected to cite. Executive Order 12333 governs intelligence collection outside the 702 framework, including upstream collection at the network level, and the CLOUD Act lets US authorities compel production from US-headquartered providers regardless of where the data is stored. Together these are why the US leg of any assessment reads adverse for bulk, non-pseudonymized personal data routed through a US-owned provider. Our supplementary measures answer to exactly these statutes: encryption strong enough that upstream collection yields ciphertext, pseudonymization that breaks the link between an identifier and a person where the processing permits it, and a default that keeps the data inside the EEA so the question does not arise. We refresh the assessment annually and on any material legal change, because an assessment that names a repealed statute or misses a reauthorization is worse than none.

How the four Transfer Impact Assessments are structured and kept current.

The four active assessments cover the only cross-border flows in the service: the Cloudflare US entity used for edge and DDoS protection, the Stripe US parent used for payments, and the optional Dallas and Panama points of presence a customer can opt into. Each one follows the same shape. It names the entity and its jurisdiction, works through the applicability of FISA Section 702, Executive Order 12333, and the CLOUD Act to that specific processor, identifies the supplementary measures that bridge the gap the analysis finds, states a conclusion on whether the transfer can proceed with those measures, and records a refresh date. The cadence is annual and immediate on any material legal change, so a reauthorization of a surveillance statute or a shift in a processor's certification triggers a review rather than waiting for the calendar. A customer running their own assessment as part of vendor due diligence can incorporate ours by reference, and we provide the underlying entity details, governance structure, and transparency-report links in a support pack under NDA, typically within one to two weeks. The point of keeping the assessments live rather than filed is that an assessment naming a repealed clause or a lapsed certification gives a false sense of cover, and a supervisory authority reading it will notice.

Three frameworks, three invalidations is the base rate to plan around.

The Data Privacy Framework is the third attempt at an EU-US adequacy bridge. Safe Harbor stood from 2000 until the Court struck it down in 2015, Privacy Shield ran from 2016 until 2020, and the current framework has been in force since 2023. Two of the three lasted roughly five years before a Schrems-led challenge ended them on the same underlying objection: US surveillance law reaching EU personal data without proportionate limits or genuinely independent redress. Planning as though the third will be the exception is a bet against a clear pattern. We plan for the base rate instead, which is the reason the durable mechanism under every account is Standard Contractual Clauses plus a current assessment, with the framework treated as a convenience that may not outlast the contract it sits inside.

How we solve it

The specific capabilities that matter for this use case.

01

EU-only PoP mode

Performance and Enterprise customers can configure their account to use only the 5 EU PoPs (Vienna, Frankfurt, Amsterdam, London, Strasbourg). DFW and PTY PoPs disabled. Sub-processor configuration also restricted to EU/EEA-only where the alternative exists.

02

Transfer Impact Assessments maintained

Four active TIAs: Cloudflare US entity, Stripe US parent, our DFW PoP, our PTY PoP. Each documents the destination-country legal analysis, supplementary measures, and refreshed annually or on material legal change.

03

SCC Module 2 and Module 3 in DPA

Our standard DPA at /dpa incorporates EU Commission Decision (EU) 2021/914 Standard Contractual Clauses, Module 2 (Controller to Processor) for direct customer transfers and Module 3 (Processor to Processor) for sub-processor flows.

04

EU-US Data Privacy Framework reliance

Where our US sub-processors are certified under the EU-US Data Privacy Framework (Cloudflare, Stripe), DPF certification provides the transfer mechanism alongside SCCs as a backup in case of DPF invalidation.

05

Supplementary measures documented

TLS 1.3 in transit, AES-256 at rest, pseudonymization where applicable. Documented in the TIAs and visible in our DPA at /dpa#annex-2.

06

National-country residency for Enterprise

Beyond EU-only, Enterprise customers can pin to a specific EU country (Austria, Germany, France, Netherlands, Ireland, Belgium, Italy, Spain) to address national-supervisor data sovereignty requirements that exceed EU-only.

Common challenges

What we see go wrong, and how we fix it.

EU-US Data Privacy Framework stability

The DPF is the third attempt at an EU-US adequacy mechanism after Safe Harbor (invalidated 2015) and Privacy Shield (invalidated 2020). Privacy advocates have signaled litigation against the DPF; the same Max Schrems is involved through noyb. We do not assume the DPF will survive future CJEU review and maintain SCCs as the primary mechanism with DPF as a redundant secondary mechanism for the US sub-processors that have certified.

Cumulative transfer chains

A customer in Austria sending email through our Frankfurt PoP to a recipient in Brazil involves multiple potential transfers: storage in Frankfurt is intra-EEA; SMTP delivery to the recipient is the customer's own Chapter V transfer (controlled by your DPA with your recipients); logs forwarded to our Vienna SIEM are intra-EEA; bounce processing involves our edge CDN which has US-edge fallback. The TIA addresses each chain segment.

Customer-specific TIA requirements

Some enterprise customers run their own TIA as part of vendor due diligence and require us to provide specific data points (legal address of each sub-processor entity, governance structure, transparency reports). We provide a TIA support pack on request — typically 1-2 weeks turnaround under NDA.

The framework could pause before a court ever rules

The conventional risk model waits for a CJEU invalidation, but the more immediate scenario in 2026 is the European Commission suspending the framework on its own if the US oversight bodies that underpin it lose their independence. A provider whose compliance depends on the framework staying valid is exposed to a decision that may not come from a court at all. We treat the framework as secondary precisely so that a pause or a ruling changes our customers' paperwork rather than their deliverability.

A US-owned sovereign cloud still answers to its parent

Moving to a hyperscaler's European sovereign offering feels like a resolution and leaves the ownership question open, because the operating entity remains a subsidiary of a US corporation subject to the CLOUD Act. For a buyer whose procurement language excludes third-country legal reach, the contractual commitments of a US-owned entity do not clear the bar that an EU-incorporated provider clears by structure. We are direct about that distinction rather than letting a customer discover it during a supervisory review.

FAQ

Questions we get the most.

01

Do I need a TIA if I am using OS Domains?

You need a TIA for any cross-border transfer where the destination country does not have an adequacy decision. If you use only our EU PoPs and use the EU-only sub-processor mode, your direct transfer to us is intra-EEA and does not require a TIA. The cross-border flows for our US sub-processors fall under our own TIAs (which we share under NDA), and your reliance on our supplementary measures is documented in our DPA. If you opt into our DFW or PTY PoPs, that opt-in is a Chapter V transfer and you need your own TIA for that flow; we provide a template.

02

Are you using the new EU Commission SCCs (Decision 2021/914)?

Yes. Our DPA incorporates the 2021 SCCs — Module 2 for customer-to-OSD transfers, Module 3 for OSD-to-sub-processor transfers. The earlier 2010 SCCs were repealed in December 2022 and are no longer valid; any DPA still using the 2010 SCCs is non-compliant.

03

How do you handle the EU-US Data Privacy Framework?

Where our US sub-processors are DPF-certified (Cloudflare and Stripe currently are), DPF certification provides an adequacy-equivalent transfer mechanism. We rely on DPF as the primary mechanism with SCCs as a backup in case the DPF is invalidated. We monitor DPF certification status for our sub-processors monthly via the DPF list at the US Department of Commerce.

04

What supplementary measures does your TIA identify?

TLS 1.3 mandatory for all transfers in transit. AES-256 at rest in all locations. Pseudonymization of recipient PII in non-EEA processing where possible (some bounce processing requires raw recipient address). Contractual NDA chains binding US sub-processors to GDPR-equivalent obligations. Transparency report commitments — Cloudflare publishes biannual transparency reports on government data requests, which we monitor.

05

Can you provide a Letter of Reliance for our supervisory authority?

On Enterprise contracts and after legal review, we can provide a specific letter addressing the supplementary measures we have implemented and our TIA conclusions, suitable for submission to a supervisory authority during a vendor review. We do not provide blanket Letters of Reliance that commit to specific behaviors beyond contract terms — that would be misleading.

06

Is the EU-US Data Privacy Framework still valid in 2026?

Yes, for now. The EU General Court upheld it in September 2025, and that ruling is under appeal to the Court of Justice with no hearing date set as of mid-2026, while a broader challenge from noyb has been signaled. The framework also depends on US oversight bodies whose independence has been questioned, which raises the possibility of the European Commission pausing it before any court rules. We rely on it only as a secondary mechanism behind Standard Contractual Clauses and current Transfer Impact Assessments, so a change in its status does not interrupt your compliance.

07

Does the AWS European Sovereign Cloud solve our Schrems II exposure?

It reduces the exposure without closing the ownership question. The partition went live in January 2026 with EU-resident operations and contractual commitments against non-EU access, but its operating entities are owned by a US parent, so the CLOUD Act test still points at that parent. For a configuration that removes the third country from the chain rather than constraining it by contract, the relevant factor is an EU-incorporated provider with no US parent, which is how our EU-only mode is built.

08

What changes if we pin to a single EU country instead of EU-only?

Single-country residency keeps all data and processing inside one named member state, which is how we serve German federal-data rules and French ANSSI restrictions that go beyond EU-only. The trade-off is resilience: failover is limited to points of presence inside that country, so we document the recovery plan against that constraint. It is available on Enterprise accounts for Austria, Germany, France, the Netherlands, Ireland, Belgium, Italy, or Spain.

Ready to talk

Schedule a 45-minute architecture call with an engineer.

No salesperson, no commission, no qualification rounds. Tell us what you are trying to do, we tell you whether we are a fit, and you walk away with a recommendation either way.

Phone +43 1 205 11 80 Mon–Fri · 9–18 CET
Email [email protected] Avg response 4h business
Office Fleischmarkt 1, 1010 Wien By appointment