The Schrems II ruling from the Court of Justice of the European Union (Case C-311/18, July 2020) is now nearly six years old, but most procurement teams still treat it as a compliance abstraction rather than a concrete buyer’s tool. That gap matters. National data protection authorities have moved from theoretical guidance into enforcement, with the French CNIL, Austrian DSB, Italian Garante, and Danish Datatilsynet all issuing decisions that hinge on Schrems II reasoning. If you are buying SaaS in 2026, you are expected to have a defensible position — not necessarily a perfect one, but one that shows you understood the question and made a reasoned choice.
This guide walks through the actual steps a buyer-side procurement or DPO function should take when evaluating a vendor under Schrems II. It is written from the buyer’s perspective, not the regulator’s. The goal is to land on a position you can defend in writing if an auditor or regulator asks.
What Schrems II actually requires of buyers
The ruling did two things at once. It invalidated the EU-US Privacy Shield as an adequacy mechanism, and it raised the bar on what counts as a sufficient “supplementary measure” when transferring personal data outside the EEA. The European Data Protection Board (EDPB) then published Recommendations 01/2020, which lay out a six-step methodology for what is now called a Transfer Impact Assessment, or TIA.
For a buyer, the practical translation of Schrems II is: before you sign with a SaaS vendor that processes personal data outside the EEA — or whose corporate parent could compel disclosure to a third-country government — you need to be able to answer four questions in writing.
First, what personal data are you transferring? Second, where is it going, and what is the legal regime there? Third, what contractual, technical, and organisational measures are in place to protect it? Fourth, given the answers to one through three, is the transfer lawful under GDPR Chapter V?
If the answer to four is “yes, with reservations,” you document the reservations and the compensating controls. If the answer is “no,” you either pick a different vendor or accept the regulatory risk explicitly, with a sign-off from someone who has the authority to accept it.
The four categories of vendor exposure
When you evaluate a SaaS vendor, sort them into one of four buckets early. This shapes how much effort the rest of the assessment needs.
Category one: EU-only. The processor is an EU/EEA legal entity, all production data is stored in EU/EEA regions, and there are no sub-processors located outside the EEA that touch personal data. There is no transfer in the GDPR Chapter V sense, so Schrems II does not apply directly. You still need a GDPR Art. 28 DPA and a normal vendor risk assessment, but the TIA workload is minimal.
Category two: EU-owned, mixed sub-processors. The primary processor is an EU/EEA entity, but the vendor uses third-country sub-processors for ancillary services — typically email delivery, error tracking, analytics, or CDN. Here you need to look at each sub-processor relationship and assess whether the personal data flowing to that sub-processor is meaningful (the contents of a user’s account, the body of a support ticket) or marginal (an IP address logged for fraud prevention). The legal mechanism for each onward transfer matters: 2021 Standard Contractual Clauses, EU-US Data Privacy Framework certification, or one of the GDPR Art. 49 derogations.
Category three: US-owned, EU-hosted. The primary processor is US-headquartered or controlled by a US parent, but advertises EU data residency. This is where the CLOUD Act conversation lives. The US Clarifying Lawful Overseas Use of Data Act (2018) compels US-controlled companies to produce data they control, regardless of where it is physically stored. EU data residency does not, by itself, defeat a CLOUD Act warrant. You need to look at the vendor’s encryption posture, what they have committed to publicly about challenging government requests, and what they publish in transparency reports.
Category four: third-country processor with EU customers. The processor is outside the EEA and is treating the EU customer as the data exporter. The full Schrems II framework applies. The vendor will typically rely on 2021 SCCs or, for US vendors, the EU-US Data Privacy Framework. You need to assess whether the framework is reliable for your use case and what supplementary measures the vendor offers.
The six-step TIA, translated for procurement
The EDPB’s six-step methodology is dense. Here is the buyer-side version.
Step one — know your transfer. Document who is exporting, who is importing, what categories of personal data are involved, and what the processing purpose is. For a typical SaaS purchase, the exporter is your company, the importer is the vendor, the data depends on the product (customer contact data for a CRM, employee data for HR software, end-user behaviour data for analytics), and the purpose is whatever your customer is paying the vendor to do.
Step two — identify the transfer tool. This is where the SCCs, adequacy decisions, and BCRs live. For a US vendor in 2026, the relevant tool is either the 2021 SCCs or the EU-US Data Privacy Framework. For a vendor in an adequacy country (UK, Switzerland, Israel, Japan, South Korea, Andorra, Argentina, Faroe Islands, Guernsey, Isle of Man, Jersey, New Zealand, Uruguay, and the post-Brexit UK Adequacy Decision), no additional tool is needed.
Step three — assess the third country’s law. Look at whether the third country’s surveillance and law enforcement regime would render the transfer tool ineffective. The EDPB and the European Commission have published guidance and country reports. For the US, the analysis hinges on Section 702 of FISA and Executive Order 12333. For the UK, the 2021 adequacy decision held, with a review scheduled.
Step four — identify and document supplementary measures. These can be technical (end-to-end encryption with keys held outside the third country, pseudonymisation, split processing), contractual (additional confidentiality clauses, audit rights, notification obligations on government access requests), or organisational (the vendor’s published policy on challenging warrants, transparency reporting, separation of duties).
Step five — adopt the supplementary measures. This means actually configuring them in the contract and the product. A vendor that supports customer-managed encryption keys is meaningfully better than one that only encrypts at rest with their own keys. A vendor that publishes a quarterly transparency report on government data requests is meaningfully better than one that does not.
Step six — re-evaluate periodically. Vendor ownership changes. Sub-processor lists change. Third-country law changes. The TIA is not a one-shot document.
What to actually ask the vendor
Most vendor-side compliance pages are written for the easy questions. The hard ones often need to be asked directly, in writing, with a paper trail. Here are the questions worth asking before signing a contract.
Where, specifically, is production data stored? Not “the EU” — which region, which data centre, which cloud provider. If the vendor is on AWS Frankfurt, are they using AWS European Sovereign Cloud or the standard commercial AWS regions? If they are on a hyperscaler, can they articulate the contractual mechanism that prevents the hyperscaler from accessing customer data?
Who are the current sub-processors that touch personal data? Ask for the live list, not the screenshot in the sales deck. The live list should be publicly accessible — most credible vendors publish it.
Does the corporate group include any US entities? If so, what is the legal relationship between the EU processor and the US entities? A US sister company that does not control the EU processor’s data is meaningfully different from a US parent that consolidates the EU subsidiary’s financials and has board control.
What is the vendor’s published policy on government access requests? Have they ever received one? Have they ever challenged one? Is there a transparency report?
What encryption is in place — at rest, in transit, in use? Are customer-managed keys (CMK) or bring-your-own-key (BYOK) available?
What is the contractual mechanism for notifying you of a government access request? Most modern DPAs include a notification clause unless prohibited by law, but the “unless prohibited” carve-out swallows a lot of real-world requests.
What is the vendor’s stance on the EU-US Data Privacy Framework? Are they self-certified? Do they consider it a primary or supplementary transfer mechanism?
Where buyers most often get this wrong
Three patterns appear repeatedly in real-world Schrems II disputes.
The first is treating EU data residency as a sufficient answer. It is necessary but not sufficient. A US-controlled vendor with EU regions still faces CLOUD Act exposure. Regulators have repeatedly clarified this.
The second is over-relying on the 2021 SCCs. The SCCs are a transfer tool, not a magic wand. The EDPB has been clear that the SCCs require supplementary measures when the third country’s law would otherwise undermine them.
The third is documenting the assessment but never updating it. Vendor sub-processor lists change quarterly. Corporate ownership changes annually. A TIA from 2023 is a starting point, not a defence.
A defensible documentation pattern
When you finish a TIA, the deliverable should be a short structured document — typically two to five pages — that an external auditor could pick up and follow. The structure that holds up best in practice is: vendor identity and corporate structure, categories of personal data transferred, purpose of processing, transfer tool relied on, third-country law summary, supplementary measures identified, residual risk, decision, sign-off, review date.
If you can produce that document in under an hour for any given vendor, you have a procurement process. If you cannot, you have an exposure surface that an enforcement action will eventually find.
Where EU-hosted alternatives change the calculation
Switching from a US-headquartered vendor to an EU-headquartered, EU-hosted vendor does not eliminate compliance work — you still need the DPA, the sub-processor list, the technical and organisational measures documentation. What it does is collapse the Schrems II analysis. If your processor is an EU legal entity and uses only EU sub-processors, GDPR Chapter V is not engaged. That is a meaningfully shorter document to produce and defend.
For categories where EU-native alternatives have feature parity — analytics, email, hosting infrastructure, basic file storage, password management, encrypted communications — the procurement argument for switching tends to be stronger than the technical one. The Schrems II exposure simply disappears from your assessment workload.
For categories where EU-native alternatives are still maturing — CRM at enterprise scale, sophisticated marketing automation, certain developer tools — the buyer has to make a more nuanced call. The EU Stacks directory exists to make that comparison easier on the data points that matter for compliance: ownership structure, certification footprint, server regions, published trust evidence.
The right Schrems II posture in 2026 is not maximalism. It is doing the analysis honestly, documenting the trade-offs, and reducing exposure where the cost of switching is low. Procurement teams that operate this way tend not to end up in the enforcement headlines.