How to Send Sensitive Documents: a Practical Checklist

By ShareDrop.org Engineering · Published 2026-09-17

A scanned passport, a signed contract, a medical report, a tax return. These get sent every day, and most of the mistakes are not about encryption: they are about where copies end up and who else can find the link. This checklist is ordered so that each item makes the next one matter less. Do them in sequence; skip the ones that do not apply. Where a step differs by platform, the specific clicks are given, because “redact the document” is useless advice without them.

Before anything: three questions

Security people call this a threat model; it is really just deciding what you are protecting against, because the answer changes which steps matter.

Before sending

1. Send only what is needed. A landlord needs the photo page of a passport, not the visa pages. A form that wants proof of address does not need the account balance on the same statement. Crop, redact or export only the required pages. The most private data is the data you did not send. (This is also what data-protection law calls minimisation, and it is the one principle that costs nothing.)
2. Redact properly: a black box is often not redaction.
   • PDF on a Mac: Preview → Tools → Redact (macOS 11 and later). This removes the text underneath. Drawing a black rectangle with the Markup tools does not.
   • PDF with Acrobat: Tools → Redact → mark, then Apply. Until you apply, nothing is removed.
   • Word documents: a black highlight or a drawn shape leaves the text in place and searchable. Delete the text, then File → Info → Inspect Document to strip tracked changes and comments, or export to PDF and redact there.
   • Photos and scans: crop the sensitive region out entirely, or paint over it and then flatten by exporting a new copy. On iOS, Photos Markup is non-destructive: the shared copy is flattened, but the original in your library keeps the unedited version and a Revert button.
   • Verify: open the result and try to select or search for the hidden text. If you can find it, so can the recipient.
3. Strip metadata you did not mean to include. Scans and photos carry capture time, device model and often GPS position; office documents carry author names, company, and revision history.
   • Windows: right-click → Properties → Details → Remove Properties and Personal Information.
   • macOS: Preview cannot strip photo metadata; export via the Photos app with “Location” unticked, or use exiftool -all=.
   • iOS: in the share sheet, tap Options at the top and turn off Location (and All Photos Data).
   • Android: Google Photos → share → “Remove location”, or the system share sheet's equivalent.
   • Office: File → Info → Inspect Document → Remove All for Document Properties.
4. Confirm the recipient by a second channel. If the request arrived by email, verify by phone or an existing thread before sending anything. Requests for documents are a favourite phishing pretext (“HR needs a copy of your ID by Friday”), and encryption does nothing against sending a file to the wrong person perfectly securely.

Choosing the channel

5. Prefer a channel where no third party holds a copy. Email leaves the document in two mailboxes and on the providers' servers indefinitely. A cloud link keeps a copy until you delete it. A direct, end-to-end-encrypted transfer leaves one copy, on the recipient's device (how the paths differ).
6. If you must use a link, put an expiry and a password on it, and send the password by a different channel than the link. A link is a key; two halves in two places is the point. Set the sharing mode to specific people rather than “anyone with the link” if the service offers it.
7. If you must use email or chat, encrypt the file itself.
   • PDF password: Preview → File → Export → Encrypt (Mac); Acrobat → Protect; Word → File → Info → Protect Document → Encrypt with Password. Modern PDF encryption (AES-256) is strong; the password is the weak point, so use a passphrase of several words.
   • ZIP: use a tool that offers AES-256 — 7-Zip on Windows, Keka on macOS. The zip -e command built into macOS and many older tools use the legacy ZipCrypto scheme, which is breakable; do not rely on it.
   • Send the password by a different channel (a call, a text, an existing chat), never in the same email as the attachment.

During the transfer

8. Verify the other end, not just the encryption. On a direct transfer, compare the safety code shown on both devices: over the phone if you are not in the same room. Matching codes mean the encrypted session runs between exactly these two devices (why that matters). This is the step that makes “encrypted” mean something: encryption alone protects the channel; the code confirms who is at the other end of it.
9. Confirm integrity. A document that arrives with a flipped byte can be a corrupted PDF or, worse, a subtly altered one. Use a tool that checksums on arrival, or exchange a hash over the same second channel (how, on every platform).

After sending

10. Clean up the copies you control.
    • The export or scan in Downloads or on the desktop.
    • The photo in the camera roll, and then in Recently Deleted, where iOS and macOS keep it for 30 days unless you delete it from there too.
    • The attachment in Sent, and in the provider's trash.
    • The file in the upload service's or cloud drive's history and trash — “delete” in most services means “trash for 30 days.”
    • The message in the chat thread, on both sides if the app allows it.

Encrypted email, honestly

Email can be end-to-end encrypted (PGP and S/MIME have existed for decades), and almost nobody uses them, for a reason that has nothing to do with the mathematics. Both sides need software configured, keys exchanged in advance, and a shared understanding of what to do when something is wrong; a recipient who has never done it cannot be walked through it in the message that needs protecting. Between two people who already use it, it is excellent. For everyone else, encrypting the attachment itself (item 7) delivers the same practical property (the mail providers hold only ciphertext) with nothing to set up beyond a password sent separately.

Messaging apps for documents: what “encrypted” covers

The pattern: the message in flight is usually protected; the backup on the other person's phone is where a document quietly ends up readable. If you send by chat, ask the recipient to delete the message once they have the file, and be aware that “delete for everyone” does not reach a backup that already ran (the three meanings of encrypted).

Sometimes the answer is not a transfer

For a document that must never exist as a file on a network (a will, a medical record with legal weight, anything a court will care about), printing it and handing it over, or showing it on your own screen to a person in the room, is not old-fashioned; it is the only method with no copy problem at all. A transfer tool is for when the other person genuinely needs the file. Check that they do before choosing how to send it.

Three situations, walked through

A passport scan to a landlord

Threat model: identity theft if it leaks; the landlord is a stranger; the copy will be kept for the tenancy. Send only the photo page (1). Scan it with the phone's camera or Files app rather than a third-party scanner that uploads by default (see below), and turn off location in the share options (3). Confirm the request came from the agency by calling the number on their website, not the one in the email (4). Export the scan as a PDF with a password (7) and send that by whatever channel they insist on; text them the password. Then delete the scan from Photos and from Recently Deleted (10). The landlord now holds an encrypted file and a password on two different channels, and your phone holds nothing.

A signed contract to your lawyer

Threat model: commercial confidentiality; the recipient is known and trusted; it must stay private for years. Verification is easy (you have a working relationship), so the emphasis is on copies (5). A direct transfer while you are on the phone with them leaves one copy, on their machine, and they compare the safety code with you out loud (8). If they prefer email, encrypt the PDF (7) and accept that two mailboxes now hold it; the encryption is what makes that acceptable. Either way, clear your Downloads folder afterwards (10).

Medical results to a family member

Threat model: embarrassment or discrimination if it leaks; the recipient is close family; it does not need to persist. Chat apps are the reflex, and an end-to-end encrypted one is acceptable for a photo of a results page, but check that the app is actually end-to-end for attachments and that backups are not silently uploading the chat to a cloud in the clear (how to tell). A direct transfer avoids the question. Crop to the relevant page (1), send, and ask them to delete it once read.

Choosing a password, and getting it to the other person

The encryption on a modern PDF or an AES ZIP is not the weak point; the password is. Use a passphrase of four or five unrelated words (long, easy to say over the phone, hard to guess), rather than eight characters of symbols. Send it by a channel the file did not travel on: if the file went by email, the password goes by text or a call; if the file went by chat, the password goes by phone. Never put both in one message, and never in a message that quotes the previous one. Do not reuse a password you use for anything else, since you are about to hand it to someone.

A word on scanning apps

Where a scan is stored depends on the app, and the default is often not local. Scans made in the iOS Notes app live in Notes and sync to iCloud if Notes syncing is on; scans made through the Files app go to whichever folder you pick, which may be iCloud Drive; many third-party scanner apps upload every page to their own cloud by default and some run OCR there. Before scanning a sensitive document, check where the app puts it, and prefer the built-in camera or a scanner set to save locally. A document you thought you deleted may still be in an app's cloud account.

If you are the one receiving

The checklist applies in reverse. Verify the sender by a second channel before opening anything unexpected, since a “sensitive document” is also a favourite disguise for malware. Compare the safety code if the transfer offers one. Store the document somewhere deliberate (an encrypted folder or a password manager's file storage), rather than leaving it in Downloads, and delete it, including from any trash, when the purpose is served. If the sender asks you to confirm deletion, do; that courtesy is the only enforcement most people have.

What no checklist can fix

Once the recipient has the document, it is theirs to lose. Their device may be unlocked on a desk, backed up to a cloud you have never heard of, or forwarded to a colleague. Encryption in transit protects the trip; it does not extend your control to the destination. The practical defences are upstream: send the minimum (item 1), to the verified person (item 4), and ask them to delete it when the purpose is served.

A note on regulated contexts, which is not legal advice: data-protection regimes such as the GDPR turn item 1 into an obligation and care about where copies are stored; sector rules such as HIPAA in US healthcare require formal agreements with any service that stores protected information. A transfer that stores nothing on a server sidesteps the storage question but does nothing about the obligations on the two endpoints. If the document falls under rules like these, the answer is a system built for custody and audit, not a transfer tool.

The checklist, printable

The short version

Send less than you think. Verify who. Use a channel that keeps no copy, or lock the file if you cannot. Compare the safety code. Delete your leftovers. Five habits cover nearly every realistic failure, and none of them require understanding a cipher.