Sending sensitive files safely: a practical checklist

MAIN OÜ Updated 10 July 2026 7 min read

A signed contract, a photo of a passport, a private key, a spreadsheet of customer records — most people send these the same way they send a lunch invite: as an email attachment or a link to a shared folder. The problem is not that these tools fail. It is that they keep working long after you wanted them to stop. This guide walks through why ordinary file sending is riskier than it feels, and gives you an ordered checklist you can follow the next time something confidential has to leave your hands.

Why sending files is riskier than people assume

An email attachment is not sent once. It is copied. A single message can land in the recipient's inbox, their phone's mail cache, their company's mail server, an off-site backup of that server, and — if they forward it — every one of those places again for the next person. You cannot reach into all of those copies and delete them. The file is now wherever the recipient's systems decide to keep it, for as long as they keep anything.

Shared-drive links behave differently but no better. A link to a cloud folder is often set to "anyone with the link can view", and it tends to stay live for months because nobody remembers to revoke it. Links get pasted into chat threads, saved in browser history, and forwarded to people you never chose. The uncomfortable default across all of these tools is the same: almost nothing expires on its own. Unless you go out of your way to set an end date, a sensitive file you shared this morning is still readable next year.

The principles worth following

You do not need to memorise a security manual. A handful of principles cover nearly every case, and the checklist below is just these ideas put in order:

• Encrypt end to end. The file should be unreadable to everyone in the middle — including the service that transports it — and readable only to your recipient.
• Make it expire. Give the file a deadline. Something that deletes itself is far safer than something that relies on you remembering to clean up.
• Prefer one-time download. If the file only needs to arrive once, let it vanish after the first successful download rather than staying available indefinitely.
• Use a separate channel for any password. Never put the lock and its key in the same envelope. If the link travels by email, send the password another way.
• Minimise metadata. The file name alone can leak plenty — severance-agreement-final.pdf tells a story before anyone opens it. Prefer tools that do not transmit or store the name.

The checklist, in order

Work through this the next time you send something confidential. It is deliberately split into before, during, and after, because the mistakes cluster at the edges.

1. Before — strip the metadata. Photos of documents carry location and device data in their EXIF fields; office files often embed author names and edit history. Remove what you can, and rename the file to something neutral.
2. Before — confirm the recipient. Check the address or account you are about to send to, character by character. A surprising share of leaks are simply the right file sent to the wrong person.
3. Before — decide the expiry. Ask how long the recipient realistically needs. Minutes for a one-off download; a day at most for anything routine. Shorter is safer.
4. During — encrypt on your own device. Use a tool that encrypts in your browser or app before upload, so the plaintext never reaches a server.
5. During — set a short time to live. Choose the tightest expiry the situation allows, and enable one-time download if the file only needs to arrive once.
6. During — add a password, sent separately. For anything genuinely sensitive, protect the file with a password and plan to deliver that password over a different channel.
7. During — send the link on a different channel from the password. Link by email, password by phone message or a spoken call. Splitting them means one intercepted channel is not enough.
8. After — confirm receipt out of band. Ask the recipient to tell you, through a channel you already trust, that they opened it. This also tells you the one-time link did its job.
9. After — do not leave copies lying around. Delete the working copy you uploaded, clear it from your downloads and any "recently shared" list, and empty the trash if it held sensitive material.

The one-time encrypted approach, with classified

To make the checklist concrete, here is how it maps onto one tool built for exactly this: classified by MAIN OÜ. It is a working example of the principles above rather than the only way to apply them.

• Encrypted in your browser. Each file is encrypted with AES-256-GCM on your own device before anything is uploaded. Only the ciphertext and an opaque id reach the server; the key rides in the link's URL fragment or is derived from a password you set.
• One-time download. The file is destroyed on first download, and an unopened file is auto-purged when its deadline passes. Expiry ranges from five minutes to twenty-four hours.
• Password mode. You can protect a file with a password that you then send over a separate channel — the split the checklist asks for, built in.
• Names never stored. File names are never sent to or kept by the server, so that particular piece of metadata cannot leak. The size limit is 10 MB per file, and file sharing requires a verified email address.

One honest caveat: one-time download is best-effort. A link preview bot, antivirus scanner, or mail-security prefetcher that follows the link can trigger the single download before your recipient does. If that risk matters, use password mode so a premature fetch yields only an encrypted blob, and confirm receipt out of band.

Special cases that need extra care

Identity documents

Passports, national IDs, and driver's licences are the raw material of identity theft, and unlike a password you cannot rotate them. Send them with the shortest possible expiry, always behind a password, and consider a visible watermark noting the purpose and date ("for account verification, 10 July 2026") so a leaked copy is harder to reuse.

Credentials and keys

API keys, private keys, and recovery codes should be treated as burn-after-reading by default: one-time download, a tight expiry, and a plan to rotate them the moment the transfer is done, so a stray copy becomes worthless. Never commit them to a shared document that lingers.

Legal and medical documents

Contracts, court filings, and health records often carry a legal duty of confidentiality, not just a preference for it. Prefer end-to-end encryption so no intermediary can read the contents, keep a record of who you sent what to and when, and avoid shared folders that quietly grant access to a whole team when only one person needs the file.

What to avoid

• Emailing the file "just in case". Every attachment is a copy you can never recall. If a link will do, do not attach the file.
• Leaving a drive link public. "Anyone with the link" plus no expiry is a file quietly readable for as long as the link survives — which is longer than you think.
• Sending the password in the same thread. It defeats the entire point of having a password. Different channel, every time.
• Relying on a service that can read your files. If the provider holds the key and could open your file, so could an insider, an attacker who breaches them, or anyone who compels them.

A quick way to verify you did it right

Before you close the tab, run one mental check: if this exact link and message leaked to a stranger tomorrow, what could they do with it? If the honest answer is "download the file if it is still live, but they would also need the password I sent by phone" — you are in good shape. If the answer is "read everything", go back to the checklist. Then open the link yourself in a private window: on a one-time share it should now be spent, which is proof the mechanism worked.