HIPAA-Compliant Analytics: What to Actually Look For

Every vendor page in this category says the same two words: HIPAA compliant. Some say HIPAA certified, which is impressive, because no such certification exists.

If you're evaluating analytics tools for data that includes PHI, the marketing pages won't answer the questions that matter. This post will. What HIPAA actually requires of an analytics stack, what "certified" claims really mean, a checklist you can run any vendor through, and why the deployment model matters more than the feature list.

One framing note before anything else: HIPAA compliance is a property of your organization and your deployment, not of software. No tool is compliant in a box. The right question is never "is this tool HIPAA compliant?" It's "can I run a compliant deployment on this tool without a year of exceptions?"

What HIPAA actually requires of an analytics stack

HIPAA doesn't mention dashboards, warehouses, or BI. It regulates protected health information: who can hold it, what safeguards they owe, and what happens when it leaks. Map that onto an analytics stack and six requirements do the real work.

HIPAA requirement	What it means for analytics	What to verify
Business associate agreement	Every vendor that creates, receives, maintains, or transmits PHI on your behalf must sign a BAA	The vendor signs at the tier you're buying, and its subcontractors are bound by equivalent terms
Access controls (Security Rule)	Unique user identities, role-based access, and the ability to scope who sees which rows and columns	SSO/SAML, RBAC, row and column-level controls, automatic session handling
Audit controls (Security Rule)	Mechanisms that record and let you examine activity in systems containing ePHI	Per-user, per-query logs you can actually export and hand to an auditor
Encryption at rest and in transit	Technically "addressable" today; treat it as mandatory	TLS on every connection, encrypted storage, a real key management story
Minimum necessary (Privacy Rule)	Users, and any AI feature, should see the least PHI needed for the task	Column masking, row filters, scoped datasets; policy documents don't count
Breach notification	Your vendor's clock feeds your clock	A concrete notification window written into the BAA

Two of these deserve a closer look, because they're where analytics vendors most often fall short.

Audit controls. The Security Rule requires that you can record and examine activity in systems that contain ePHI. For analytics, that means answering "who queried what, when, and what came back" for every user and every query. Most analytics products log for their own debugging, not for your compliance. If you can't export per-user activity, your auditor will find that gap before your vendor does.

Encryption. Here's a nuance most compliance pages skip: encryption under the current Security Rule is an "addressable" specification, not a required one. You can technically document why an alternative is reasonable. Don't. Unencrypted PHI is indefensible after a breach, and HHS has proposed Security Rule updates that would remove the addressable designation and make encryption at rest and in transit flatly mandatory. The final rule hasn't landed as of mid-2026, but the direction is not subtle. Evaluate vendors as if it already passed.

The "HIPAA certified" myth

There is no HIPAA certification. HHS does not issue one, endorse one, or recognize one, and says so directly. This applies to every vendor, including us.

So what do vendors mean when they claim it? Usually one of three things, in descending order of substance:

1. A third-party HIPAA assessment. An auditor evaluated the vendor's controls against HIPAA requirements, often folded into a SOC 2 Type II audit. Piwik PRO's "HIPAA certification" is this, and to their credit they explain exactly what the assessment was. The audit is real and genuinely useful evidence. Calling it a certification is marketing.
2. HITRUST certification. HITRUST CSF is a real, rigorous third-party certification whose controls map to HIPAA. It's the closest thing to "certified" that exists in healthcare. It is still not a government HIPAA certification, and plenty of compliant deployments run on vendors without it.
3. Self-attestation. A page that says "we are HIPAA compliant" with no BAA terms, no audit report, and no architecture detail. Treat this as decoration.

The practical takeaway: skip the badge, request two documents. The BAA they'll actually sign at your tier, and the SOC 2 Type II (or HITRUST) report behind their claims. A vendor that hesitates on either has answered your question.

"HIPAA-compliant analytics" means four different products

One more source of confusion: the phrase covers at least four different categories, and the vendors you'll find in a search are mostly not competing with each other.

Category	What it does	Representative vendors	Honest take
Web analytics	Tracks website visitors, campaigns, conversions	Piwik PRO	Strong GA replacement for healthcare marketing; signs BAAs, hosts on covered infrastructure. It analyzes web traffic, not your business data
Product analytics	Tracks in-app user behavior, funnels, retention	PostHog	Excellent product suite; signs BAAs on paid cloud add-on tiers, and an open-source deployment exists for small volumes. Built for event streams, not BI
Marketing data pipelines	Aggregates ad and campaign data into reports	Improvado	Deep marketing connector catalog with SOC 2 Type II and BAAs. Scoped to marketing attribution
BI / data platform	Centralizes operational data (EHR exports, claims, billing, CRM) for reporting and AI analysis	Definite, plus assembled stacks	This is the category the rest of this post is about

If you need to replace Google Analytics on a hospital website (Google won't sign a BAA for GA, full stop), Piwik PRO is a reasonable answer and we are not. If you need dashboards, metrics, and an AI analyst over patient, claims, and operations data, web analytics tools were never the question.

Count your business associates

Here's the evaluation angle almost nobody runs, and the one that decides how painful your compliance program is: count the vendors that touch PHI.

A conventional analytics stack for a healthcare company looks like this: an ETL vendor moves data out of your EHR exports and billing systems, a cloud warehouse stores it, a BI tool queries it, and increasingly an AI assistant sits on top. That's four separate business associates. Four BAAs to negotiate, four subprocessor lists to review, four breach surfaces, four vendors in your annual risk analysis. And the chain has to be unbroken: if your BI tool's AI feature sends prompts to a model provider, that provider needs equivalent terms too. We walked through how that chain works (and where it usually breaks) in HIPAA-compliant AI tools.

Every tool you consolidate removes a business associate. An all-in-one platform takes the ETL, storage, BI, and AI layers down to one BAA. A self-hosted deployment takes it further: down to zero new ones.

The evaluation checklist

Run any analytics vendor through these ten questions. The order matters; the first few disqualify fastest.

1. Will you sign a BAA at the tier I'm buying? Plenty of vendors sign BAAs only on enterprise or add-on tiers. PostHog, for example, is upfront that BAAs come with its paid platform add-ons, not the base plan. Know which tier you're actually pricing.
2. Where does PHI physically live and get processed? Their cloud, or yours? This single answer sets the size of your vendor review.
3. Can I export per-user, per-query audit logs? Not "we have logging." Exportable, reviewable, attributable activity records.
4. What are the access controls? SSO/SAML, role-based access, and row and column-level scoping. If everyone with a login can query every column, minimum necessary is fiction.
5. Is everything encrypted at rest and in transit, and who holds the keys?
6. Which subcontractors touch the data? Ask for the subprocessor list. Every name on it extends your BAA chain.
7. If there's an AI feature, where does the model run, and is it inside BAA scope? Modern stacks quietly leak here. A compliant BI tool with an AI assistant calling a consumer model API is not a compliant deployment. The clean patterns are covered in how to run a HIPAA-compliant LLM.
8. Can you actually delete PHI on request? Retention policy, deletion SLA, and what happens to backups.
9. What's the breach notification window in the BAA? Your regulatory clock starts ticking on discovery. Their contractual delay is your risk.
10. What third-party attestation backs all of the above? SOC 2 Type II at minimum. Read the report, not the badge.

A vendor that answers all ten crisply is rare. That's the point of asking.

Why self-hosted deployment simplifies PHI custody

Most of the checklist above exists because your PHI is sitting on someone else's infrastructure. Change that one variable and the problem collapses.

When the analytics platform deploys into your own cloud account (BYOC) or your own data center, PHI never leaves the compliance boundary you've already built, documented, and audited. The consequences stack up fast:

• No new business associate for the data plane. The vendor never holds your PHI, so there's nothing to disclose to them. Your existing cloud provider BAA (AWS, Azure, GCP all sign them) keeps covering the infrastructure, same as it covers your EHR integrations today.
• Your security controls apply natively. Your network policies, your IAM, your KMS keys, your logging pipeline. No mapping exercise between the vendor's controls and yours.
• The AI question answers itself. An AI analyst running inside your environment, calling a model endpoint you already have under your cloud BAA (Bedrock, Azure OpenAI, or a covered Gemini service), adds zero new parties to the PHI path. Compare that with the consumer AI tools that should never see PHI at all.
• Vendor reviews get short. "PHI never reaches the vendor" is a one-line answer to most of the security questionnaire.

Self-hosting used to mean trading compliance simplicity for operational pain: a rack of open-source tools to assemble and babysit. That trade is gone. We laid out the full architecture in the self-hostable data stack; the short version is that a complete platform can now deploy into your environment from a single Helm chart.

Where Definite stands

The honest version, same as we give compliance officers on calls:

• Definite is not HIPAA certified, and neither is anything else. See above.
• Definite signs HIPAA BAAs, for both Definite Cloud and self-hosted deployments.
• Definite holds a SOC 2 Type II attestation. The report and security documentation are at trust.definite.app.
• The whole stack ships as one platform: connectors, a DuckDB and DuckLake lakehouse, BI, a semantic layer, and Fi, the AI analyst. One vendor in your PHI path instead of four, and sub-second dashboards as a side effect of the architecture.
• Private deployment puts all of it inside your environment via a single Helm chart. PHI never reaches Definite. Fi calls the model endpoint you choose, under the cloud BAA you already hold.
• Compliance stays shared. A BAA from us, or from anyone, covers the vendor's side. Your risk analysis, workforce training, and access policies remain yours. Any vendor who says otherwise is selling something.

FAQ

Is there such a thing as HIPAA-certified analytics software? No. HHS does not endorse or recognize any HIPAA certification, for analytics or any other software. When a vendor says "HIPAA certified," it usually means a third-party auditor assessed its HIPAA controls, often as part of a SOC 2 audit. The assessment can be real and useful. The certification is not a thing. Ask for the BAA and the audit report instead.

What makes an analytics platform HIPAA compliant? Nothing makes the software itself compliant; compliance attaches to your organization and your deployment. A workable deployment needs a signed BAA with every vendor that touches PHI, role-based access controls, exportable audit logs, encryption at rest and in transit, and minimum-necessary scoping of who (and what, including AI) can see which data. Your own policies, training, and risk analysis remain your job.

Does Google Analytics sign a BAA? No. Google states that Google Analytics customers should not send it PHI, and it does not offer a BAA for the product. That is why the healthcare web analytics category (Piwik PRO and others) exists, and why OCR's guidance on tracking technologies pushed hospital marketing teams off GA in the first place.

Do I need a BAA with every tool in my data stack? Yes. Every vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate. In a stitched-together stack that means separate BAAs with your ETL vendor, your warehouse, your BI tool, and your AI layer, plus subcontractor terms behind each one. One missing link makes every PHI-bearing request through that path an impermissible disclosure.

Is encryption actually required by HIPAA? Today encryption is an "addressable" specification, meaning you can document an alternative if it is reasonable. In practice, treat it as mandatory: unencrypted PHI is nearly impossible to defend after a breach, and HHS has proposed Security Rule updates that would remove the addressable designation and require encryption at rest and in transit outright.

Does Definite sign a HIPAA BAA? Yes, for both Definite Cloud and self-hosted deployments. Definite holds a SOC 2 Type II attestation (report at trust.definite.app), and the private deployment option runs the entire stack, including the Fi AI analyst, inside your own environment, so PHI never reaches Definite at all.

If you're evaluating analytics for PHI and want the short path, the private deployment page has the architecture, or grab a time here and I'll walk you through the whole stack running inside a single tenant, BAA and all.