The question worth asking a practice-software vendor is not “is our data secure?” but “where does our data sit relative to another firm’s, and what exactly keeps them apart?” There are four common answers. Two of them are permission models, two are structural. Only structural separation limits the blast radius of another firm’s incident — and only structural separation can be demonstrated to a client, an insurer or a regulator without asking them to trust a configuration screen.
Executive summary
Law firms are increasingly asked, usually during client onboarding or an indemnity renewal, to explain where their clients’ information is held and who could reach it. Most firms answer from instinct, because the software they use has never given them a more precise answer.
This paper separates the marketing from the mechanics. It describes four models of separation found in practice, scores each against the four things firms actually care about — confidentiality, blast radius, verifiability and exit — and sets out a test a firm can run in a week without technical staff.
It also states, plainly, the limits of our own position. A whitepaper that only argues for its author is a sales document, and firms are entitled to a better class of reading than that.
1 · Why this question is being asked now
Three pressures have converged:
- Clients ask. Commercial clients, and increasingly private ones, ask in their onboarding paperwork where their files are held and who else could access them. Legal departments pose the same question in panel tenders.
- Insurers ask. Professional-indemnity renewals now routinely include questions about systems, access control, backups and the handling of client money. “We use cloud software” is not an answer.
- Regulators ask. Record-keeping, supervision and client-money rules assume you can show what happened, who did it and when. That is difficult when the record is spread across a spreadsheet, an inbox and a messaging group.
The trap is that all of these questions sound like questions about security, and security questions have comfortable answers — encryption, certifications, a well-known vendor name. The underlying question is different. It is about structure: whether separation is a property of the system or a promise made by the people operating it.
2 · Four models of separation
Every practice-management system sits somewhere on this ladder. Most vendors are on the first rung and describe it with the language of the second, third or fourth; the useful procurement work is finding out which rung you are actually on.
| Model | What it means | Blast radius of one firm’s incident | Verifiable by the firm? |
|---|---|---|---|
| A · Shared table | All firms in one database; each row carries a firm identifier and every query must filter on it | The whole platform | Only by audit — the separation exists in code, not in the data layout |
| B · Shared database, isolated schema | One database engine, but each firm’s tables live in a separate schema with separate permissions | Firm-by-firm for query errors; database-wide for engine failures | Partly — a firm can be shown its own schema |
| C · Database per firm | Each firm has its own database; the application connects as that firm only | Confined to the firm involved | Yes — the firm can be given direct access to its own store |
| D · Deployment per firm, with a separate client-facing system | Each firm has its own application instance and store; the client portal runs separately with its own store containing only what was shared | Confined to one firm, and to one side of that firm | Yes — including the boundary between staff data and client-visible data |
Why model A is not automatically wrong
A disciplined shared-table system, built by competent engineers, can be perfectly acceptable — and it is how most of the software industry works. The weakness is not incompetence; it is that correctness depends on every query, every endpoint, every background job and every future feature remembering to filter correctly, forever. That is a strong position to hold in a sales meeting and a demanding one to hold in an engineering department.
Why model D changes the client-portal conversation
In models A and B the client portal is usually the same application reading the same store, with a different set of permission rules. The portal is therefore as trustworthy as the most recent piece of code that touched it.
In model D the portal is a separate system: a separate application, a separate store, and — the part that matters — a store that never contained staff records in the first place. It holds the matters, documents, messages and invoices the firm deliberately shared. There is nothing in it to leak, because nothing else was ever put there.
For a firm whose clients ask “who can see my file?”, that is a sentence you can say out loud without hoping nobody follows up.
3 · What separation does not solve
A firm that adopts the strongest model and changes nothing else will still have most of its risks. Separation is one control, not a security programme, and honest vendors say so before they are asked.
- It does not fix a careless user. Someone who downloads a client list to a personal device has defeated every architectural control in this paper.
- It does not fix weak credentials. Multi-factor authentication, forced password changes on first sign-in and lockout policy remain essential.
- It does not cover the systems outside it. Client files in personal inboxes, spreadsheets on a shared drive and messaging groups sit outside any practice system’s protection.
- It does not replace backups. Separation limits who can reach data; it does not bring data back after deletion, corruption or ransomware. Restores must be rehearsed, not assumed.
- It does not make a firm compliant. Client-money rules, supervision and record-keeping are the firm’s obligations. Software can enforce parts of them — a ledger that refuses a deficit is genuinely useful — but responsibility does not transfer with a subscription.
The right conclusion is not “separation is unnecessary”. It is that separation is the part you can verify, so it is where a procurement conversation should start — and then move to the controls that depend on people.
4 · A ten-point test you can run in a week
None of these require technical staff, and only the last two need the vendor’s cooperation beyond a demo. Ask for the answer in writing; if a vendor will not write it down, that is itself information.
| # | Test | What a good answer looks like |
|---|---|---|
| 1 | Where does our data sit relative to another firm’s? | A description of the model — table, schema, database, deployment — not the word “secure” |
| 2 | What happens to our firm if another firm has an incident? | A bounded answer with a reason, not a reassurance |
| 3 | Does the client portal read the same store as the staff application? | Either answer is acceptable if stated honestly; the follow-up is what changes |
| 4 | Can we see our own data directly, without going through the application? | An export, or credentials to our own store, demonstrated live |
| 5 | How are updates delivered, and who is first? | A staged process with a test environment and a rollback route, ideally per firm |
| 6 | Show me a restore, not a backup schedule. | A drill record with dates and durations, or a live demonstration |
| 7 | What exactly do we receive if we leave, in what format, in what timescale, at what cost? | Specifics, in writing, with no exit fee for your own data |
| 8 | Who inside the vendor can reach our data, and is that access recorded? | A named set of roles and an access log you can be shown |
| 9 | Can we verify any of these claims independently? | Source code, a public build record, a third-party report, or our own technical adviser’s access |
| 10 | What are the honest limits of your product today? | A named list. Every competent vendor has one, and the willingness to give it predicts the relationship |
5 · What to put in writing
Assurances given in a demonstration have a habit of not surviving the second year. These six terms convert them into something a firm can rely on — and any vendor confident in its architecture will accept them without much argument.
- Export commitment. What the firm receives on request and on termination, in what format, within what period, and confirmation that no fee applies to its own data.
- Restore commitment. A stated restore point and restore time, plus an obligation to rehearse and to provide the drill record on request.
- Update process. How releases are tested, how they reach a firm, how a firm can defer one, and how a rollback is performed.
- Sub-processor notice. Advance notice of any new party that processes firm data, with a right to object.
- Incident notification. Notification without undue delay, a named channel, and a written summary afterwards.
- Access transparency. Who at the vendor can reach firm data, recorded and available on request.
None of these require the vendor to disclose trade secrets. All of them require the vendor to have thought about the question — which is precisely the signal a firm is looking for.
6 · Where OpenLPM stands
Our own position, against the same test, including the parts that are not finished. A whitepaper that applies a test to everyone else and exempts itself is not worth the paper it is printed on.
| Test | Our position |
|---|---|
| Separation model | Model D. Each firm runs its own instance with its own store; the client portal is a separate system with a separate store containing only what the firm shared |
| Blast radius | Confined to the firm involved for application and data faults. Honest caveat: our demo fleet currently shares one account boundary between firms, and per-firm accounts are a documented piece of in-progress work |
| Portal boundary | The portal holds no staff records by construction, and staff-only areas of the application are not reachable from the portal at all — verified on the live instances |
| Independent verification | Source code and a numbered build record are public under Apache 2.0. Verify §5 above by reading the code rather than trusting this page |
| Updates | Released per firm after testing on our own instance, with rollback for the firm affected |
| Honest limits | Client and firm software share one codebase with two runtime-separated deployments — the separation is infrastructural, not a separate source tree; and client-money balance checks are safe for single-operator use, with multi-writer firms flagged for review before general release |
7 · How to verify any of this
The point of a structural claim is that it does not need to be believed. Three things a firm — or its technical adviser — can do this week:
- Open the live demonstrations. Two of our demo environments are public: one staff workspace, one client portal. Try to reach staff areas from the portal.
- Read the source. The repository is public, including the migration record that documents how the separation was built and what it cost us to get right.
- Ask us the awkward question. If a claim on this page cannot be demonstrated in a demonstration, it should not be on the page — and we would rather be told than quietly correct it later.
Book a walkthrough and test it with us