The Compliance Surprise That Kills Client Portal Projects

The short answer: if a single client of yours might ever need a Business Associate Agreement for HIPAA, you have to narrow your options on day one. Retrofitting compliance after a contract requires it is the most expensive surprise in this category. As of mid-2026 only four client portals are concretely set up for HIPAA-compliant configurations, and most of the tools that dominate "best client portal" listicles are not among them.

This is the part of portal selection that almost nobody writes about, because it is not a feature you can demo.

The four terms you need before evaluating anything

Vendor pages use these words loosely. Used precisely, they mean the following.

PHI (protected health information) is any health-related data tied to an identifiable person. If you work for healthcare providers, clinics, insurers, or their vendors, assume you touch it. A marketing agency building a clinic's website can end up holding PHI in a contact form submission.

A BAA (Business Associate Agreement) is the contract HIPAA requires between a healthcare entity and any vendor that stores or processes its PHI. No BAA, no PHI on the platform - regardless of how good the vendor's security is. This is a legal requirement, not a best practice, and a vendor "being HIPAA compliant" without offering you a BAA is meaningless for your purposes.

SOC 2 is an independent audit of a vendor's security controls - how they run their systems. Type I says the controls existed at a point in time; Type II says they operated over a period, usually six to twelve months, which is the one enterprise clients actually ask for. Critically, a vendor's SOC 2 covers the vendor's operations. It says nothing about whether you can prove who accessed a specific client's records.

Data residency is a contractual or regulatory requirement that data be stored in a specific country or region. It is decided by your client's legal team, not by your preferences, and multi-tenant SaaS products generally have one fixed answer.

Why this catches good teams out

Portal selection usually runs on convenience. You compare interfaces, you check the price, you pick the one your clients will actually log into. All reasonable.

Then eighteen months later a client sends a security questionnaire, or a new customer turns out to be a healthcare provider, or your largest account gets acquired by someone with a procurement process.

At that point you have three options. Migrate every client to a compliant platform mid-relationship. Tell the client no. Or sign something you should not. The cost is not the platform difference - it is the migration, the disruption, and occasionally the contract.

Which platforms are actually configured for HIPAA

As of mid-2026, four client portals have documented HIPAA-compliant configurations.

And the ones that are not standard HIPAA configurations: HoneyBook, Dubsado, Plutio, Copilot, FuseBase, Bonsai and Agiled. That second list contains most of the tools that top general "best client portal" roundups. They are good products. They are just not the answer if you handle protected health information.

The rule that follows: if you treat PHI, restrict your shortlist to the four above and verify the BAA signing process directly with the vendor before sending any patient data. Not the marketing page. The actual signing process.

What compliance costs on the platforms that have it

Compliance almost always lives on a higher tier, which changes the economics of the whole decision.

Clinked Premium, with SOC 2 and enforced two-factor and role-based permissions, runs $383.20 a month billed annually. Moxo with SOC 2 Type II and private cloud starts at $99 a month and up, with its 2026 pricing page listing $200 a month as the entry point. SuiteDash is the outlier at $19 a month flat with documented HIPAA compliance included, which is why it appears in nearly every regulated-industry recommendation despite reviewers finding the interface dense.

So the choice for a regulated firm is often between a $19 tool with a steep learning curve and a $383 tool that is easier to use. Neither is wrong. But the $29 tool you liked in the demo is off the table entirely, and most comparison articles will not have told you that.

The three questions that matter more than the certification badge

A SOC 2 logo on a vendor page tells you less than people assume. Three things tell you more.

1. Can you get a signed BAA, and how fast? HIPAA availability and a signed BAA in your hands are different states. Ask the vendor to walk you through the process before you commit. If it involves a sales conversation and a legal review, factor in the weeks.

2. Where does the data physically live, and can you choose? For healthcare, financial services, and any client with data residency requirements, this is the question that ends evaluations. Multi-tenant SaaS on shared infrastructure has a fixed answer. Self-hosted has whatever answer you need.

3. Can you reconstruct who accessed what, and when? Certification proves a vendor has controls. It does not prove you can answer a client's question about their own data. The audit requirement in most regulated engagements is not "is your vendor certified," it is "show me what happened to my records." That is a different technical property, and it is the one most portals handle worst. A platform that logs application events is not the same as one that records, per action, which user accessed which record on whose authority.

The isolation question underneath all of it

Compliance frameworks are ultimately asking one thing: can one customer's data reach another customer? There are two ways to answer that.

Application-layer filtering means your code adds a tenant clause to every query. It works until someone writes the one query that forgets, and the failure is silent.

Storage-layer enforcement means the database refuses to return rows outside the requesting user's scope regardless of what the query asked for. In Postgres that is row-level security:

ALTER TABLE client_records ENABLE ROW LEVEL SECURITY;
ALTER TABLE client_records FORCE ROW LEVEL SECURITY;

CREATE POLICY client_scope ON client_records
  FOR SELECT
  USING (client_id = current_setting('app.client_id', true)::uuid);

The FORCE clause matters more than teams expect. Without it, the table owner bypasses the policy, which means your migration tooling and any admin connection silently see everything. And the client context has to come from a verified session token rather than a parameter the application supplies. Any value the caller controls is a value an attacker can influence.

Why this is the compliance question rather than a technical one: "we are careful about filtering" is a process claim. "The database cannot return it" is a control. Auditors and security questionnaires are asking for the second one, and most teams answer with the first.

What to do before you choose

Ask the hypothetical client question first. Not what your clients need now. Whether any client you would want in three years would need a BAA, a SOC 2 report, or data residency. If yes, that narrows the list before you look at a single interface.

Get the security questionnaire early. If you have any enterprise-adjacent clients, ask one of them for the questionnaire they would send. Answering it against your shortlist takes an afternoon and eliminates most of them.

Separate the certification from the capability. A vendor's SOC 2 covers the vendor. It does not cover whether you can produce an audit trail for one client's records on request.

Assume you will be asked to prove isolation. Not asked whether you have it. Asked to demonstrate it. Design for the demonstration.

The verification checklist to send vendors

Copy these five questions into an email before you sign anything. The answers, in writing, are worth more than any certification page.

1. Do you sign BAAs on the tier I am considering, and what is the actual process and timeline from request to signature?
2. Which data centres store my clients' data, and can I choose or change the region?
3. Can I export a per-client access log showing which user opened which record, and when? Ask for a sample export, not a yes.
4. Is two-factor authentication enforced for my clients' accounts, or only offered?
5. When I delete a client, where does the data persist - backups, logs, analytics - and for how long?

Question three is the one that ends the most evaluations. Most vendors answer questions one and two comfortably. Very few can produce the sample export.

The alternative to picking a compliant vendor is not needing one. Butterbase enforces client isolation in Postgres rather than in application code, records every agent and user action with actor, tenant and originating request, and runs on your own infrastructure where the engagement demands it. Compliance stops being a pricing tier and becomes a property of the system. Related reading: Do You Actually Need a Client Portal Yet?.

Frequently asked questions