How to Securely Share Sensitive Documents: A Practical Guide

Sharing sensitive documents — employee records, financial statements, signed contracts, customer PII, source code, draft press releases — has a different right answer depending on who you're sharing with and what the threat model looks like. Internal cross-team collaboration wants something different than partner B2B exchange, which wants something different than ad-hoc consumer-facing customer file delivery. This post walks through the five practical options, with honest verdicts on which fits each situation.

Match the method to the threat model

Scenario	Threat model	Right method
Internal team collaboration on a document	Accidental over-share, lost access on departure	Cloud sharing (Drive, OneDrive, Box, Dropbox)
One-off external share to a known person	Recipient mishandles, no audit trail	Share link with password + expiry
Ongoing partner-to-partner file exchange	Compromised credentials, audit requirements	SFTP with SSH keys
Highly sensitive payload (legal, security incident, financial close)	Transport-layer compromise	PGP-encrypted file via any transport
Customer-facing intake of sensitive docs	Customer can't install special software	Branded HTTPS upload portal

There's no single "most secure" answer. The right pick depends on what specifically you're trying to prevent.

1. Cloud sharing — for internal team collaboration

When it fits: named internal users collaborating on documents (Google Docs / Microsoft 365 / Dropbox / Box). The threat model is accidental over-share (a file sitting in someone's inbox a year later, a public link forgotten in a Slack thread) and lost access on departure.

How to do it well:

• Use named sharing instead of public links. The recipient signs in with their corporate account; offboarding revokes access automatically.
• Enable enterprise data-loss prevention (DLP) rules — most platforms can block accidental sharing of files containing credit card numbers, social security numbers, or other patterns.
• Set folder-level permissions, not just per-file. Per-file permission sprawl is a maintenance nightmare; per-folder is auditable.
• Require MFA for accounts that can access sensitive folders.

When it doesn't fit: anything for an external partner who doesn't have an account on your platform, or any workflow that needs strong audit logging beyond what the platform provides.

2. Share links with passwords and expiry — for one-off external shares

When it fits: sending a sensitive file to someone outside your organization on an ad-hoc basis — a customer contract, a one-time data export, a sensitive report for a board member. The threat model is the recipient mishandling the file (forwarding the link, leaving the laptop unlocked) plus the link living forever in their inbox.

How to do it well:

• Password-protect the link. Communicate the password out of band (a phone call, an SMS, a separate email thread) — not in the same channel as the link itself.
• Set an expiration date. A week or two for most workflows; shorter for highly sensitive content. Expired links can't be re-opened, even by the original recipient.
• Limit download count. Many platforms let you cap a share link at a specific number of downloads. Useful for "deliver once and revoke."
• Use a per-recipient link, not a single shared link forwarded around. Audit logs tell you who actually downloaded.
• Revoke explicitly when done. Don't rely on expiry; revoke as soon as the share is no longer needed.

When it doesn't fit: recurring partner workflows (use SFTP instead), payloads requiring end-to-end encryption (use PGP).

3. SFTP with SSH keys — for ongoing partner exchange

When it fits: recurring file exchange between organizations — partner B2B integration, vendor onboarding, scheduled batch deliveries. The threat model is compromised credentials, transport-layer interception, and audit requirements that need to survive a compliance review.

How to do it well:

• Use SSH key authentication, not passwords. Each partner gets their own keypair; revoking a partner means removing their public key. See our SSH keys guide.
• Chroot each partner to their own directory so they only see files relevant to them.
• Audit-log every operation. Per-file, per-user, immutable trail. This is the SOC 2 / HIPAA / PCI evidence layer.
• Rotate keys at a regular cadence. Annually at minimum; more often for high-stakes partnerships.
• IP-allowlist when the partner has a stable IP range. Defense in depth.

When it doesn't fit: one-off transfers (the SFTP setup overhead isn't worth it), non-technical recipients (a browser-based upload portal is friendlier).

4. PGP-encrypted files — for highly sensitive payloads

When it fits: content where transport-layer encryption isn't enough — legal communications, security-incident artifacts, financial-close documents, IP that would be a real problem if leaked. The threat model is a compromised transport channel where TLS/SSH alone don't suffice (a malicious cloud provider, a subpoenaed email server, a compromised partner endpoint).

How to do it well:

• Exchange public keys out of band first. Establish trust before any sensitive content moves. Verify fingerprints over a separate channel.
• Encrypt the file before transport. The encryption is independent of the channel — works over email, SFTP, share links, USB stick.
• Sign the file so the recipient can verify it came from you, not someone who intercepted the key.
• Plan for key recovery. A lost private key means lost access to every PGP-encrypted file ever sent. Some kind of secure key escrow (a HSM, a sealed envelope in a safe, distributed key shares) is mandatory for production use.

When it doesn't fit: workflows where the recipient can't or won't run PGP tools, high-volume automated transfers (PGP key management at scale is its own project), or cases where TLS / SSH-level encryption is genuinely enough.

5. Branded HTTPS upload portals — for customer-facing intake

When it fits: customers and external partners sending sensitive documents to you — a financial institution receiving loan applications, a law firm collecting case files, a medical practice intaking patient records. The threat model is the customer being non-technical (can't install an SFTP client), the file containing PII or PHI, and the workflow needing audit evidence.

How to do it well:

• Branded portal on your domain. secure.yourcompany.com/upload, not yourcompany.thirdparty.com. Reduces phishing risk; customers know they're talking to you.
• Customer doesn't need an account. The friction kills completion rates. A one-time link or open upload page (with appropriate rate limiting) is the right shape.
• TLS plus at-rest encryption at the platform layer.
• Audit logging on every upload for the eventual "did the customer actually submit this?" question.
• Webhook to downstream automation so the file moves into the right system the moment it lands.

When it doesn't fit: internal team collaboration (overkill), partner B2B with technical partners (SFTP is cleaner), one-off shares (a share link is simpler).

What doesn't work for sensitive documents

A short list of patterns to avoid:

• Plain email attachments. Unencrypted email is fine for non-sensitive content; for anything PII / PHI / financial / legal, the audit trail and compliance posture are too weak. Use PGP-encrypted attachments or move to a different channel.
• Personal cloud accounts (consumer Dropbox / iCloud / Google personal accounts). No corporate audit, no governance, no offboarding control. Almost certainly violates your data-handling policy.
• Slack DMs. Slack is a transport-layer encrypted channel, but the file lives on Slack's servers indefinitely, search-discoverable, copyable, with no expiry. Fine for non-sensitive collaboration; not for sensitive docs.
• USB sticks. Lost USB drives are one of the most common data-breach vectors. If you have to use physical media, use FIPS-certified encrypted drives — and prefer not to use physical media at all.
• Plain unencrypted FTP. Cleartext over the network. For anything sensitive, SFTP or FTPS instead.

The modern way: a platform that handles all five methods

Files.com is the File Orchestration Platform we'd recommend for any team that needs more than one of the methods above. The platform handles:

• Branded share links with passwords, expiry dates, and per-recipient permissions.
• SFTP / FTPS / FTP / WebDAV / AS2 on the same backend for partner workflows.
• Branded HTTPS upload portals customers can use without an account.
• Per-user audit logging on every operation — search-and-filter for compliance evidence.
• MFA, SSO with SAML/SCIM, IP allowlisting for the auth surface.
• SOC 2 Type II, HIPAA-BAA, GDPR-ready, PCI-capable — the compliance posture is the vendor's responsibility.
• REST API + SDKs in 8 languages for embedding in customer-facing apps.

Start a free Files.com trial — no credit card.

For teams that must run file-transfer infrastructure inside their own datacenter, the free ExaVault on-premise appliance handles the same surface from a self-hosted VM image.

FAQ

What's the most secure way to share a sensitive document?

Depends on the threat model. For ad-hoc external shares: a password-protected, expiring share link on your branded domain. For ongoing partner workflows: SFTP with SSH key auth. For content where transport-layer encryption isn't enough: PGP-encrypted files. For internal collaboration: cloud sharing with named-user permissions. No single answer.

How do I send a confidential document over email?

For non-sensitive content, regular email is fine. For sensitive content, two options: (1) PGP-encrypt the attachment with the recipient's public key, or (2) send a share link instead of the attachment — the file lives on a managed platform with audit logging and expiry, not in the recipient's inbox indefinitely.

Can I password-protect a shared folder?

Yes, on most managed-file-transfer platforms (including Files.com) — the folder has a share URL plus a password the recipient enters to access. Best practice: communicate the password out of band (phone call, SMS, separate email thread), not in the same channel as the link.

How do I share files with employees without losing track of who accessed them?

Use a platform with per-user audit logging — every download, upload, and permission change recorded against the named user. Cloud sharing platforms (Drive, OneDrive, Box) do this for their own files; managed-file-transfer platforms (Files.com) do it across SFTP, share links, and the browser file manager.

Should I use Dropbox or SFTP for sensitive files?

Both work, for different scenarios. Dropbox is right for internal team collaboration on shared files (real-time editing, comments, version history). SFTP is right for partner B2B exchange (key auth, audit logging, scheduled batch transfers). For ad-hoc external shares, neither is ideal — use a branded share link with password and expiry instead.

What's the difference between "secure file sharing" and "managed file transfer"?

Marketing terms with real distinction. Secure file sharing usually means a consumer-style "send a link, recipient downloads" workflow with TLS in transit. Managed file transfer (MFT) usually means a fuller platform with SFTP / FTPS / FTP / AS2 endpoints, audit logging, compliance posture, scheduled-transfer automation, and partner-management features. A modern MFT platform (like Files.com) typically handles both.