A law firm's client portal and confidentiality

A law firm client portal protects confidentiality through four mechanisms working together: per-matter access control that isolates each client's documents, encryption in transit and at rest, a complete audit trail of who viewed what and when, and hardened session handling. Email and shared drives cannot provide those guarantees, which is why firms handling privileged material outgrow them.

Key Takeaways

These are the controls we check first when a law firm asks us to review an existing portal or scope a new one: matter-level access control, encryption, audit logging and session hardening. Get them right and the portal becomes a trust asset; get one wrong and a single shared link can undo years of client confidence.

• Confidentiality is a property of the whole system, not a checkbox — access control, encryption, logging and sessions must all hold at once.
• Per-matter isolation is the core rule: a user authenticates once, then sees only the matters they are assigned to.
• Every view, download and permission change should land in an append-only audit log — that log is what you show when confidentiality is questioned.
• Email is the biggest leak path in most firms; the portal's first job is replacing it for documents, not adding features.
• A generic file-sharing tool can be acceptable for low-sensitivity material if you verify MFA, vendor terms and export options first.
• Budget for operations, not just the build: access reviews, restore tests and log checks are recurring work.
• Verify with hostile tests, not vendor promises: try to cross into another client's matter and confirm the attempt was logged.

Why is ordinary email not confidential enough for legal work?

Email fails the confidentiality test because you surrender control the moment you press send. An attachment can be forwarded freely, sits unencrypted in mailboxes and backups for years, and leaves no reliable record of who opened it — three failures a client portal is specifically designed to prevent.

A misdirected attachment is the classic leak: two clients with similar names, autocomplete picks the wrong one, and the document is gone. Email gives you no way to revoke a send, and copies persist in sent folders, phone caches and backups long after the matter closes. Professional conduct rules in most jurisdictions hold the firm responsible for exactly this kind of disclosure, and corporate clients increasingly audit how their legal documents are stored and shared.

When does a law firm actually need a client portal?

You need a law firm client portal when confidential documents change hands weekly, several people work each matter, and clients demand proof of who accessed what. You do not need one yet if a handful of files move monthly and a password-protected, expiring link covers the gap.

The signals are practical, not theoretical: litigation matters with hundreds of documents, corporate clients asking where their files live, hours lost reconstructing email threads, and staff turnover that scatters knowledge of which folder held what. If two of those sound familiar, the business case for a client portal is already there. If you are a solo practitioner moving a couple of files a month, do not build one yet — a well-run file share with multi-factor authentication and expiring links is the honest, simpler answer.

How does a portal keep one client's files separate from another's?

Isolation rests on role-based access control layered over matters, not over clients alone. A user authenticates once, the application re-checks their assignment on every request, documents are encrypted at rest in storage, and every read is written to an append-only audit trail.

Authentication proves who you are; authorisation decides what you may touch. Role-based access control (RBAC) maps roles — partner, associate, paralegal, client contact — onto matters, and the application re-checks that mapping on every request, not just at login. New matters start with default-deny: nobody sees a file until someone is explicitly assigned.

Files are encrypted in transit with TLS — Cloudflare's SSL/TLS documentation explains the modes in plain terms — and encrypted at rest, where database-level features such as PostgreSQL's encryption options protect metadata and audit rows. Every view, download and permission change is appended to the audit log: who, what, which matter, when, from where. Sessions expire on idle, multi-factor authentication (MFA) is enforced for staff and clients alike, and we have written more about structuring client access permissions this way.

How do you launch a portal without weakening confidentiality?

A safe rollout is sequenced so confidentiality is tested before any real client file moves. Classify what you hold first, stand up access control and logging before data, pilot with one friendly client, and keep email as a fallback only until the audit trail proves the portal works.

1. Classify what you hold. List document types — identity papers, contracts, evidence, drafts — who touches each, and where they live today. If anything is deleted from an old share, take a full backup first and keep it for your retention period.
2. Fix the foundation. Unique named accounts for every user, MFA enforced, and hosting in an account the firm owns. No shared logins — including "the intern one".
3. Structure matters before uploading. Create matters, map roles, and confirm a freshly created user sees nothing until assigned.
4. Switch on logging and backups first. An append-only audit log, plus a backup you have actually restored in a test.
5. Set the sharing policy. Expiring links only, no public URLs, an idle session timeout of 15–30 minutes, and every download logged.
6. Pilot with one matter and one friendly client. Check the log shows exactly what happened — and nothing more.
7. Migrate active matters in batches, most urgent first; a portal holding half the firm's files tends to be abandoned.
8. Retire the email habit deliberately. A written firm rule, then a quarterly review of accounts, permissions and restore tests.

Which settings decide whether your portal stays confidential?

Six settings do most of the work: enforced multi-factor authentication, matter-scoped permissions with default-deny, expiring share links, full audit logging, encrypted storage, and tested backups. Everything else — branding, dashboards, notifications — is cosmetic until these six hold. Check them quarterly, because a platform update or new integration can silently reset one.

Default-deny matters more than password rules: MFA blocks credential stuffing that password complexity never will. Set the idle timeout in the 15–30 minute range for a high-sensitivity application, make links expire within days rather than months, and ensure no administrator can edit or delete audit entries — an editable log is not evidence of anything.

How do you verify the portal actually enforces confidentiality?

Verification means hostile testing from a client account, not clicking around as an admin. Log in as a test client and try to reach another client's matter, open an expired link, then read the audit log to confirm your failed attempts were recorded with timestamps.

The classic portal bug is an insecure direct object reference (IDOR): a client changes /matters/1042 to /matters/1043 in the address bar and receives another client's file. Test for it deliberately with a real client account. Then confirm a download appears in the log within seconds, an expired link returns an error, a password reset cannot reach a departed employee's address, and a restore brings back a document deleted an hour earlier. Repeat this after every major update and at least quarterly.

What breaks first in a client portal, and how do you debug it?

The first failures are usually access, not hacks: a client locked out after a phone upgrade loses their MFA device, a renamed matter breaks a saved link, or a permission change gives an ex-employee's account another week of access. Debug outward from the audit log.

The log tells you whether the failure was authentication, authorisation or the application itself. A client locked out after changing phones needs their backup MFA codes, issued at enrolment and stored somewhere safer than the same phone. Large uploads timing out usually points at a server body-size limit, not the client's connection. And when a client says the notification never arrived, check spam and deliverability first — email, not the portal, is usually at fault.

What does a confidential portal cost to run day to day?

Running costs are driven by storage growth, backup retention, the hosting tier and — the biggest line — engineer or admin time. An off-the-shelf subscription trades money for control; a custom build inverts that trade. Both need recurring access reviews, restore tests and log checks.

Storage grows with every matter and backup retention multiplies it. Per-seat licensing punishes success, because every paralegal and client contact is a seat, and egress charges bite when clients repeatedly download large bundles. Confirm current figures in your vendor's own calculator rather than trusting a sales call. The cost firms most often underestimate is not hosting at all — it is the few hours a month someone senior must spend on reviews and tests.

Which confidentiality mistakes do firms make most often?

The damaging mistakes are almost always procedural: a shared login "just for the intern", a demo environment loaded with real case files, backups restored to an unsecured laptop, or an employee leaving without access being revoked that day. Each defeats technically sound software.

• Shared or generic logins — you cannot audit what you cannot attribute to a person.
• Copying production case files into demo or staging environments with weaker protection.
• No leaver process, so an ex-employee's account survives for weeks after their last day.
• An audit log nobody reads — misconfigurations persist for months when no one looks.
• A slow, clunky portal that staff quietly abandon, letting email and shadow copies return.

What does a portal rollout look like in practice?

A realistic rollout for a mid-size firm runs about six weeks: one week to classify documents and access, two to build and harden, one to pilot with a single client, two to migrate active matters — followed by quarterly reviews for as long as the firm holds the data.

Picture a fourteen-lawyer commercial firm: litigation bundles moving by email, two near-misses last year, and a multinational client now asking in writing how its documents are secured. Following the sequence above, the firm classifies its files, stands up a portal with per-matter access and full logging, and pilots with one client's due-diligence bundle. When that client later asks who viewed a draft and when, the answer takes two minutes in the audit log instead of an afternoon of apology. That is the shift that matters: confidentiality becomes something you can demonstrate, not something you assert. Our work for Moksha Legal Group shows what a legal-sector build looks like delivered.

Which option should your firm choose?

Choose by sensitivity and volume, not by feature lists. Email and shared drives suit low-sensitivity, low-volume exchange; a generic portal works for mid-sensitivity files if you verify the vendor's controls; privileged and voluminous material justifies a purpose-built portal where you control access, logging and hosting.

For low-sensitivity exchange, a reputable generic portal starts today and costs less to run. Privileged material changes the calculus: you want the access rules, the logs and the keys in hands you control — the honest dividing line in our comparison of custom software versus off-the-shelf.

In short: a law firm client portal earns confidentiality through per-matter access control, encryption in transit and at rest, an audit log someone actually reads, and sessions that expire. Classify your files, switch on logging before the first upload, test like a hostile client, and only then retire the email habit.

People also search for

• How much does it cost to build and run a client portal?
• What access permissions should client portal users have?
• Should a law firm buy off-the-shelf software or build a custom portal?
• Where should a law firm host confidential client files?
• How do other organisations run member and client portals?
• How do you keep clients secure when they have no technical contact?

If you would like a confidential second opinion on an existing portal — or a new one built properly from the start — our team can help you scope, build and run it in accounts you own. Our software development team builds portals and internal systems for professional firms, and you can contact us for a review of what you have today.