After Schrems II: practical transfer hygiene for API estates

Nearly two years after the Court of Justice struck down Privacy Shield, the dust has settled into something like a routine: new standard contractual clauses, transfer impact assessments, and a steady stream of supervisory decisions, the Austrian and French rulings on website analytics most recently, reminding everyone that the routine has teeth. Talk of a successor framework continues; prudent organizations are not waiting for it.

Amid the legal churn, one operational lesson has become impossible to avoid: you cannot assess a transfer you cannot see. The organizations struggling most with Schrems II are not those with the boldest transfers but those with the vaguest picture of where their data actually goes.

The problem is visibility, not law

Most of the discussion since the ruling has been legal, and understandably so: the clauses, the assessments, the supplementary measures. But the legal analysis assumes a fact that is usually missing, that you know which transfers you are making in the first place. A transfer impact assessment is only as complete as the list of transfers it covers, and in most organizations that list is a composite of vendor contracts and institutional memory, both of which are incomplete by construction.

The consequence is that the hardest part of Schrems II compliance is often not the reasoning but the inventory. The legal team can assess any transfer you put in front of them. What they cannot do is assess the integration a product team stood up two years ago that quietly sends personal data to a support tool hosted abroad, because nobody told them it exists. The gap between the assessed transfers and the actual ones is where the supervisory findings live.

Transfers happen at the integration layer

Personal data does not leave the Union through data centers; it leaves through calls. A support tool hosted abroad, an analytics endpoint, a SaaS API, a partner integration: each is a transfer, and each passes through the estate's integration layer, where it can be seen, constrained, and documented, or not.

• Map from traffic, not contracts: the transfer register built from vendor lists misses the integration a team added in 2019. The one built from gateway records does not.
• Make destination a policy: which categories of data may flow to which jurisdictions should be a rule that executes on every call, not a paragraph in an assessment.
• Keep the evidence at home: whatever happens to the data in flight, the record of what was sent, where, and under which safeguard belongs in your own jurisdiction.

A transfer impact assessment describes what should happen. Your integration layer determines what does.

Building the capability that outlasts the framework

Frameworks will come and, as we have now twice learned, may go. It is genuinely difficult to build a transfer strategy on a legal foundation that a single court ruling can remove overnight, and organizations that pinned everything to Privacy Shield learned that the expensive way. The response is not to guess which framework survives next, but to invest in the thing no ruling can invalidate.

The capability that survives every ruling is the same one: an estate that knows its own flows. An organization that can see, at any moment, which data goes where and under what safeguard can adapt to a new legal reality in an afternoon, because it is changing a policy rather than launching a discovery project. Build that, and each new legal development becomes a policy update rather than a scramble.