Five years on, in most organizations, the legal team and the engineering team are still not working from the same understanding of what Schrems II requires, what the TIA should assess, and what architectural changes — if any — are needed to bring the current data transfer architecture into compliance. The legal analysis exists. The engineering architecture has not changed to reflect it.
What Schrems II Actually Requires
The CJEU's Schrems II judgment invalidated the EU-US Privacy Shield and imposed an obligation on organizations using standard contractual clauses for EU-to-US data transfers to assess whether US law provides essentially equivalent protection to the data transferred. This assessment — the transfer impact assessment — must consider US surveillance law (particularly FISA Section 702 and Executive Order 12333), the nature of the data transferred, and whether supplementary measures are needed to achieve the required level of protection.
The TIA is not a one-time exercise. It must be updated when relevant factors change: when US law changes, when the data being transferred changes in nature or volume, and when the processing activities of the US recipient change. The obligation is continuous, not point-in-time. The June 2021 SCCs include a TIA requirement as part of their use.
For many organizations, the TIA revealed a straightforward conclusion about US cloud providers: the standard SCCs, with the new 2021 versions, plus the cloud provider's supplementary measures (encryption, access controls), provide adequate protection for the specific data categories and transfer scenarios assessed. For others, the TIA revealed that specific transfer scenarios — involving sensitive data categories, bulk transfers, or specific US recipient practices — require additional supplementary measures or architectural changes.
The TIA is the organization's documented assessment of whether the data transferred is adequately protected. It is a legal document that has architecture implications. Most organizations have produced the legal document. Fewer have implemented the architecture changes the document identified as needed.
Where the Legal-Engineering Gap Lives
The TIA That Identified Issues Engineering Did Not Address
TIAs conducted by legal teams with privacy counsel support identify scenarios where the current transfer architecture may not provide adequate protection. The identified scenarios produce recommendations: encrypt data in a way that the US recipient cannot decrypt, use an EU-only processing architecture for specific data categories, avoid transferring specific sensitive data categories to the US entirely. These recommendations require engineering action.
The gap occurs when the TIA is produced, reviewed by legal, shared with the data protection team, and not communicated to the engineering team in terms that produce architectural changes. Legal has assessed the risk. Engineering has not received the work. The TIA's findings sit in the legal files. The transfer architecture continues unchanged.
The Data Transfer Reality Legal Did Not Know About
TIAs assess the transfers that were disclosed to the legal team — the transfers in the Article 30 records, the transfers that system owners reported during data mapping. They do not assess transfers that were created after the TIA was conducted, transfers through APIs that were not identified as data flow mechanisms during mapping, or transfers through SaaS integrations that were provisioned after the last data mapping exercise.
The engineering team builds integrations continuously. Each new SaaS integration, each new API connection, each new analytics platform integration may create a new EU-to-US transfer that was not in scope for the TIA. Legal's TIA covers the transfers it knew about. Engineering's integrations extend beyond what the TIA covered.
Creating the Connection
The gap between legal's Schrems II assessment and engineering's architecture requires a process that connects the two. Data transfer governance that includes engineering in the TIA process — not to produce legal analysis but to assess whether the current architecture matches what the legal analysis assumes and to implement the supplementary measures the analysis requires — closes the gap that sequential, siloed review creates.
New integration governance that triggers a transfer assessment when a new SaaS tool or API integration creates a new EU-to-non-EU transfer prevents the accumulation of post-TIA transfers that are outside the compliance scope. This requires a mechanism for detecting when engineering integrations create new transfers — either through an integration review process that includes data residency assessment, or through technical monitoring of data flow destinations.
The organizations that have resolved the Schrems II implementation gap have built a joint legal-engineering review process for the specific scenarios the TIA identified as requiring action, and have implemented the integration governance that prevents new unassessed transfers from accumulating. Both investments are required. Legal produces the analysis. Engineering implements the solution.
The TIA identifies what needs to change. Engineering builds the change. Neither step alone resolves the compliance gap.
Produce the TIA. Read what it says needs to change. Build the joint process that implements it. Five years after Schrems II is long enough.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.