Where Do Your Files Actually Go When You 'Share' Them?

This is a technical and general-compliance explainer, not legal advice. If international transfer rules matter to your organization, talk to counsel about your specific facts.

"Just upload it and send them the link" is the default way most people share a file today. It's worth being precise about what that sentence actually does, because it's easy to picture the file moving in a straight line from you to the recipient. It doesn't. It moves from you, to a server owned by a third company, where it sits — even briefly — before the recipient downloads it. That middle step is where most of the interesting questions live.

A copy exists, even if you delete it later

Any "upload, get a link, share the link" service — cloud storage, a transfer tool, an email attachment relayed through a provider's infrastructure — necessarily stores a copy of your file on its own servers for at least as long as the link is valid. That's not a criticism of those services; it's what makes the link-sharing model work at all. But it means:

• The data is now subject to that provider's retention policy, breach history, and internal access controls — not just your own.
• It's subject to the legal jurisdiction of wherever that provider's servers and corporate entity actually sit, which may not be the jurisdiction either you or your recipient are in.
• It's a second copy that has to be separately secured, and separately accounted for if you're ever asked "where does this data live."

Why "which country" is a real legal question, not pedantry

If you're in the EU and the file contains personal data, moving it to a server outside the EU/EEA is what GDPR calls an international transfer, and Chapter V of the regulation requires a legal basis for it — not because the mechanics are exotic, but because the protection is supposed to follow the data. In practice, transfers to the US mostly rely on one of two mechanisms:

• An adequacy decision — the European Commission decides a given country's protections are equivalent to the EU's own. The current one for the US is the EU-US Data Privacy Framework (DPF), adopted July 10, 2023, covering transfers to US organizations that have self-certified to the DPF principles and fall under FTC or Department of Transportation jurisdiction (European Commission, dataprivacyframework.gov).
• Standard Contractual Clauses (SCCs) — a contract-based mechanism used when no adequacy decision applies, or as a fallback alongside one.

This machinery exists because of history that's worth knowing: the EU's previous adequacy arrangements with the US (Safe Harbor, then Privacy Shield) were both struck down by the Court of Justice of the EU — the second time in the 2020 ruling known as Schrems II — over concerns that US surveillance law didn't give EU residents enforceable protections. The DPF was built to answer that ruling, backed by a new US executive order constraining signals-intelligence collection. It's also, as of this writing, still being actively challenged in EU courts (informally called Schrems III); a General Court ruling in September 2025 upheld the DPF's adequacy, though that decision remains open to appeal. The honest summary is: the DPF is currently valid and in active use by roughly 2,700 certified US organizations, and this area of law has a track record of changing again.

None of this makes uploading a file to a US-based service illegal — most organizations do it every day, under one of these mechanisms. It does mean "we uploaded it to a share link" is not actually the end of the compliance question; it's the start of one, with paperwork attached.

The alternative: don't create the copy in the first place

A direct, peer-to-peer transfer sidesteps this specific problem structurally rather than contractually. If a file goes straight from one machine to another — as it does over a properly encrypted WebRTC connection — there is no third-party server holding a copy, so there's no second location, jurisdiction, or retention policy to reason about for that file. The question "did this cross a border in a way that needs a legal transfer mechanism" doesn't arise for a hop that never happened.

This is a large part of why Privatta is built the way it is: the file streams directly from sender to recipient once the connection is open, and the signaling server that helps the two sides find each other never receives the file — only enough metadata to introduce them. It's an open-source, stateless relay: one in-memory table of pending pairings, no database, and it forgets a pairing the instant its two peers connect.

Two honest caveats, because this is a compliance topic and overstating it would defeat the point of writing about it accurately: first, direct transfer removes the storage-in-transit problem specifically — it doesn't replace your organization's broader GDPR obligations around consent, retention, or security once a file lands on the recipient's own device. Second, "no cloud copy" is a genuine architectural property you can verify (the relay is open source), not a compliance certification — if your organization needs to formally document its data flows, that documentation work still has to happen; this just makes the honest answer to "does this step involve an international transfer" a simple no.