Skip to content

Blog

The Secure Way to Collect Documents from Clients (Email Attachments Aren't Safe)

You ask clients to email tax returns, IDs, and signed contracts as attachments — but email was never built to keep them private. Here's why it isn't safe, and the secure way to collect them.

By Pocper Team · Published

The Secure Way to Collect Documents from Clients (Email Attachments Aren't Safe)

Every time you need a client's tax return or a copy of their ID, the request is the same: "Just email it over." They attach the file, hit send, and you both move on. It feels like nothing happened. It is also the least protected moment in your whole relationship with that client. Email was built to deliver messages, not to guard the documents stapled to them, and the files you collect this way are exactly the ones that cause real harm if they get out — someone's identity, their whole financial life. The reason a safer method exists at all is that the inbox was never one. It also happens to be where your most sensitive paperwork changes hands.

The everyday habit: 'Just email me the documents'

Picture the last few files a client sent you. Maybe a prior-year tax return, maybe a passport scan for an identity check. Whether you're an accountant or a lawyer, you run some version of the same loop: you need a document from a client, and your default is to have them email it back as an attachment. Nobody sat down and decided this was the secure option. It's the path of least resistance, the same reflex as asking someone to text you their address.

What sets these files apart is what's inside them. A tax return carries a Social Security number and a complete financial history. An ID scan is everything an impersonator needs to open an account in someone else's name. When a document like that leaks, the fallout doesn't show up on your calendar as one bad afternoon; it shows up on your client's credit report and in their bank account.

Why 'email has a password' doesn't make attachments safe

The sense that email is safe comes from the login. You sign in with a password, so the whole thing feels like a sealed room. What the password protects is your account, not the message once it leaves for someone else.

When your mail server hands a message to the recipient's server, it tries to open an encrypted connection first. It works until that negotiation fails. Under the standard that governs mail delivery, the encryption is opportunistic: when an encrypted channel can't be established, the message goes out in the clear, as the IETF's SMTP-over-TLS specification states plainly. The fallback is silent by design, so "my email is encrypted" is a hope rather than a guarantee. An attachment you assumed was protected can cross the internet as plain text.

Then there's permanence. Hit send and the file is out of your hands: it stays in your Sent folder and their inbox, and it travels along inside every forward the thread spawns. You can't recall it, and you have no record of who opened it or saved a copy. There's no delete that reaches every copy, either.

None of this takes a sophisticated attacker. Most confirmed breaches turn on an ordinary human slip — 68% involve a non-malicious human element such as someone falling for a phishing email, according to Verizon's Data Breach Investigations Report. Once a single mailbox falls into the wrong hands, every client attachment inside it is exposed at once.

The real problem isn't email — it's using an open channel for private files

People respond to this by reaching for a better setting — a provider that advertises "secure email," or a password on a zipped archive. None of that reaches the actual problem, because the problem was never the provider. Email is built to carry a message from one person to another and then get out of the way. It was never built to receive files and keep them safe on your behalf over time.

The design has no place for what private documents need: a way to say who is allowed to open a file after it arrives, and a record of who actually did. A better inbox is still an inbox. You've tightened the settings, and the channel underneath is the same one it always was.

What that actually risks: compliance lines and breach costs

The compliance line: how GDPR and HIPAA read a plaintext channel

Up to here this can feel like a matter of degree — a little safer, a little less safe. Regulators don't treat it that way. If any of your clients sit in the EU or the UK, GDPR's Article 32 names encryption of personal data among the technical measures you're expected to have in place when you process it. "Appropriate" carries a lot of weight in that clause, but a channel that can quietly drop to plaintext is hard to defend as appropriate after something has already gone wrong. When it does go wrong, what a regulator weighs is whether you took the measures a careful professional would, and encryption of personal data is on that list by name.

If you handle anything health-related, say a medical bill or an insurance form, the bar is spelled out just as clearly. HIPAA's Security Rule requires technical safeguards for protected health information while it's in transit and points to encryption as the mechanism for meeting that duty. A plain attachment carrying that kind of data doesn't clear it, however routine sending it feels.

What a breach actually costs

Compliance is only the floor. The figure that tends to change minds is the bill at the end. The global average cost of a single data breach has climbed to $4.88 million, according to IBM's annual study with the Ponemon Institute. You won't lose the full average over one leaked return; that number spans huge enterprises and worst-case incidents, so read it as the scale of the risk rather than your personal invoice. The number makes the trade concrete: you're placing a small bet over and over on the emailed attachment, and the losing side of it runs into breach-notification duties and clients who quietly stop referring you. The bill is only the visible part; the rest is weeks of your own time and the goodwill that produced those referrals in the first place.

What 'secure' has to mean before you trust any method

Before you trust any method, you need a bar to hold it against. This is the one I use.

Start with encryption, and notice it has two halves. A file has to be protected while it moves and while it sits in storage afterward. Neither half is an extra a cautious person bolts on; recognized security frameworks treat both as baseline controls. NIST lists protecting information in transit as SC-8 and protecting information at rest as SC-28. A method that encrypts the upload but leaves the stored copy readable has done half the job and called it finished; the copy in storage is still exposed to anyone who reaches the storage.

Encryption on its own still isn't the whole bar. You also need to control who can open a given file after it lands, and you need some record of who reached it and when. Access control is what lets you cut a file off when a device is lost or a relationship ends; the record is what lets you answer, later, whether one specific document was ever exposed. An encrypted file that anyone holding the link can pull, with no trace of who did, is barely a step above the attachment you were trying to get away from.

The requirement people skip is the one that decides whether any of this survives real life: it has to be easy for the client. Ask a stressed client to open an account or install an app they've never heard of, and a good share of them will give up and email you the file anyway. A method only counts as secure when the people on the other end actually use it.

A better way: a client upload link instead of an attachment

On the client's side: one link, no account

The shape of the fix is plain: stop asking clients to attach files to an email, and give them a link that uploads straight into a single place. Instead of a document landing in a mailbox that copies and forwards itself, it arrives in one place rather than scattered across inboxes.

The worry is that "more secure" has to mean "more work for the client," and that they'll push back. A well-built upload flow asks nothing extra of them. We build one of these, a client workspace called Pocper, so I'll use it as the concrete example: according to its own documentation, a client opens a share link or scans a QR code and fills it in from the browser, with no sign-up and no app to install. For the client there's no account to forget and nothing to download, which is exactly why they'll do it instead of falling back to the reply button.

On your side: filed in one place, not scattered across inboxes

The other half is what becomes of the file once it lands. With attachments, it lives wherever the email lives: buried in a thread, maybe re-downloaded later if you're organized about it. A dedicated intake changes that shape. By its own account, the tool lets clients attach PDFs, images, and Office files up to 25 MB, straight into their folder, where each client's uploads file themselves under the right client automatically. On its Plus plan, again by the company's own description, teammates can manage the same clients together. Months later, when you need that one document again, you look in the client's folder instead of searching your mail for the right thread.

The link takes the place of the attachment, and every file you collect ends up in one place rather than scattered across mailboxes.

FAQ

Can't I just password-protect the PDF or zip and email it?

It's a little better than a naked attachment, but it only protects the file. The copies still sit in both mailboxes and every forward. You also can't see who ends up holding one. And the password usually rides in the same thread or a follow-up message anyway, which puts the lock and the key in the same place.

What about a WeTransfer or Dropbox/Google Drive link — is that secure enough?

A share link can beat an attachment, but a link on its own isn't a guarantee. Hold it to the same bar: is the file encrypted in transit and at rest, and can you both limit who opens it and see who did? Some tools clear that and some don't, so check the actual settings rather than the brand name.

I'm a solo practitioner — isn't this overkill for me?

No. The compliance duties don't shrink with the size of your practice; the rules apply to the data you handle, not the number of people handling it. One leaked client file is enough to cause real harm and real liability, and a solo practice has less cushion to absorb an incident like that.

Isn't switching to a secure upload method a hassle to set up?

For a good method, it's less work than what you already do. Chasing files across email threads and filing them by hand is the real hassle; a link that drops each file into the right place removes most of it. For the client it's opening a link and choosing a file, and the setup on your end is mostly one-time.

Email will keep handling these documents right up until the day it doesn't, and by then the file has been copied to more places than you can track. Moving collection off the inbox and onto a controlled upload closes that gap for every client at once.

If pulling sensitive paperwork from clients is a daily part of your job, it's worth seeing what a purpose-built upload workspace does to that routine; Pocper is the one we build for exactly this.

Sources

Get Started Free
PricingTemplates
← Back to Blog