Research Data Residency and International Transfers: Where Your Interview Data Actually Lives

The short answer

"Where is our data stored?" is the wrong first question. The right one is "who can lawfully compel access to it, and under which country's law?" Storage location is one input to that answer, not the answer itself. A dataset sitting in a Frankfurt data centre operated by a company subject to another country's disclosure laws is not automatically protected by its postcode.

For research teams, three distinct concepts get collapsed into one word:

• Data residency — the geographic location where data is stored at rest. Usually a contractual commitment you choose.
• Data sovereignty — whose laws govern that data, including who can compel disclosure. Follows the operator and the legal entity, not just the server.
• Data localisation — a legal requirement that data must stay in a country. Imposed by statute, not chosen.

Under GDPR, moving personal data outside the EEA is a restricted transfer and needs a Chapter V mechanism regardless of where you store it. Getting this right takes an afternoon. Getting it wrong surfaces during a security review, three weeks before you needed the research.

Why this lands on research teams

Interview data is unusually exposed. Survey responses are short and often anonymous; interview transcripts are long, narrative, and full of incidental identifiers — a person naming their employer, their manager, a medical condition, a customer account. Recorded voice adds another layer, since in some jurisdictions voiceprints are biometric data with their own rules.

Meanwhile the processing chain is long. A single study can touch a recruitment tool, an interview platform, a transcription service, an LLM analysis provider, and a repository — potentially in four countries. Your transfer analysis has to cover the whole chain, not just the platform you bought. The most common finding in a research security review is not that the vendor is in the wrong country; it is that nobody mapped the sub-processors.

GDPR Chapter V: the transfer mechanisms

A note on the Data Privacy Framework's stability

The DPF remains valid law and is the simplest route for certified US vendors, but it is under active challenge. The EU General Court dismissed the Latombe action on 3 September 2025, upholding the framework; that ruling was appealed to the Court of Justice on 31 October 2025 and the appeal is still pending. Separately, the US Privacy and Civil Liberties Oversight Board lost its quorum in January 2025 when three of its five members were removed — and PCLOB oversight was one of the safeguards the Commission relied on in finding US protections adequate.

None of this means you should avoid the DPF. It means you should not build a research programme whose only transfer mechanism is the DPF. The resilient pattern is DPF certification plus SCCs as fallback in the same contract. That way an adverse ruling is a paperwork event rather than a fieldwork stoppage. Ask your vendor directly whether their DPA includes SCCs alongside any DPF reliance.

Transfer impact assessments

Since Schrems II (2020), relying on SCCs is not enough on its own. You must assess whether the destination country's law undermines the protection the clauses promise, and add supplementary measures where it does — encryption with keys held in the EEA, pseudonymisation before transfer, or contractual commitments to challenge and report access requests.

For research specifically, the highest-value supplementary measure is pseudonymisation before transfer. If names, employers, and direct identifiers are stripped and held separately in the EEA, what crosses the border is far less sensitive and your TIA becomes considerably easier to write.

Beyond the EU

• UK GDPR — separate regime. Transfers out of the UK use the International Data Transfer Agreement or the UK Addendum to the EU SCCs. The UK's own adequacy status under EU law has been extended rather than made permanent and is subject to periodic review, so confirm the current position rather than assuming it holds.
• Switzerland — its own framework and a Swiss-US arrangement; the EU SCCs need Swiss-specific amendments.
• Brazil (LGPD) — transfers require adequacy, contractual clauses, or specific consent; the ANPD has issued its own standard clauses.
• Canada (PIPEDA) — no localisation requirement federally, but transfers require comparable protection and transparency to individuals about offshore processing. Some provincial public-sector rules are stricter.
• India (DPDP Act) — a blocklist model rather than an allowlist: transfers permitted except to countries the government restricts.
• China (PIPL) — genuinely restrictive, with security assessments, standard contracts, or certification required, plus localisation duties for some operators. Treat China research as a separate project with local counsel.

Practical implication: if you run global research, do not try to satisfy every regime with one policy. Segment by participant region, apply the strictest applicable rule per segment, and document the segmentation.

Six questions to ask any research vendor

Send these before the security review, not during it:

1. In which countries is interview data stored at rest, and in which is it processed? These are different answers.
2. List every sub-processor that touches participant data — transcription, LLM inference, storage, email. Which are on your DPA's sub-processor list?
3. Which transfer mechanism applies, and does the DPA include SCCs in addition to any adequacy or DPF reliance?
4. Is data used to train models? For a research platform, the answer should be no for customer content. Get it in the contract, not the FAQ.
5. What is the deletion path and its SLA, including backups?
6. Can you support pseudonymisation before data leaves our control?

Question 4 is the one that changed most in 2026. Model-training terms move faster than security pages; verify against the current DPA rather than a blog post.

How Koji reduces the surface area

Most transfer risk in research is created by the shape of the data, not the route it travels. Koji is built so that less sensitive data exists in the first place.

Structured questions collect bounded values. Koji supports six question types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no. A scale, single_choice, or yes_no answer is a value, not a narrative that might contain a name, a diagnosis, or a customer's identity. Every question you convert reduces what crosses any border. See the structured questions guide.

Anonymisation before sharing. Transcripts can be anonymised before they are shared or exported, which is exactly the supplementary measure a transfer impact assessment asks for. See anonymizing customer interview data.

A short chain. Recruitment link, AI-moderated interview, automatic transcription, automatic analysis, report — inside one platform. Compare that with the usual stack of a scheduler, a video tool, a separate transcription vendor, an LLM analysis add-on, and a repository, each with its own sub-processors and its own transfer analysis. Fewer hops means a shorter list to assess.

Deletion you control. Interview data, transcripts, and analysis belong to your account, and studies and their associated data can be deleted at any time — the concrete evidence a deletion SLA needs.

Text-only mode as a mitigation. Where voice recording raises biometric questions in a given jurisdiction, running the study as a text interview removes the issue entirely while keeping the conversational depth and AI follow-up probing. That option does not exist in a video-based research stack.

For teams with contractual residency requirements or a specific enterprise data-handling posture, contact the Koji team to discuss enterprise options rather than inferring the answer from a docs page.

Five common mistakes

1. Treating storage location as the whole answer. Sovereignty follows the operator and applicable law too.
2. Mapping the platform but not the sub-processors. The transcription and inference layers are where surprises live.
3. Relying on Article 49 consent for ongoing operations. The derogations are for occasional transfers, not a running research programme.
4. Relying on the DPF alone. Pair it with SCCs so a court ruling is a paperwork problem, not an outage.
5. Doing the analysis once. Vendors change sub-processors and regions. Re-check at renewal.

Related Resources

• Enterprise Security for AI Research Platforms — SOC 2, SSO, and the vendor review process
• GDPR-Compliant AI User Research — lawful basis and participant rights
• DPIA for User Research — the risk assessment that references your transfer analysis
• AI Interview Data Privacy and Security — the buyer's evaluation checklist
• Anonymizing Customer Interview Data — pseudonymisation as a supplementary measure
• Research Data Retention and Deletion — how long data should exist anywhere
• Structured Questions Guide — the six question types and data minimisation by design