A Transfer Impact Assessment (TIA) is a documented legal and technical analysis that an organisation must complete before relying on any transfer mechanism under GDPR Article 46 to send personal data to a third country, such as the United States. It evaluates whether the laws and practices of the destination country undermine the protection offered by the chosen safeguard, typically Standard Contractual Clauses. When an organisation migrates from a US-controlled cloud provider to a sovereign host in Switzerland or the EU, the TIA serves a dual purpose: it records the legal exposure that justified the migration, and it provides the audit trail that supervisory authorities expect to see under the GDPR Article 5(2) accountability principle.
Why Schrems II and the EDPS Decision Made TIAs Non-Optional
The 2020 CJEU ruling in Schrems II (Case C-311/18) removed the assumption that Standard Contractual Clauses are self-sufficient. The Court held that controllers must assess, case by case, whether the law of the recipient country provides essential equivalence to EU data protection standards.
The Court of Justice of the European Union stated in paragraph 94 of that judgment: “Where personal data is transferred to a third country, the level of protection of natural persons guaranteed in the Union by this Regulation must not be undermined.” That sentence transformed SCCs from a procedural checkbox into a starting point that requires substantive evidence. For any organisation still relying on Microsoft 365, Google Workspace, or comparable US-headquartered services, the practical consequence is that their current SCCs must be backed by a TIA that honestly documents whether the US legal framework, specifically the CLOUD Act, FISA Section 702, and the Patriot Act, renders those clauses ineffective in practice.
The EDPS enforcement decision of 2024 removed any remaining ambiguity. The European Data Protection Supervisor found that the European Commission’s own use of Microsoft 365 violated the applicable data transfer rules because personal data, including telemetry and diagnostic content, flowed to the United States without adequate safeguards. This decision is directly usable as evidence in any TIA: it demonstrates that contractual commitments from Microsoft have not prevented data from reaching US jurisdiction.
Elements a Legally Complete TIA Must Contain
A TIA is not a single-page risk summary. The EDPB’s Recommendations 01/2020 on supplementary measures define a six-step process that maps directly onto what a supervisory authority expects to inspect.
The document must cover the following elements, each supported by evidence rather than assertions. First, it must identify all data flows and their legal basis, specifying which categories of personal data are processed by the provider, in which country the data is stored and accessed, and under which Article 46 mechanism the transfer currently operates. Second, it must assess the third-country legal framework. For US providers, this means analysing the reach of 50 U.S.C. Section 1881a (FISA 702), the CLOUD Act of 2018, and National Security Letters under 18 U.S.C. Section 2709, with specific attention to whether the provider qualifies as an Electronic Communications Service Provider subject to government compulsion. Third, it must document supplementary measures in place, whether technical (end-to-end encryption where the provider holds no keys), contractual (enhanced data processing addenda), or organisational (data minimisation policies). Fourth, it must reach an explicit conclusion on whether the combination of SCCs and supplementary measures achieves essential equivalence. If not, the TIA must state that and recommend remediation, which in practice means sovereign migration.
During a migration window, the TIA must additionally document the residual risk of the legacy environment. This means recording which data remains in the US-controlled environment at any given date, what controls are applied to that residual data, and what the projected migration completion date is. Version-controlling this document with timestamps gives the DPA a defensible timeline demonstrating that the organisation acted promptly.
Assessing Essential Equivalence Under the Revised Swiss FADP
Switzerland occupies a distinctive position in the European data protection landscape. The European Commission issued an adequacy decision for Switzerland under the original FADP, but Switzerland is not an EEA member, and the adequacy decision was made before the revised Swiss Federal Act on Data Protection (FADP) entered into force in September 2023.
The revised FADP substantially aligns Swiss law with GDPR principles: it introduces mandatory data breach notification, privacy by design obligations, data protection impact assessments, and strengthened rights for data subjects. The Swiss Federal Data Protection and Information Commissioner (FDPIC) now has enforcement powers comparable in structure to those of EU supervisory authorities. For a TIA assessing a migration to a Swiss-hosted sovereign environment, the relevant questions are whether the Swiss legal framework contains equivalent national security access provisions to those in the US, and the honest answer is that it does not replicate the FISA 702 or CLOUD Act architecture.
However, until the European Commission formally updates its adequacy decision to cover the revised FADP, DPOs in highly regulated sectors should not treat the Swiss position as entirely resolved. The prudent approach is to document in the TIA that essential equivalence is strongly supported by the revised FADP’s alignment with GDPR structure, by the absence of bulk intelligence collection laws comparable to FISA 702, and by the FDPIC’s independent enforcement posture, while noting that the Commission review is pending and committing to update the TIA once that decision is published.
Which Data Categories Require the Most Urgent TIA Review
Not all data carries the same legal and operational risk during a cloud migration. The categories below warrant priority TIA review, in descending order of urgency, when phasing out Microsoft 365 or Google Workspace.
| Data Category | Sector | Reason for Priority | Relevant Legal Hook |
|---|---|---|---|
| Patient health records and clinical communications | Healthcare | Special category under GDPR Article 9; breach triggers mandatory DPA notification and public disclosure | GDPR Art. 9, NIS-2 Directive |
| Legal professional privilege communications | Legal | Foreign government access could destroy privilege and expose clients | CLOUD Act, FISA 702 |
| Core banking data and payment transaction records | Finance | DORA Article 28 requires ICT third-party risk management with geographic specificity | DORA, GDPR Art. 46 |
| Classified or restricted government communications | Public sector | National security and sovereignty obligations; EDPS decision directly applicable to EU institutions | NIS-2, national classification frameworks |
| HR data with long retention periods | All regulated sectors | Long retention increases the exposure window for US government access over time | GDPR Art. 5(1)(e), Art. 46 |
Translating EDPB Recommendations 01/2020 into Concrete TIA Findings
The EDPB’s Recommendations 01/2020 are the operative framework for TIA construction. The EDPB stated clearly: “The controller or processor must verify, on a case-by-case basis and, where appropriate, in collaboration with the importer in the third country, whether the law or practice of the third country impinges on the effectiveness of the appropriate safeguards.” That phrasing defines both what the TIA must assess and who is responsible for it.
In practice, when a CISO or DPO applies that framework to Microsoft 365, the assessment reaches the same destination the EDPS reached in 2024: the US legal framework gives the NSA and FBI access to data held by US-headquartered providers regardless of where the servers are physically located, because jurisdiction follows corporate control, not server geography. Microsoft’s contractual commitments to challenge government access cannot override domestic US law. The TIA finding is therefore that standard contractual safeguards are insufficient in the absence of strong technical measures, and that the only effective supplementary measure available is encryption where the provider holds no decryption keys. Because Microsoft 365 operates on a shared key management architecture that gives Microsoft access to content, that technical measure is not available within the standard service. The TIA conclusion supporting migration to a sovereign Nextcloud-based workspace is therefore not a preference but a documented legal necessity.
Accountability, Version Control, and the TIA Registry
GDPR Article 5(2) requires controllers to be able to demonstrate compliance with the data protection principles, not merely comply with them. A TIA that exists as a static PDF produced at the time of a migration project closes does not satisfy that requirement. Supervisory authorities conducting audits, particularly in the wake of Schrems II and the EDPS Microsoft 365 decision, look for evidence of ongoing governance rather than one-time documentation.
Organisations should maintain a TIA registry structured as a living database rather than a document repository. Each entry in the registry should record the transfer relationship by provider name and service, the legal mechanism used, the version number and review date of the TIA, the outcome of the latest assessment, and the trigger conditions for the next review. Trigger conditions should include new sub-processor additions by the provider, material changes in the third country’s national security law, and the publication of any Schrems III or equivalent CJEU ruling. The registry should be accessible to both the DPO and the CISO, with change history preserved so that an auditor can reconstruct the organisation’s legal reasoning at any point in time.
For organisations managing multiple third-country transfer relationships, covering cloud infrastructure, SaaS productivity tools, analytics platforms, and AI API calls to services such as OpenAI or Google Gemini, the registry approach makes continuous compliance monitoring operationally feasible. Each AI API call that sends personal data to a US-based model endpoint is a third-country transfer and requires its own TIA entry. Private AI deployments running on open-source models such as Mistral or Llama on sovereign infrastructure eliminate this exposure entirely, which should be recorded in the registry as a transfer relationship closed by design rather than by contractual safeguard.
As Schrems III litigation progresses, the registry gives the compliance team a clear list of which transfer relationships would be affected by an adverse ruling, and how quickly each could be migrated to a sovereign alternative. That readiness posture is itself evidence of accountability under Article 5(2) and is increasingly what DPAs expect to see during supervisory examinations of regulated-sector organisations.
FAQ
Is a Transfer Impact Assessment a legal requirement under the GDPR, or just best practice?
It is a legal requirement. The Schrems II judgment (Case C-311/18) made clear that GDPR Article 46 transfers must be accompanied by a case-by-case assessment of whether the third-country legal environment undermines the safeguard in question. The EDPB formalised this obligation in Recommendations 01/2020. Failure to document a TIA exposes the controller to enforcement action under Article 83.
Does Switzerland count as an adequate country under GDPR, removing the need for SCCs?
The European Commission issued an adequacy decision for Switzerland before the revised FADP entered force in September 2023. The Commission is reviewing whether the revised FADP maintains that equivalence. Until a fresh adequacy decision explicitly covers the new FADP, many DPOs treat the position as uncertain and maintain SCCs or conduct a TIA to confirm essential equivalence, particularly for highly sensitive data categories.
Which Microsoft 365 features triggered the EDPS enforcement action, and what does that mean for a TIA?
The EDPS 2024 decision found that the European Commission transferred telemetry, content, and diagnostic data to Microsoft in the United States without adequate safeguards. For any organisation conducting a TIA on Microsoft 365, this decision is direct evidence that standard contractual controls have not, in practice, prevented the flow of data to US jurisdiction, which directly supports a finding of high residual risk in the legacy environment.
How often should a TIA be reviewed and updated?
A TIA is a living document, not a one-time exercise. The EDPB guidance requires organisations to monitor developments in the third country’s law and practice. Practically, TIAs should be reviewed at least annually, after any significant change in the provider’s sub-processor list or data flows, after any new legal development in the relevant jurisdictions, and whenever Schrems III or equivalent litigation produces a material ruling.
Can a sovereign Nextcloud deployment in Switzerland or the EU eliminate the need for a TIA entirely?
If the deployment runs on infrastructure that is legally and operationally within the EU or in an adequate third country, and no data flows to a jurisdiction lacking adequacy, then the Chapter V transfer rules of the GDPR do not apply and no TIA is needed for that transfer relationship. The organisation should still document this conclusion in its records of processing activities as evidence of the Article 5(2) accountability principle.
