Client Portals for Law and Accounting Firms: What to Include

Email is where client files go missing. A tax return sits in an inbox three people share, an attachment is forwarded to a personal account, and in March nobody can find the signed engagement letter. A client portal fixes that only when it is the easiest way for clients to send and receive things, and when the firm can explain exactly who was able to see what.

This is a specification checklist for firms that are choosing or commissioning a portal. Confidentiality, record-keeping and client-money duties vary by profession and jurisdiction, so use it to ask better questions and confirm the obligations themselves with your bar, institute or regulator.

Design the client portal around five things clients come to do

Portals fail when they are designed as a folder tree with a login. Clients do not come to browse. They come to do one of five things:

• send a document the firm asked for;
• collect a document the firm prepared;
• ask a question or answer one;
• see where their matter stands and what happens next;
• view or pay an invoice.

Build the first screen around what is outstanding: "We need three documents from you", "Your draft accounts are ready to review", "Invoice due on the 14th". If a client can finish the task from that screen on a phone, they will use the portal. If they have to hunt, they go back to email, and the firm runs two channels with the risks of both.

Document exchange that is safer than an attachment

The core of the portal is a document request: a named item on a checklist with a status (requested, received, accepted, sent back). It replaces the email that says "please send your bank statements" and the three reminders that follow, and it shows staff what is missing for each engagement at a glance.

Uploads are among the riskiest features of any web application, so specify them carefully. The OWASP File Upload Cheat Sheet is the reference to hold a build against. In short:

• accept only the file types the firm needs, checked on the server and not only by extension;
• set a size limit, and rename every file to a generated name on arrival;
• store files outside the web root or in private object storage, never in a publicly addressable folder;
• scan uploads for malware before staff can open them;
• serve every download through the application, after a permission check, with a link that expires.

Add version history, so that "final", "final v2" and "final signed" are one document with three versions, and encryption both in transit and at rest.

Messages and notifications that do not leak content

Messaging belongs inside the portal, threaded by matter or engagement, so the conversation is stored with the file and survives staff changes. The notification email should say only that something is waiting, with a link to sign in. No message text, no attachment, no document title that reveals what the matter is about.

On the staff side, internal notes must be a different kind of record from client messages, with a different color and a separate permission. The classic portal accident is a note meant for a colleague that the client can read. Every thread also needs an owner, so a question asked on Friday evening is not waiting on whoever happens to look.

Status and billing in the client's language

Internal workflow has twenty states. Clients need four to six, in plain words: "Waiting for your documents", "In preparation", "With you for review", "Filed". Map the internal states to these, and show the next action and who owes it.

For billing, show invoices with their status and a PDF, and take payment through a payment provider's hosted fields so card numbers never touch your server. Law firms should check one point before taking retainers or funds on account online. Many jurisdictions require client money to be kept apart from the firm's own, which affects which bank account the processor pays into and where its fees are debited. Ask your regulator or accountant how that has to work, then configure payments to match.

Permissions, two-factor login and the audit trail

These three decide whether the firm can stand behind the portal.

Permissions per matter, enforced on the server

Access should attach to the matter or engagement, not to the client company as a whole. A client's bookkeeper may see the year-end file but not the shareholder dispute. On the firm's side, only the team on that matter should reach it, which also gives you information barriers where your rules call for them. Every request for a record or file has to be checked on the server. Hiding a link is not access control: test it by signing in as one client and changing the ID in the address bar.

Two-factor login and account recovery

Offer an authenticator app and passkeys, and keep text-message codes as a fallback at most. NIST's digital identity guidelines treat codes sent over the phone network as a restricted method and favor phishing-resistant options. Make the second factor mandatory for staff. For clients, the weak point is usually recovery: decide how a locked-out client proves who they are, and make sure the answer is not "they email us and we reset it". Our article on securing the WordPress login explains the options.

An audit trail nobody can edit

Record sign-ins and failed attempts, every view, download and upload, permission changes and deletions, each with the user, time and IP address. Store the log so that staff, including administrators, cannot alter it, and make it exportable per matter. When a client asks who saw their file, the answer should take a minute.

Closing a matter and getting the data out

Decide at the start what happens at the end. When a matter closes, the client should be able to download their documents as a set, after which access becomes read-only and then expires. Deletion should follow a retention schedule that matches your professional obligations, and backups should follow it too, or deleted files quietly live on.

Tie staff sign-in to the firm's directory through single sign-on, so a person who leaves loses portal access the moment their account is disabled. And check that you can export every matter, with its documents, messages and log, in a format another system can read.

Built-in portal, WordPress or a custom application

Many practice management products for law firms and accountants ship with a portal. Test that first, because the documents and matters are already there.

	Portal in your practice software	Portal on WordPress	Custom web application
Fits when	It covers the five client tasks as it stands	You mainly share resources, forms and simple status	You need your own permission model, workflows or several systems joined up
Matter and document data	Already in place	Synced through an API or entered twice	Synced through an API, on your terms
Control over design and wording	Limited to the vendor's options	High	Full
Per-matter permissions and audit log	As the vendor built them	Need careful custom development	Designed for your structure
Who keeps it secure and updated	The vendor	You or your developer	You or your developer

WordPress is a reasonable base for a light portal, built on the same foundations as a membership site. Be careful with files: the media library is designed for public content, so sensitive documents need private storage and permission-checked downloads, which means custom work. Once you need per-matter access, an unalterable log and two-way sync with a practice system, a purpose-built application, for example in Laravel, is usually the cleaner route. Either way, much of the effort goes into the integration with your existing systems.

How to decide what to do next

Run the five tasks through the portal you already own, on a phone, as a client would. If it passes and the audit log answers "who saw this file", improve adoption before you build anything: send every document request through it and stop accepting attachments by email.

If it fails on tasks your clients do every week, write down which ones and what the firm's rules require, and take that list to a developer. A portal holds your most sensitive data, so it is not a project for a first-time builder. Our page on software for legal and professional services explains how we approach it.

Frequently asked questions

Is a client portal more secure than email?

It can be, because access requires a login, files stay in one controlled place and every action is logged. That advantage disappears if the portal has weak passwords, no second factor or sloppy permission checks.

How do we get clients to use the portal?

Make it the shortest path. Send requests with a direct link to the exact item, let clients photograph and upload documents from a phone, and do not require an app install. Then be consistent: if staff still accept attachments by email, clients will keep sending them.

Should two-factor login be mandatory for clients?

For staff, always. For clients, make it the default and keep the setup simple, with a passkey or authenticator app and printed recovery codes. Whether clients may opt out is a risk decision for the firm, and your regulator or insurer may have a view.

Where should portal data be hosted?

Ask your regulator and your larger clients whether they expect data to stay in a particular country or region, then choose hosting and backup locations to match. List every service that touches client data too, such as email delivery and malware scanning.