How to collect documents from clients securely

For sensitive documents, use a link the client can open without an account, where each file is encrypted on the client’s device to a key only you hold. That removes the two usual failure points: the client giving up at a signup screen and emailing a photo instead, and a readable copy sitting with a third party.

If you need automatic reminders to clients, branded upload pages or a full practice portal more than you need that encryption property, a client portal or a branded upload tool will serve you better. The trade-off is that those tools can generally read what your clients upload.

Email is what most clients default to, and it needs no account. The problem is where the file ends up: a readable copy in the client’s sent folder, in your inbox, on both mail providers’ servers, and in any backup or forwarding rule along the way. Transport encryption between mail servers protects the file in transit only; it is stored readable at both ends.

Zipping with a password helps only if the archive uses AES encryption rather than the legacy ZipCrypto scheme, and only if the password travels by a different channel than the file. In practice clients often send both in the same email. There is no checklist and no tracking; chasing is manual. It costs nothing.

Dropbox File Request lets anyone upload into a folder of yours without a Dropbox account; they may be asked for a name and email address. You get an email when a file arrives, can add an optional password, and on Professional and business plans can set a deadline. Uploads are limited to 2 GB per file on Basic, Plus and Family and 250 GB on the business plans.

Dropbox encrypts stored files with AES-256, but its own help centre states it does not offer client-side encryption, so the files are readable by the service. Dropbox’s end-to-end encrypted team folders, on Business Plus and above, list file requests as a feature that is not available in them.

Google Drive has no equivalent upload-only link. The usual workaround is a Google Form with a file-upload question, and Google’s documentation says respondents must sign in to a Google account to answer it. Files land in the form owner’s Drive, encrypted at rest by Google, not by your client.

Portals built for accountants, lawyers and agencies (Content Snare, SmartVault, TaxDome and others) are the most complete workflow tools. They organise requests per client, track what is outstanding, and many chase clients for you.

Content Snare, for example, includes unlimited automatic email reminders on every plan, from $35 per month billed annually. If your real problem is clients who forget, that feature is worth more than anything else on this page.

Before choosing one for sensitive intake, read the vendor’s security page for one specific claim: that files are encrypted on the client’s device to a key only you hold. Most portal documentation describes encryption in transit and at rest, which protects against a stolen disk but leaves the provider able to read the files. Some portals also require the client to create a login, which costs you completion rate.

An encrypted request link looks like a file request to the client: open a link, drop files in, no account. The difference is that the browser encrypts each file before upload, so the service stores ciphertext. Whether the provider can decrypt depends on who holds the key, and vendors differ on that — the companion page compares encrypted file request tools one by one.

Tresorit File Requests encrypt on the uploader’s device and need no Tresorit account, but every uploader must give an email address, and the feature is on paid plans only.

FileSeal encrypts in the browser with AES-GCM-256; in its default delivery mode FileSeal holds the key, and in its “Get a link” mode the key lives only in the link.

ShieldFive File Request encrypts each file and its filename in the client’s browser to your firm’s public key — a hybrid of ML-KEM-1024 and X25519 — and stores ciphertext in the EU. You decrypt in your own browser. The client needs no account; you need a free one to create requests and hold the keys.

If the documents are routine and low-risk, a Dropbox file request is fine and your clients probably know it already. If they are IDs, tax returns, bank statements, medical or legal material, the question that matters is who can read them once stored — and for email, file requests and most portals, the answer includes the provider.

If you mainly lose time chasing, pick the tool with automatic client reminders and accept that trade-off knowingly. If you need both strong encryption and heavy workflow, some firms run an encrypted request link for the sensitive items and their portal for everything else.

Whatever you use: send any PIN or password by a different channel from the link, set links to expire when the intake is done, and list exactly which documents you need so the client does not send extras you then have to hold.

If you prepare US tax returns, the choice is also a compliance question: the FTC Safeguards Rule requires a written security plan and encryption of client data in transit and at rest. The guide for tax preparers maps each of these methods against the rule and IRS Publications 4557 and 5708.

Chasing is light. On Firm seats (and during the trial), if you add the client’s email, ShieldFive reminds them at most twice, after about three and seven days, while required items are missing. The reminder cannot contain the upload link, because the decryption key never reaches our server, so it points the client back to the link you sent. You also get a reminder to follow up. Your firm name and logo appear on the upload page on the paid plan and during the 14-day trial. A portal with unlimited automatic reminders will chase harder.

Your firm name and logo appear on the upload page on the paid plan and during the 14-day trial, but there is no custom domain and no recurring or scheduled requests: you create a fresh request each time. Every link needs a PIN of at least four characters, which you share with the client separately.

And the honest ceiling on the encryption: like any web app, we serve the JavaScript that does it. The guarantee is “encrypted in the client’s browser, ciphertext at rest”, not a claim that no compromised server could ever interfere. The request security page explains the threat model.