How to Protect Client Data Without Breaking ABA Rules
Last year, I was auditing the IT infrastructure for a mid-sized family law practice. The managing partner proudly showed me their new cloud-based case management system. "The vendor promised it's secure," he said. I asked for their Data Processing Agreement. Blank stare. He'd never heard of it.
That moment stayed with me. Not because the partner was negligent — he wasn't. But because the legal profession has a specific ethical framework around client data, and most lawyers I audit don't realize how cloud architecture intersects with those obligations.
Let me be clear: I'm not a lawyer, and this isn't legal advice. I'm a security researcher who has spent years reviewing how law firms store and protect client information. What I've seen during those audits is a pattern of assumptions that create real risk exposure.
The Ethical Framework (and Where It Gets Complicated)
ABA Model Rule 1.6 establishes the duty of confidentiality. Comment 18 to that rule requires lawyers to make "reasonable efforts" to prevent unauthorized access to client information. Separately, Rule 1.1, Comment 8 ties technological awareness to the baseline duty of competence.
Here's where it gets tricky for solo practitioners and small firms. The rules don't prescribe specific technologies. They don't say "you must use encryption X" or "your data must live on-premises." Instead, they require "reasonable efforts" — a standard that depends on the sensitivity of the information, the likelihood of disclosure, and the cost of additional safeguards.
What I see during audits is that many lawyers assume "the vendor handles security" satisfies this standard. It doesn't. The ethical obligation remains with the lawyer, regardless of where the data lives.
What Actually Happens with Cloud SaaS
When a law firm adopts a cloud-based practice management or invoicing tool, they're typically handing over privileged communication, financial records, and personally identifiable information to a third party. The vendor controls the encryption keys, the server infrastructure, and the access policies.
This isn't inherently wrong. Many cloud providers invest heavily in security. But it does mean the firm is outsourcing a significant portion of its "reasonable efforts" to a vendor they may not have properly vetted.
During a breach at a cloud provider — and these happen regularly — the question isn't just "was the vendor negligent?" It's also "did the law firm exercise reasonable diligence in selecting and monitoring that vendor?" If the answer is no, the ethical exposure falls on the lawyer, not the vendor.
Failure Modes I Keep Seeing
After auditing dozens of legal practices, here are the patterns that concern me most:
1. No Data Processing Agreement. The firm can't produce a DPA from their vendor. They don't know where their data is stored, who has access, or what happens in a breach. This makes it nearly impossible to demonstrate "reasonable efforts" if questioned.
2. Over-retention of sensitive data. Client bank details, social security numbers, and medical records sitting in cloud databases long after the case closes. The easiest way to protect data is to not hold it. If you don't need a client's routing number for an active matter, it shouldn't be in your system.
3. Assumed encryption without verification. "The vendor says it's encrypted" — but encrypted at rest? In transit? Who holds the keys? Can the vendor decrypt it for law enforcement or in a breach? Most lawyers I audit don't know the answers.
What I Tell Firms to Do
I don't prescribe specific architectures. But I do recommend a framework:
Know where your data lives. If you can't tell me which server cluster holds a specific client's financial statement, you haven't completed your due diligence. Ask your vendor for a data map. If they can't provide one, that's a red flag.
Minimize what you hold. Don't store sensitive client fields in systems that don't need them. If a project management tool doesn't require a client's tax ID, don't put it there. Less data = smaller attack surface.
Understand the encryption model. If your vendor holds the encryption keys, they can decrypt your data — for compliance, for law enforcement, or in a breach. Zero-knowledge encryption (where only you hold the keys) removes this entire category of risk. It's not the only valid approach, but it's the one that gives you the most control.
Plan for the breach. Assume your vendor will be compromised. What's your response plan? How quickly can you notify affected clients? If you don't have answers, you're not meeting the "reasonable efforts" standard.
The Local-First Question
Some lawyers ask me: "Should I just keep everything on my laptop?"
Local-first architecture — where data lives on your device, encrypted with keys you control — does eliminate an entire category of vendor risk. A breach at a SaaS provider can't expose data that was never on their servers. For highly sensitive matters, this is often the most defensible position.
But it's not the only valid approach. Cloud tools can be appropriate if you've done proper vendor due diligence, signed a DPA, understand the encryption model, and have a breach response plan. The key is intentionality. You can't meet "reasonable efforts" by accident.
I've helped three law firms respond to breach notifications in the past two years. In every case, the data was sitting in a cloud tool the firm had assumed was "secure" without verifying the architecture. You cannot control a vendor's security posture, but you can control your own. Know where your data lives. Hold only what you need. Keep your keys close.