Transfer Impact Assessments Before They Were Required

Almost every argument about international data transfers this year has been an argument about instruments. Is the framework valid, are the clauses adequate, which mechanism survives the next hearing. Very few organisations have asked the question underneath all of that, which is considerably more useful and requires no court to answer: for this specific transfer, of this specific data, to this specific recipient, what could actually happen to it, and what would we do about it? That is a transfer impact assessment. Nothing currently obliges anyone to produce one. I think you should produce them anyway, for a reason that has nothing to do with compliance posture: the assessment is the only piece of work in this field that stays useful whichever way the law moves. An instrument can be struck down in a morning. An inventory of your transfers, with a tier and a decision attached to each, keeps its value.

Six questions, one page each

The assessment is not a legal memorandum. For each transfer it answers six questions in plain terms. What data, in what volume, about whom. Employee payroll records for four hundred people is a different proposition from marketing contact details for four hundred thousand, and both are different from a health or biometric dataset of any size. To whom, and who stands behind them. The contracting entity, its corporate parent, and the jurisdictions to which both are subject. A European subsidiary with an American parent is a different risk profile from an independent European company, whatever the contract says. Where the data physically rests and moves. Primary storage, replicas, backups, disaster recovery, content delivery caches, log aggregation, monitoring telemetry. Most organisations can answer for the first and none of the rest. Under what mechanism. Framework certification, standard clauses, binding corporate rules, consent, derogation. Note it, then set it aside; this is the part everyone else is already arguing about. What the destination state can compel, and how it does so in practice. Not a treatise on foreign surveillance law. Three sentences on whether the recipient is the kind of entity that receives orders, whether those orders reach data held for foreign customers, and whether the recipient can tell you when it happens. What would materially change the answer. This is the only question that produces work, and it is the point of the exercise.

The inventory is the hard part, and the transfers you miss are predictable

Ask a technology team to list its transfers and you will get the obvious ones: the cloud platform, the payroll provider, the customer relationship system. The ones that get missed are the same in every organisation. Support and administration access, where nothing is copied but everything is visible, and the session comes from wherever the engineer happens to be. Backup and recovery copies, which frequently land in a different region from production because that is what resilience means. Analytics, advertising and error-reporting tags embedded in your own web properties, each one a transfer you agreed to by adding a script. Collaboration and security telemetry, which is the exhaust of every modern platform. Sub-processors, plural and layered, where your processor's processor is the one holding the data. And the informal channel: spreadsheets emailed between group entities because the system does not support what somebody needed on Thursday. Discovery that works in practice: read the sub-processor lists your vendors publish, pull the access logs for your main systems and look at source locations, ask the network team which egress destinations dominate, and ask the finance team which foreign software suppliers are paid monthly. That last one finds more than any architecture review.

Tier it, then fix the top of the list

A per-transfer legal analysis across four hundred transfers is not a project anyone will finish. Tiering is what makes this tractable. High tier: special categories, large volumes, financial detail, anything about children, and anything where the recipient sits in a jurisdiction with both the means and a demonstrated interest in obtaining it. These get the full six questions, a documented decision and, usually, engineering work. Middle tier: ordinary business data, moderate volumes, established recipients. One page, a decision, and a review date. Low tier: business contact details, aggregated statistics, transfers where identification is genuinely infeasible. Record and move on. In a typical mid-sized group the high tier contains between five and fifteen transfers. That is a week of serious work, not a programme.

The measures that actually change the answer

When the assessment concludes that a transfer carries real risk, four responses do something and the rest are paperwork. Hold the keys somewhere else. Encryption only helps if the party subject to compulsion cannot decrypt. A managed encryption service run by your processor, in your processor's jurisdiction, with your processor able to access the keys, changes the optics and not the exposure. Key custody with a separate provider in a separate jurisdiction changes the exposure. Keep the identifiers at home. Sending transaction or behavioural data abroad while retaining the identity mapping locally is frequently possible, often unglamorous, and reduces the consequence of a disclosure far more than any clause. Constrain the access path. View-only support access, session recording, named individuals, approval before elevation, and a break-glass route that is monitored. Remote administration is the transfer nobody records and the easiest one to control. Change where the data rests. Regional storage, regional backups, regional recovery, and a processor whose corporate structure does not reach into the jurisdiction that worried you. This is the expensive option and sometimes the only honest one. And one commitment worth asking every processor for in writing: tell us when you receive a government request, challenge what you can, and disclose what you are permitted to disclose. Most will not commit fully. Their answer is itself assessment evidence.

Practical Guidance for a Transfer Risk Assessment

• Build the transfer register before the legal analysis. Data, recipient, corporate parent, locations, mechanism, volume, sensitivity. One row per transfer; the register is the deliverable that keeps its value.
• Mine your vendors' sub-processor lists. They are published, they change without notice, and they are the fastest route to the transfers your own documentation has missed.
• Treat support and administrative access as a transfer. Then find out which of your systems can be administered from which countries, and by whom. Expect surprises.
• Tier ruthlessly and assess only the top tier properly. Five to fifteen transfers deserve the full six questions. Everything else needs a line and a review date.
• Ask processors the government request question in writing. Notification, challenge, transparency. Keep the answers, including the refusals, in the assessment file.
• Prefer key custody and identifier retention over contractual comfort. The measures that survive a change in the law are the technical ones.
• Write the decision down, including the decision to accept risk. Who accepted it, on what basis, when it is reviewed. An accepted risk that is documented is a governance position; an undocumented one is an accident.
• Rehearse the fallback once. If your primary mechanism became unavailable tomorrow, which transfers stop, which continue, and who signs. An afternoon now saves a month later.

The Regional Angle

The Gulf occupies an unusual position in this exercise, and organisations here tend to discover it in the wrong order. Most regional entities will encounter the transfer impact assessment as its subject rather than its author. A European customer, a European parent, or a European insurer will ask what happens to their data once it reaches the Emirates, Saudi Arabia or Qatar, and the questions will be exactly the six above. The organisations that answer well will have prepared the answer in advance: what local telecommunications, security and licensing law permits by way of state access, how requests arrive, what the entity would do on receipt, and which technical measures limit the consequences. The organisations that answer badly will reply that local law is fine, which reads as evasion and invites a harder look. The honest and uncomfortable part of that self-assessment is procedural. In much of this region, official access to information often arrives informally, through a call to a general manager or a request from a licensing body, rather than through a documented instrument with a reference number. You cannot write a process description for a channel that leaves no paper trail. What you can do is decide and record your own rule: requests are directed to a named officer, nothing is disclosed without written confirmation of the requesting authority and its legal basis, and each request is logged whether or not it is granted. That document is defensible. Pretending the informal channel does not exist is not. Second, intra-group transfers within the Gulf are almost entirely ungoverned, and this is the gap I find most often. A group with entities in three or four Gulf states runs group human resources from one of them, group finance from another, and a shared service desk from a third. Those are cross-border transfers between jurisdictions with no mutual recognition arrangement, and the free zone regimes that already apply European-style rules treat them as such. Very few regional groups hold any intra-group data transfer agreement at all. It is cheap to put in place, it is the first thing a sophisticated counterparty asks for, and its absence undermines every other assurance the group gives. Third, key custody is more available here than most boards realise. Regional financial institutions have been holding cryptographic material locally for years because their supervisors required it, so the hardware, the operational practice and the providers exist in-market. That makes the strongest technical measure in this article, keys held by a party in a different jurisdiction from the operator, genuinely practical for a regional buyer rather than theoretical. Anyone hosting European data in a Gulf facility, or Gulf data with a foreign operator, should price that option before accepting either a contractual assurance or a full relocation.

The objection worth taking seriously

The strongest objection is epistemic. A private company cannot assess a foreign state's surveillance practice. You have no visibility of classified programmes, no way to verify whether a provider has received orders, and no expertise in the constitutional law of the destination country. What you produce will therefore be a document assembled from published sources, journalism and vendor assurances, dressed as an evaluation, and its real function will be to demonstrate diligence rather than to establish a fact. That is the definition of compliance theatre, and doing it voluntarily, before anyone requires it, looks like theatre performed to an empty room. The second objection is proportionality. Small and mid-sized organisations transfer data to the same handful of large platforms that everyone else uses, cannot negotiate their terms, cannot audit their operations and cannot realistically stop using them. An assessment that concludes there is residual risk and no available alternative has consumed effort to arrive at a position the organisation already occupied. Both are right about what the assessment cannot do, and both miss what it does. This exercise is not an attempt to determine the state of foreign surveillance law; it is an attempt to determine what you hold, where it goes, who can reach it and which of those facts you could change. Those are questions about your own estate, and they are answerable. The output is not a legal conclusion, it is an engineering backlog: three transfers where the backup location should move, two where support access should be constrained, one where the keys should sit elsewhere, and a register that lets you answer a customer, a regulator or a board in an afternoon rather than a quarter. On proportionality, the tiering is the concession: five to fifteen transfers get real work and the rest get a line in a register. And if the mechanism everyone is currently relying on does not survive its next examination, the organisations with a register will spend that week making decisions while everyone else spends it discovering what they transfer.

Common Questions

Is this required today?

No. No instrument obliges a documented per-transfer assessment at present. The inventory and the technical measures are useful regardless, which is the argument for doing it now rather than under deadline.

How long does a first pass take?

For a mid-sized organisation, two to four weeks for the register and about a week for the high-tier assessments. The discovery work consumes most of it, and it is work you will only do once.

What if a transfer has no adequate safeguard and no alternative?

Then you record the risk, name who accepted it and on what basis, apply whatever technical mitigation is available, and set a review date. A documented accepted risk is a legitimate position; an undocumented one is not.

What should we expect over the next twelve months?

Expect the Advocate General's opinion in the pending transfer case within weeks and a judgment next year, either of which will move the ground under whichever mechanism you rely on. Expect supervisory authorities to start asking for transfer documentation as a matter of routine. Expect the large processors to compete on data location commitments, government request transparency and customer-held encryption keys, because those are the only differentiators available to them. And expect the organisations that built a register this year to be the ones answering questions calmly next year.

---

Transfer Risk Assessment — we find the transfers your documentation missed, tier them honestly, and turn the top of the list into a short engineering backlog you can actually finish.