If Someone Stole Your Firm's Database Right Now, Could They Read It

Let me be very honest, most managing partners I've talked to about this have never actually sat down and asked themselves the question in that title, and it's not because they don't care about security, it's because the question sounds abstract until you make it concrete, so let's make it concrete. Say an associate's laptop gets pulled out of her car outside a courthouse, or a paralegal who left on bad terms still has a synced folder of matter files sitting on his personal machine three months after his last day, or somebody gets a foothold on your file server over a long weekend and quietly copies everything off before you even notice, right, all three of those things happened to real firms in the last couple of years and none of them are exotic. The question that actually matters isn't whether someone could get a copy of your data, because at this point you basically have to assume that eventually somebody will, the question is what they'd be holding once they had it. And for a firm running on a generic CRM, or a shared drive, or a practice management tool that only encrypts the hard disk it sits on, the honest answer is they'd be holding a fully readable client list, years of privileged notes, and a trust ledger, in plain text, the moment they got past whatever thin login screen was in front of it. Does that make sense as a problem worth actually sitting with for a minute?

When "Encrypted" Doesn't Mean What You Think

Here's the thing almost nobody explains clearly enough, and it's the whole crux of the question in the title. Most systems, including most legal software, will tell you your data is encrypted, and technically that's true, because the disk the database sits on is encrypted at rest. That protects you from exactly one scenario, someone physically pulling a hard drive out of a server rack and reading it raw. It does basically nothing once someone has legitimate or stolen access to the running system itself, a database backup file, an admin credential, or a SQL export, because at that point the disk has already done its job decrypting everything for the application to use, and whatever's readable to your own software is readable to whoever's holding the copy. So the actual question isn't "is it encrypted," it's "encrypted from what, and does that protection survive the data actually leaving the building." Casely encrypts a second layer on top of the disk, AES-256-GCM applied per firm at the application layer, specifically on the fields that would hurt you the most if they leaked, case notes, matter details, trust entries, documents. That means even a raw database dump, sitting on someone's laptop with no server around it at all, still doesn't hand over plain text on the fields that matter most.

The Ledger Is the Part That Should Worry You Most

For instance, think specifically about the trust ledger for a second, because this is the piece that turns a data breach into a bar complaint. A trust ledger isn't just a number, it's a running history of every deposit, every disbursement, every fee deduction and wire and check against every client matter, and in most systems that whole history sits in the database as readable rows the same way a to-do list would. If that got copied, someone would be able to reconstruct exactly how much money moved through your firm, for which clients, on which dates, which is exactly the kind of thing that's supposed to stay privileged and protected. Casely treats that ledger like the liability it actually is, so a disbursement that would overdraw a matter gets blocked atomically at the database transaction level, it's not a warning you can click past, and the rejection is direct, "Disbursement exceeds trust balance. Bar rules prohibit overdrafts." Entries are voided rather than deleted, so there's always a visible marker of who voided something and why, and the fields carrying all of that get the same app-layer encryption as everything else, so a stolen copy of the ledger doesn't hand someone a readable financial history of your clients.

The First Wall Is the One Most Firms Skip

At the end of the day, though, encryption is the second line of defense, and the first one is just keeping people out in the first place, which is where a lot of firms quietly fail without realizing it. Two factor authentication exists on most legal software as an option somebody can turn on if they feel like it, which in practice means maybe a third of the firm actually has it enabled, and a stolen password is enough to get in everywhere else. Casely enforces 2FA, not offers it, so once it's on for the firm there's no bypass, no "remember this device for 30 days" loophole that quietly defeats the whole point, and setup itself takes about three steps and under two minutes, scan a QR code, type the six digit code it generates, and you're enrolled, with ten recovery codes generated once so you're never locked out of your own account either.

And this is the part firm admins actually like once they see it, you can look at the Users page and see exactly which attorneys have completed enrollment and which haven't, so it's not a policy sitting in a handbook nobody reads, it's a status you can check on a Tuesday morning. If a laptop does get stolen with an active session open, one click signs out every other session tied to that account, so the window of exposure closes immediately instead of staying open until someone remembers to reset a password three days later.

Even a Legitimate Login Shouldn't See Everything

The catch here is that firm databases don't usually get read by outsiders who broke in from scratch, more often it's a login that already exists getting used somewhere it shouldn't, a receptionist's account that happens to also have access to every matter's trust activity, or an associate who's supposed to be walled off from a matter because of a conflict but can still pull the file up if they know where to click. Role-based permissions in Casely control exactly what each person, partner, associate, paralegal, receptionist, can see and touch across documents, the trust ledger, billing, matters, contacts, calendar, users, reports, conflict checks, portal access, and audit logs, so access maps to the actual job instead of being all-or-nothing.

That distinction matters more than it sounds like, because a UI-level restriction only stops someone clicking through the normal app, and anyone who knows how to open a browser's developer tools can often talk to the API directly and get the data anyway. Server-side enforcement means the wall exists at the point where data actually gets handed out, which is the only place a restriction like that is worth anything.

What You Can Actually Check Right Now

So if you want to know where your own firm stands on this before it becomes a real problem instead of a hypothetical one, here's what's worth actually going and checking today, not eventually.

The Portal Side of the Same Question

And so yeah, the same logic runs through the client portal too, because that's another door into the same database, just from the outside. A privileged document tagged as such at the moment it's uploaded can never reach the portal even by accident, the filtering happens server side against what's actually been marked shareable, invoices, e-signature requests, hearing dates, case status, and nothing else, so a client's login is never a backdoor into the notes and documents that are supposed to stay internal.

If It Did Happen Anyway

At the end of the day, no system makes theft impossible, and anyone promising you that is lying, what actually matters is what's left readable afterward and how fast you'd know something happened at all. Because entries are voided instead of deleted, you keep a permanent, visible trail of who touched what and when, which matters just as much for an internal investigation as it does for an external one. Because session control is a single click, a stolen device stops being a live door the moment you notice it's gone. And because the sensitive fields are encrypted at the application layer, not just the disk, a stolen copy of the database itself, backup file, export, whatever form it takes, still isn't a readable copy of your clients' privileged history.

For a five-attorney firm or a fifty-attorney firm, this isn't really a technology question, it's a bar rules question wearing a technology costume, because the obligation to protect client confidences doesn't go away just because the breach happened through a stolen laptop instead of an office break-in. So next time you're evaluating what your firm runs on, or auditing what you already have, the question isn't whether you've got a login screen and a checkbox next to "encrypted," it's whether the data behind that checkbox would actually mean anything to a stranger holding a copy of it, and so yeah, that is basically the whole case for it.