How to send files securely, without turning it into a project

Most people worry about interception and are actually exposed by a link that outlived its purpose. Name the threat first, then pick the method — and a short routine that covers nearly every real case.

Jul 10, 20264 min read

"Securely" is doing a lot of work in most sentences it appears in. Before choosing a method it is worth being specific about what you are protecting the file from, because the answers pull in different directions.

This is a practical guide: the threats worth naming, what each common method actually defends against, and a short routine that covers most real situations.

Name the threat first

Four different worries hide behind the word secure.

Interception in transit. Someone reading the file as it crosses the network. Largely solved: any service on HTTPS handles this, and it is the least likely of the four.
The provider. The company storing your file being able to read it, whether through an employee, a legal request, or a breach of their storage.
The link leaking. Far and away the most common real failure. Links get forwarded, pasted into group chats, and left in mailboxes for years.
The recipient. Once they have the file they have the file. No technical measure survives someone choosing to pass it on, and pretending otherwise leads to bad decisions.

Most people worry about the first and are actually exposed by the third.

What the common methods defend

Email attachments

Encrypted between well-configured mail servers, and stored in plaintext in two mailboxes indefinitely. Copies multiply on every forward and reply-all. Fine for the unremarkable, wrong for anything you would not want sitting in an inbox in three years.

A shared cloud folder

Good access control if it is configured deliberately, and that is the catch — the default is often "anyone with the link", the link outlives the project, and access reviews do not happen. The provider can read the contents.

A transfer link

Nothing for the recipient to sign into, which is what makes it usable outside your own organisation. Security depends on two things: whether the link expires, and whether the provider can read the file.

An encrypted archive

A password-protected zip is genuinely better than nothing, and its weakness is the password: it usually travels in the same email as the file, which defeats it entirely. If you use one, send the password by another route.

The routine

For anything sensitive, in order:

Send only what is needed. One page of a statement rather than a year of them. The most reliable way to protect data is not to send it.
Encrypt end to end, so the provider holds bytes it cannot read. On this service that is the default and costs no extra steps.
Set a short expiry. A day for anything genuinely sensitive. Expiry is the only protection that still works after you have lost track of the link.
Separate the key from the link when it matters. A link carrying its own key in the fragment is convenient and means the link alone is enough to open the file. Passing the key by another channel — a phone call, a different app — means an intercepted link is useless on its own.
Send to one person per message. One address per message, never a shared inbox with fifteen people in it.
Check afterwards. Download counts and delivery receipts tell you whether it arrived and whether it was opened more times than there are people who should have opened it.
Revoke when the job is done. Do not wait for expiry if the file has served its purpose.

Two mistakes that undo the rest

Sending the key with the file. A password in the same email as the encrypted archive protects against nothing. Two channels, always.

Trusting a link to stay where you put it. A share link is a credential, and it behaves like one: anyone holding it has whatever access it grants. Treat forwarding as a certainty rather than a possibility, and set the expiry accordingly.

If you have a compliance obligation

GDPR, HIPAA and their equivalents care about specifics, and a blog post is not advice. But the useful general principle is data minimisation: the less you send, the shorter it exists, and the fewer people who can read it, the smaller the problem in every direction — including the paperwork if something goes wrong.

Three questions worth being able to answer about any service you use for regulated data: what is stored, for how long, and who can read it. Ours are answered in the privacy policy, with the retention windows stated as the ones the system actually enforces.

The short version

Encrypt end to end, expire quickly, split the key from the link when it matters, and send the minimum. That covers the overwhelming majority of real risk without turning a five-minute task into a project.

What end-to-end encryption actually means for the files you send

Nearly every file service says it encrypts your files, and almost none of them mean the same thing. Here is the difference that decides whether the company holding your file can open it, and how to tell from the outside.

Aug 14, 2026

Security4 min read

Password-protecting a file is not the same as encrypting it

Three different things go by the same name, and one of them is a door with a lock painted on it. How to tell which you have, why legacy zip encryption is worthless, and the mistake that undoes all of it.

Jul 21, 2026