Is it safe to use a third-party tool with client documents?
It can be — plenty of firms route confidential documents through third-party software every day. The real question isn't whether such a tool can be safe, but how you tell a trustworthy one from a risky one before client files go through it. This is a practical, vendor-neutral checklist for that decision. It is not legal advice; your specific obligations depend on your jurisdiction and your bar's guidance.
Safe is something you verify, not assume
A third-party document tool can absolutely be safe for confidential client files — law firms route documents through outside software constantly, and the well-built tools in the category are engineered exactly for that trust. But "browser extension" or "third-party tool" isn't a safety rating. The category spans reviewed, enterprise-grade software and weekend projects with no answers to basic questions. Safety is a property of the specific tool, and it's one you can check before any client file goes through it.
The checklist below is how you check it. None of it requires a security background — each item is a plain question with a plain answer, and a trustworthy tool can answer all of them without hedging. Where the tool is a standing connection rather than a one-time transfer, add two more: who inside the firm owns the authorization, and what stops working when someone revokes it. The pattern that matters most isn't any single criterion; it's whether the tool is transparent. A vendor that explains where your files go, what it keeps, and how you cut off access is telling you it has thought about the problem. Silence on those questions is itself an answer.
One note before the list: this is a practical guide, not legal advice. Your specific obligations depend on your jurisdiction and your bar's guidance — when in doubt, check those.
Seven questions to ask before you trust a tool
How do you authenticate?
Look for a proper OAuth connection — the authorization-code flow behind 'Sign in with…' buttons, where you log in on the platform's own page and the tool receives a revocable token, not your password. Walk away from anything that asks you to type your platform username and password into its own form.
Where do my files actually go?
Some tools stream a file straight from your browser to its destination; others route it through their own infrastructure. Neither is automatically unsafe. What you want is a clear answer to whether the vendor's servers touch the file at all — so you know what you're trusting and to whom.
Is anything retained, and for how long?
If the vendor's infrastructure handles the file, ask whether the contents are stored and for how long. 'We don't retain your file contents' is a stronger answer than silence. A short, stated retention window is fine; an unstated one is a question.
Is traffic encrypted in transit?
Files and credentials should move over encrypted connections (TLS/HTTPS) end to end. This is table stakes for any serious tool — its absence, or vagueness about it, is a strong signal to stop.
What can the connection do, and can I revoke it?
Ask what the connected token is actually able to do. Some platforms offer fine-grained scopes; others grant broad access that mirrors your own permissions — in which case how much you trust the vendor, and how easily you can revoke the connection, carry the weight. Confirm you can cut off access in one place whenever you need to.
Is there a real company with a published security posture?
A named company, a privacy policy, an architecture or security overview, and ideally an independent security review or SOC 2 report. You're not auditing source code — you're checking that someone has documented how the tool handles data and stands behind it.
What agreements are available?
A clear privacy policy, and — for a tool processing client data at any scale — a data-processing agreement (DPA). If your practice handles protected health information, a business associate agreement (BAA) becomes relevant. Treat these as evidence to weigh, not a single pass/fail box.
Red flags
No single one is always disqualifying — but more than one together is a reason to keep looking.
- ✕It wants your platform password. A tool that asks you to enter your Clio (or other platform) password into its own form, rather than using OAuth, is handing your actual credentials to a third party.
- ✕It won't say where files go or what it keeps. Vagueness about data flow and retention isn't a detail to overlook — it's the core question left unanswered.
- ✕No company, no policy, no posture. No named maker, no privacy policy, and no security information at all. You can't vet what no one will describe.
- ✕It looks abandoned. No recent updates, broken when the browser changes. Security maintenance is ongoing work; a tool no one is maintaining drifts out of safe over time.
The throughline is transparency. You're trusting the tool with client confidences, so it should be able to tell you — plainly and without deflection — how it handles them. A clear answer to the seven questions above is what "safe" actually looks like in practice. For a provider that holds everything rather than passing it through, the same seven carry more weight and two more join them: where the data physically sits, and what an export gives you back if you ever leave.
Is it safe to use a browser extension or third-party tool with confidential client documents?
+It can be — the category includes both well-architected, security-reviewed tools and weekend projects with no answers. Safety isn't a property of the category; it's something you verify per tool. The questions that separate the two are concrete: how you authenticate, where your files actually go and whether they're retained, whether traffic is encrypted, what the connection can do and how you cut it off, and whether there's a real company with a published security posture behind it. A tool that answers all of those clearly is a different proposition from one that's vague about any of them.
How should I authenticate a tool to a platform like Clio?
+Look for a proper OAuth connection — the authorization-code flow you know from 'Sign in with…' buttons, where you log in on the platform's own page and the tool receives a revocable access token instead of your password. The tool never sees the password, and you can revoke the token later without changing it. The pattern to avoid is any tool that asks you to type your platform username and password into its own form; that hands over your actual credentials and is much harder to take back.
Does it matter whether my files pass through the vendor's servers?
+It matters that you can answer the question — not that the answer is always one way. Some tools stream a file straight from your browser to its destination; others route it through their own infrastructure. Pass-through isn't unsafe by itself: a vendor with encryption in transit, a current SOC 2 report, and a data-processing agreement can handle it responsibly, which is how most reputable cloud software works. What you want to know is concrete: does the vendor's infrastructure touch the file, is the content retained, for how long, and under what protections? 'We don't retain your file contents' is a stronger answer than silence.
What agreements or certifications should I look for?
+A clear privacy policy that states what is and isn't collected, and — for a tool that processes client data at any scale — a data-processing agreement (DPA). A SOC 2 report or an independent security review is a strong signal that someone outside the company has examined its controls. If your practice handles protected health information, a business associate agreement (BAA) becomes relevant for tools that touch that data. Treat these as evidence of seriousness to weigh, alongside the rest of the checklist, rather than as a single pass/fail box.
What are the red flags that should stop me?
+A tool that asks for your platform password instead of using OAuth. Vagueness about where files go or whether they're retained. No named company, no privacy policy, and no security information at all. An extension that looks abandoned — no updates, broken when the browser changes. None of these is automatically disqualifying in isolation, but more than one together is a reason to keep looking. You are trusting this tool with client confidences; it should be able to tell you, plainly, how it handles them.
Why does this matter for a law firm specifically?
+Because lawyers carry a duty to protect client confidences, and that duty extends to the technology you choose to handle those confidences. This page is a practical checklist, not legal advice — what your duty requires in a given situation depends on your jurisdiction and your bar's guidance. The durable point is simpler than any rule citation: 'I didn't know where the files went' is not a position you want to be in if a client or a regulator ever asks. Knowing the answers on this list is how you avoid it.
Keep going
Security & architecture
A worked example of these questions answered for one tool — data flow, OAuth token handling, permissions, and how to revoke access.
Read guide →Migrating to Clio
The process playbook for moving a firm to Clio, where tool-selection decisions come up.
Read guide →Tools for uploading to Clio
An honest comparison of the ways firms get documents into Clio, and where each fits.
Read guide →