Building software for law firms: security, confidentiality and integration

Building software for a law firm is not technically harder than building software for other sectors. What differs is that a number of decisions which are ordinarily matters of preference become matters of obligation.

Access control, audit logging and data handling are good practice everywhere. In a law firm they are regulatory requirements, and getting them wrong is a conduct issue rather than a defect. This article covers what that means in practice for anyone specifying or commissioning a legal software project.

Confidentiality shapes the architecture, not the feature list

Paragraph 6.3 of the SRA Code of Conduct requires solicitors to keep the affairs of current and former clients confidential unless disclosure is required or permitted by law, or the client consents. That single obligation has substantial architectural consequences.

It means access control cannot be an afterthought layered onto a working system. Permissions have to be designed at matter level from the outset, because a person entitled to see one matter for a client may have no entitlement to see another. Where information barriers exist between teams, the system has to enforce them rather than rely on people observing them.

It also means the principle of least privilege applies more strictly than in most commercial software. A paralegal should not have access to every client file by default. Access should follow matter involvement, and it should be removed when involvement ends. Leavers should be deprovisioned the same day, which means the system needs to support that cleanly rather than requiring a manual sweep.

These are not difficult things to build. They are difficult things to retrofit, which is why they belong in the initial design rather than a later phase.

Audit trails have to stand up to scrutiny

Most systems log activity. Legal systems need audit trails that can be produced as evidence.

The practical difference is completeness and immutability. It should be possible to establish who accessed a document, when, from where, and what they did with it, and to demonstrate that the record has not been altered. If a question arises about whether confidential information was accessed improperly, an incomplete log is worse than useless.

The SRA Accounts Rules impose related requirements where client money is involved, and firms are expected to maintain accurate, secure records with robust backup and audit trails. Any system touching that data inherits the obligation.

Build audit logging in from the start. It is straightforward at design stage and awkward to add later without gaps in the historic record.

Integration with practice management systems

This is usually the hardest part of a legal software project, and the part most often underestimated.

Most firms of any size run an established practice management system and have no intention of replacing it. New software has to work with what is there. The difficulty is that these systems vary enormously in how accessible their data is. Some offer well documented APIs. Some offer a database you may read but not write to. Some have been customised so heavily over the years that the vendor's documentation no longer describes what the firm is actually running.

The practical approach is to establish integration feasibility before committing to the wider project rather than assuming it. We would rather spend time early confirming exactly what can be read, what can be written, and how reliably, than discover a constraint after the design is fixed.

Where direct integration is genuinely not possible, there are usually workable alternatives: scheduled synchronisation, an intermediate data layer, or a defined manual step at a point where it costs little time. What does not work is designing as though integration exists and resolving it later.

Data residency and multi jurisdiction requirements

Firms operating across jurisdictions face requirements that single jurisdiction firms do not. Some client data may not be permitted to leave a particular territory. Some clients impose their own conditions on where their information is held and who may access it.

This affects hosting architecture and therefore needs establishing early. Retrofitting geographic data separation into a system designed without it is expensive and disruptive.

Where a firm has clients with specific data handling conditions, it is worth surfacing those at discovery. They are usually accommodated easily if known in advance.

Working with the firm's IT and security functions

Firms of any size have established security standards, and increasingly a penetration testing regime and defined infrastructure requirements. We expect our work to be reviewed by the firm's own security function or an external tester, and we plan for it.

In our experience this goes well when the security team is involved early rather than presented with a finished system to approve. Requirements that are trivial to accommodate at design stage can be genuinely expensive to address after build. It is worth introducing the developer to the security lead at the start of a project rather than at the end.

The same applies to identity and authentication. Most firms already have an identity system and would prefer not to create another set of credentials. Integrating with what exists is usually straightforward if it is known from the outset.

Why we build on .NET

We build in .NET, which suits legal work for several reasons. It has a strong security track record and a mature ecosystem of well maintained libraries. Most law firms are already invested in Microsoft infrastructure, so authentication, hosting and integration tend to be simpler. And it is an enterprise platform with long term support commitments, which matters for systems expected to run for a decade.

It also means the pool of developers who can maintain the system in future is large. Building on something unusual creates a dependency on whoever built it, which is a risk no firm should accept for a system it relies on.

Planning a legal software project?

We build secure systems, portals and bespoke software for law firms, including several international practices among our largest clients. If you are scoping a project and want a view on feasibility, integration or approach, we are happy to have that conversation before anything is committed.

Get in touch at hello@16i.co.uk or call +44 (0)1242 654 000.