Why a Google Analytics alternative for HIPAA-regulated websites starts with the BAA
If you are a covered entity or business associate running a patient-facing site with Google Analytics 4 tags, the first question is contractual, not technical. Google's Analytics Help page on HIPAA states that Google makes no representations that Google Analytics satisfies HIPAA requirements, does not offer Business Associate Agreements for the service, and that HIPAA-regulated customers must refrain from exposing Protected Health Information to Google. Without a BAA, GA4 cannot sit on any page that may reveal a person's patient status, such as appointment booking, condition-specific service pages, provider search results or logged-in portal screens. Pages that look like marketing content can still carry query strings, form fields or URL paths that expose it, so the review has to cover every tagged page, not only the clinical ones.
Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the vendor to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI and report security incidents to the covered entity. A reader evaluating self-hosted options should start by mapping where analytics data could carry PHI, then decide which pages keep any tracking at all. Self-hosted Matomo or PostHog running inside your own HIPAA environment is the realistic path, because the organization controls where events are stored, who can query them and which safeguards apply. That does not make the product compliant. No analytics product is "HIPAA certified": HHS states that no Security Rule standard requires certification, and the compliance outcome depends on how your team configures, hosts and operates the platform.
Before choosing a tool, confirm three points in writing with your privacy and security officers: which hostnames and paths the tracker will load on, whether any event payload, custom dimension or session recording could capture PHI, and who signs the contracts for any hosting provider that stores the data. Run the self-hosted instance in an environment already covered by your risk analysis, and treat the analytics database as ePHI from the start. Confirm current requirements against the HHS guidance and your legal counsel, since HHS proposed a major Security Rule revision in January 2025 and no final rule had been published as of October 2026.
What the HIPAA Security Rule requires of analytics data
The Security Rule reaches any electronic PHI a covered entity or business associate handles, and analytics tags on a patient-facing site can capture ePHI. The cards below separate what applies to a self-hosted stack you operate from what depends on your contracts and your own risk analysis.
Who the rule covers
The Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information they create, receive, maintain or transmit under 45 CFR 164.302. If your website collects appointment, condition or insurance details through analytics events, those events are ePHI. Confirm early whether your own organization is a covered entity or a business associate, because that decides which obligations apply to your analytics stack.
Eighteen standards and 36 specifications
Appendix A to Subpart C groups the Security Rule into administrative, physical and technical safeguards. It lists 18 standards with 36 implementation specifications, of which 14 are required and 22 are addressable. Addressable means you must assess whether the specification is reasonable for your environment and document the decision, not that you may skip it. For a self-hosted analytics platform, the administrative standards (risk analysis, workforce security and contingency planning) apply to the platform you run, not only to the application code.
Unique user identification and emergency access
The technical safeguards in 45 CFR 164.312 have 7 implementation specifications. Unique user identification and an emergency access procedure are required, so every administrator and analyst login to the analytics console must trace to a named person, and you need a documented way to reach the data during an outage. Shared admin accounts on a self-hosted Matomo or PostHog instance would fail this requirement outright. Check how the platform handles SSO, role separation and break-glass access in your own environment.
Automatic logoff and encryption
Automatic logoff and both encryption specifications (for data at rest and in transit) are addressable under 164.312. You decide whether each is reasonable and document the result, but encryption of the database, backups and the tracker's transport path is hard to justify skipping for patient-facing analytics. Ask whether your hosting layer provides disk encryption, TLS termination you control, and session timeouts in the analytics admin interface. Each choice belongs in your risk analysis with a stated reason.
Business associate contract terms
Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Self-hosting removes the need for a vendor to sign such a contract for the software itself, but a DeployOpen engagement, a managed host or a cloud provider holding the data may still need one. Confirm with counsel which parties must sign.
No certification, but enforceable rules
HHS states that no Security Rule standard requires certifying compliance, and that private certifications do not stop HHS from later finding a violation. The Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. A self-hosted analytics stack therefore needs documented evidence (risk analysis, configuration baselines, access reviews and incident records) that you can produce on request. Penalty ranges are adjusted each year, so confirm the current table before you size the risk.
What Google Analytics rules out on patient-facing sites
Google's Analytics Help page on HIPAA gives you three positions you cannot work around: Google makes no representation that Google Analytics satisfies HIPAA requirements, Google does not offer a Business Associate Agreement for the service, and HIPAA-regulated customers must refrain from exposing to Google any data that may be considered Protected Health Information. Without a BAA, sending PHI to Google Analytics is not a risk you can document away. Read together, these mean that any page where a visitor's health situation could be inferred from what the tag sends is out of bounds for the tag, whatever the consent banner says.
In practice the exposure is rarely a form field. It is the page itself and the URL. Condition pages, appointment booking steps, portal login screens and pages whose query strings carry a clinic, service line, referral or appointment identifier can each reveal a patient's situation through page titles, paths and parameters that the default tag collects. Pageview hits, event names and referrer data can carry the same signal. Ask your privacy officer and counsel to list every patient-facing page, every authenticated area and every marketing landing page that links to clinical services, then decide which of them can carry any analytics tag at all.
Confirm with counsel which of your pages are in scope before you choose a replacement, because a self-hosted tool only helps if it runs inside your own HIPAA environment and receives no data that Google would have received. Check whether a business associate contract with your hosting provider covers the analytics stack, and whether it is configured to strip or hash URL parameters before storage. The HIPAA Security Rule, not the marketing team, sets those boundaries, so the decision belongs with the covered entity and its counsel.
Which open-source analytics options fit a HIPAA environment
This table compares self-hosted Matomo, PostHog, Plausible and Umami against the requirements that matter when analytics could touch patient-facing pages inside a HIPAA environment. Read each row as a question to put to the vendor, your counsel and your own architecture, since a free license does not by itself establish HIPAA compliance. The main takeaway is that self-hosting keeps data in your environment, but you still own the safeguards, the business associate analysis and the evidence.
| Requirement | Self-hosted Matomo | Self-hosted PostHog |
|---|---|---|
| License for self-hosting | GPLv3, On-Premise Community edition is free with unlimited users and hits | MIT except the ee directory, which needs a PostHog license for premium features on self-hosted instances |
| Hosting stack | PHP with MySQL or MariaDB, behind Apache, Nginx, IIS or LiteSpeed; confirm the version pairing for your release | Docker Compose hobby deployment; Kubernetes deployments of the paid self-hosted product are no longer supported |
| Sizing driver | Pageviews per month; the requirements FAQ lists a single-server tier for up to 1 million pageviews a month | Event volume; the README says open-source deployments should scale to about 100k events a month |
| Vendor support for self-hosting | Forum support on the On-Premise edition; confirm any paid support options with Matomo | Self-hosted deployments are officially unsupported and PostHog offers no customer support for them |
| Session replay and heatmaps | Premium plugin under the InnoCraft EULA, not the GPL; adding it removes the consent exemption in France | Session replay is part of the product, but it runs under the same ee license split; confirm what is free in your build |
| Business associate agreement | Confirm with your counsel that no BAA is needed for software you host yourself, and that your cloud or data center provider will sign one | Confirm the same for your own deployment; PostHog Cloud is not the path if PHI-adjacent data must stay in your environment |
| Lighter alternatives | Plausible Community Edition (AGPLv3) and Umami (MIT) cover cookieless traffic dashboards with narrower reporting and fewer hosting dependencies | Plausible and Umami do not offer session replay or product analytics, so pair them with another tool if you need those |
How to deploy self-hosted analytics inside your HIPAA boundary
This sequence takes analytics from a scoped list of pages and events to a documented, monitored deployment that runs inside your covered environment and keeps protected health information out of the data it collects. Each step ends with a check you can record as evidence for your security and compliance reviews.
Scope pages, events and data fields
Your privacy or compliance lead and the web team list every page, form and event the analytics tool will record, then mark each one that sits in a patient, appointment, billing or authenticated portal flow. Those flagged pages are the ones that need the strictest rules in the steps that follow. The output is a signed-off inventory of tracked pages and events, with each entry labeled as public marketing content or as a page that may touch health information.
Set data minimization rules for tracking
Write a short standard that bans protected health information from URLs, page titles, form fields, search queries, custom dimensions and event names, and that tells developers to send generic page identifiers instead of content. Review the tag manager configuration and the site's JavaScript against this standard before go-live. The output is a written rule set and a review record showing that tracked fields were checked against it.
Choose the hosting environment inside your boundary
Decide which of your own cloud accounts, data centers or private networks will run the analytics server and database, and confirm that the environment is already within the scope of your HIPAA Security Rule risk analysis. Ask the hosting provider in writing whether it will sign a business associate agreement and how it will handle subcontractors that touch the data. The output is an approved hosting location and a signed or pending contract with the hosting provider.
Size servers from published pageview guidance
Estimate monthly pageviews for the tracked sites, then use Matomo's published requirements to choose a single-server or separate application and database layout, along with the minimum PHP and MySQL or MariaDB versions for the release you plan to run. Confirm the current stable version and requirements on the vendor's changelog and requirements pages before you install. The output is a sizing sheet tied to a named Matomo release and a documented architecture.
Configure encryption, access and logoff controls
Enforce HTTPS on the analytics endpoint and encrypt the database and backups at rest using your platform's key management. Create individual administrator and analyst accounts with no shared logins, enable an emergency access procedure, and set automatic logoff on the web interface. The output is a configuration baseline and a test record showing that encrypted transport, unique user identification and session timeouts are working.
Set retention and IP truncation
Configure the analytics tool to truncate the last byte of visitor IP addresses, set a retention period that matches your documented purpose, and disable features that would add identifiers or cross-reference patient-facing data. Record each setting in the configuration file or admin panel so it can be audited later. The output is a settings record that a reviewer can compare against your data minimization standard.
Document subcontractor and vendor terms
Map each organization that can access the analytics servers, backups or logs, including the hosting provider, managed database provider and any support partner, and confirm that each has the contract terms your business associate requirements call for. Keep the list with the risk analysis so it stays current when vendors change. The output is a subcontractor register and the executed or pending agreements behind it.
Test, monitor and back up the deployment
Run a tracking test on each flagged page to confirm that no health information reaches the analytics server, then review access logs and set alerts for failed logins and configuration changes. Schedule encrypted backups and perform a restore test to a separate environment. The output is a test report, a monitoring runbook and a restore record that your compliance reviewers can file with the deployment documentation.
Evidence HHS and auditors ask for under the Security Rule
HIPAA has no certification, so the evidence you hold is what proves your Security Rule safeguards work for analytics on a patient-facing site. The cards below cover the records that connect a self-hosted analytics platform to that rule, and the practical guide to map them against is NIST SP 800-66 Rev. 2.
Access logs for the analytics platform
Keep logs of who signs in to the analytics console, database and server, with user identifiers, times and actions. Under the technical safeguards, unique user identification and audit-style records are the first things an assessor asks to see. Confirm that logs from the web server, the database and the Matomo or PostHog application are shipped to storage your own administrators cannot silently alter, and that someone reviews them on a defined schedule.
Risk analysis covering analytics data
Document a risk analysis that names the analytics platform as a system that creates, receives, maintains or transmits electronic protected health information. Record what data the tracker collects, such as page paths, form fields, search terms and session identifiers, and whether any of it can identify a patient. Update the analysis when you add a plugin, change a tag or enable session recording, because each change alters the data in scope.
Configuration baselines and change records
Keep a written baseline of the analytics configuration, including tracked URLs, query parameters that are stripped, masking rules for form inputs, retention settings and which plugins are enabled. Store the baseline in version control and tie each change to an approved ticket. This is the evidence that the configuration you describe is the one running, and it shows what an auditor should expect to find on the live site.
Business associate contracts under 164.314
If a vendor, host or managed service provider can access ePHI, 45 CFR 164.314 requires a business associate contract that obliges that party to meet the Security Rule, flow the same terms to subcontractors and report security incidents. Self-hosting inside your own environment may remove the need for an analytics vendor contract, but your cloud provider or implementation partner may still need one. Ask counsel to confirm which parties hold ePHI in your setup.
Incident response and breach procedures
Write procedures for how a suspected exposure of analytics data is detected, contained, investigated and reported to the covered entity. Include how you would identify whether captured data contained PHI, who decides whether it is a breach of unsecured PHI, and how you preserve logs during the investigation. Test the procedure with a tabletop exercise so that the first drill is not during a real incident.
Official HHS enforcement and the no-certification point
HHS has stated that no Security Rule standard requires certifying compliance, so no certificate can stand in for your evidence. HHS enforces through complaints, compliance reviews and audits, and it can find a violation even when a private certification exists. Plan your evidence file as something you can hand to an investigator on request, and use NIST SP 800-66 Rev. 2 as a practical guide to map each record to the relevant standard. Confirm the current status of the proposed Security Rule revision with counsel before you plan around it.
Common questions about replacing Google Analytics for HIPAA
Does self-hosting Matomo make my website HIPAA compliant?
No. Self-hosting Matomo does not make a website, an organization or a vendor HIPAA compliant, and there is no HIPAA certification to obtain. What self-hosting changes is control: the analytics component runs in your own HIPAA environment, so you decide where tracking data is stored, who can access it and how it is logged and backed up. The Security Rule in 45 CFR Part 164 Subpart C still applies to the whole system, including the hosting, the tracker configuration, the pages that fire tracking and the people who run them. Google's Analytics Help page states that HIPAA-regulated customers must not send Protected Health Information to Google Analytics and that Google offers no Business Associate Agreement for it, so the first decision is whether any PHI can reach the analytics script at all. Your compliance lead should document that decision and the controls around it.
What does a self-hosted HIPAA analytics project cost, and what drives it?
Matomo's On-Premise Community edition is free to download under GPLv3, so the license is not the main cost. The spending falls into four components: infrastructure, configuration and hardening, documentation and evidence, and ongoing operations. Infrastructure is driven by monthly pageviews. Matomo's requirements FAQ sizes a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month, and recommends separate app and database servers for up to 10 million. Costs rise with the number of sites, plugins, retention periods and whether you need a separate environment for testing. Paid premium plugins, such as Matomo's Heatmap and Session Recording plugin, are licensed separately under a different EULA. Ask any implementation partner for a quote built from a written scope that lists these components separately.
What must my organization provide before the work starts?
Several inputs decide whether the project can be scoped at all. You need a current data flow map showing which pages, scripts and tag managers send events to analytics, and a clear statement of which pages are patient-facing or could carry PHI, such as appointment, symptom or billing pages. You also need the hosting environment inside your HIPAA boundary, including network segmentation, identity provider, logging and backup targets, and the business associate contracts you already hold with cloud and hosting providers. Your privacy and compliance leads should confirm the data retention period and who approves changes to tracking. Without these inputs, any quote is an estimate that will change once discovery starts. Ask the implementer to name what they need from you before they price the work.
Can my team run a HIPAA-scoped analytics deployment alone?
A capable platform team can install Matomo, but the question is whether it can carry the full set of obligations on its own. The Security Rule has 18 standards across administrative, physical and technical safeguards, and the business associate contract rules in 45 CFR 164.314 require the vendor and subcontractors to meet the same terms and report security incidents. If your team hosts the software, it must also handle risk analysis, access reviews, encryption decisions, patching and incident response for that system. Many teams keep these internal and buy only the specialist work, such as hardening, testing, evidence collection and upgrade support. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure, and prepares evidence for assessments, but it does not issue audit reports or certifications. Decide early which tasks stay with your staff.
What makes the timeline longer or shorter?
The timeline depends on drivers you can inspect before committing, not on a fixed duration. The biggest driver is how many sites, subdomains and tracking surfaces need to move, since each one needs its tag, consent and event logic checked. Another is whether historical data must be migrated, because importing history requires separate review of PHI exposure. Access model and identity integration also matter: single sign-on, role design and audit logging take longer in an environment with strict controls. Infrastructure approvals, change windows and the availability of your own staff for reviews often set the pace more than the software does. Ask for a timeline built from a written scope with named milestones, and ask which of these drivers the proposal assumes.
What are the HIPAA penalties I should be aware of?
The HIPAA civil money penalty table is adjusted for inflation, and 45 CFR 102.3 sets the current ranges. For penalties assessed on or after 28 January 2026, the range runs from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294 for identical violations. These figures show the scale of exposure, but they do not measure the cost of a single analytics leak, which also includes investigation, notification and remediation work. Penalties depend on culpability, the steps taken to correct the problem and the nature of the violation. Treat these numbers as context for why scope decisions matter, and have counsel confirm how they apply to your organization.
Can I import historical Google Analytics 4 data without exposing PHI?
You can import aggregated history, but the import needs a PHI review first. Matomo's Google Analytics Importer, a free plugin for Matomo On-Premise, brings over aggregated report data from a Google Analytics property rather than raw visits. That history was collected by Google under a setup your organization may not have approved for PHI, so confirm with counsel whether the existing property ever received sensitive page paths, query strings or user identifiers. Review reports for patient-identifying page titles, search terms and custom dimensions, and exclude or rename them before import. Also note that imported reports do not support the Visitor Log, segmentation or some funnels, so decide whether the history is needed at all. Keep a record of what was reviewed and what was excluded.
When does a retainer make sense after the HIPAA deployment?
A retainer makes sense when the analytics system needs ongoing work that your team cannot absorb without risk. Matomo releases new versions on its own schedule, and newer releases have different requirements, so upgrades, patching and dependency changes recur after launch. Continuous security testing, periodic access reviews, backup restore tests and updates to documentation also repeat. A retainer covers ongoing support, upgrades and continuous testing, while a fixed-scope project covers the initial build and evidence package. If your staff will own the system after handover, ask what runbooks, training and knowledge transfer the scope includes. Decide before the project starts whether support will be retained, and price it separately.
How the pending Security Rule revision could change the picture
The main regulatory uncertainty is the proposed revision of the HIPAA Security Rule. HHS published it on January 6, 2025 (90 FR 898), and it would tighten the technical expectations that apply to any system holding electronic protected health information. As of October 2026, no final rule had been published. The Unified Agenda entry for RIN 0945-AA22 projects final action for July 2027, but agency schedules move, so confirm the current status on the Federal Register proposed rule and the reginfo.gov entry before you set any date with your board or auditors.
The practical advice is to design to the rule that is in force today and to track the revision as a change request, not a reason to wait. Controls the current rule already expects, such as unique user identification for each administrator, encryption of ePHI in transit and at rest, audit logging and documented risk analysis, are the ones most likely to be tightened. For a self-hosted Matomo or PostHog deployment, that means keeping the analytics host inside your HIPAA boundary, writing down which fields can carry health context, and keeping the configuration, access list and backup records in a form you can update when the final text arrives. Ask any vendor or integrator how they would map a revised requirement to their change process.
HITRUST CSF is a voluntary, privately administered framework. Some organizations use it to organize their controls and to give partners structured evidence, but it is not a HIPAA certification. HHS states that no Security Rule standard requires certification, and an external HITRUST assessment does not prevent HHS from later finding a violation. Treat any HITRUST interest as a separate decision about assurance, and confirm with the assessor and your compliance lead which CSF version and assessment type fit your scope before committing to it.
How DeployOpen deploys analytics under a HIPAA constraint
DeployOpen plans, implements, hardens and documents self-hosted open-source analytics inside your own infrastructure, including the cloud accounts or data centers where HIPAA obligations already apply. We start from the question of whether any analytics data can reach a third party without a business associate agreement, and build the scope around the answer.
How we scope
- Each engagement starts with a written, fixed scope that names the sites, pages and events in question.
- We map which fields could carry protected health information, such as URLs, form values and user identifiers, and which must be excluded.
- The scope records which HIPAA safeguards the analytics stack touches and who on your side owns each one.
How we build
- We install Matomo or PostHog inside your own environment, with the database, backups and network paths under your control.
- We configure tracking so URLs, page titles and form fields are stripped or masked before any data is stored.
- We test the deployment for data leaving the environment, including tag managers and third-party scripts, and document the results.
How we hand over
- You receive architecture diagrams, configuration records, access lists and a data flow map for the analytics stack.
- Runbooks cover upgrades, backup and restore testing, and incident steps that align with your business associate contracts.
- We prepare the evidence your compliance team and independent assessors will ask for, without issuing any certification ourselves.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, configuration reviews when tracking changes, and periodic testing of the data boundary.
- Confirm with your legal and compliance team which agreements, such as a business associate contract, your environment requires.
