Access Control for Law Firms: Who Should See What, Enforced Where

Small firms usually operate on total internal visibility, for understandable reasons: the team is small, everyone is trusted, and restricting access creates friction that slows work.

The exposure grows quietly as the firm does. A contractor, a departing employee, a junior hired last month, a compromised password — each inherits the whole file room. Trust is not the issue; the issue is that trust is not a control, and the firm has no answer to "who could have seen this" beyond "everyone".

The most common implementation of roles is that the interface shows fewer options. This is a usability feature and nothing more.

The question that separates real controls from cosmetic ones is where the rule is enforced. If the application checks a role before rendering a page, then anything reaching the data another way — a direct API call, an exported report, an integration, a bug — bypasses it. If the database filters every row by firm and role, the rule holds regardless of the path, because there is only one place it can be evaluated.

For a firm holding privileged material, this distinction is the whole of the matter.

Access control in legal software has two separate jobs, and systems that conflate them get one wrong.

The tenant boundary separates your firm from every other firm on the platform. It must be absolute, enforced below the application, and never dependent on a query being written correctly. The internal boundary separates roles and matters within your firm. It is more nuanced, more frequently adjusted, and legitimately overridable by the right person for the right reason — with that override recorded.

A system with a strong internal permission model and a weak tenant boundary has solved the easier problem.

Least privilege is right in principle and often implemented so strictly that people route around it, which leaves the firm worse off than a permissive system that is actually used.

A workable version: default access to matters someone is assigned to; broad visibility for those who genuinely need it, such as a managing partner; money and client-level financial data restricted by role; and a documented way to grant more when the work requires it. The measure of a good scheme is that nobody needs to share a login.

External access is not a weaker version of internal access; it is a different model. A client should see specifically what the firm has chosen to share and nothing adjacent to it — not the folder around the document, not the other matters they are a party to, not metadata the firm did not intend to disclose.

The safe construction is explicit, per-item grants. Anything inherited by proximity will eventually disclose something nobody decided to disclose.

Access is usually granted carefully and removed carelessly. Departures are where firms are most exposed, because revocation depends on someone remembering, and the accounts of departed staff are the most common route into a small firm's data.

Two disciplines cover most of it: revoke on the last day rather than when someone gets to it, and keep a record of what that person could access, which is also what any subsequent investigation will ask for first.

Both boundaries are enforced in the database. Every firm-scoped table and every storage object is filtered by row-level security keyed on the caller's firm and role — so a request for another firm's matter, document or invoice returns nothing regardless of how it is constructed. There is no code path that widens it, because the check is not in the code.

Internally, an associate's dashboard and data are scoped to their own matters, tasks and clients; client-level financial data and firm money are gated by role; and matters opened by associates can be required to pass partner review before becoming active. Invitations carry the role, and seat limits are enforced at the point of invitation.

Client access is explicit and per item — a named client user is granted a specific folder, matter or document, never a share that leaks by proximity — and clients never count as billable seats. Grants, revocations and access events are written to the append-only audit ledger, which no role can amend, so "who could see this, and when" is answerable from the record rather than from memory.