HIPAA Compliance Checklist for Web Analytics

If your website touches patients, members, or health plan beneficiaries in any way (a symptom checker, a patient portal, a “find a doctor” search, even a simple appointment request form), your analytics setup is closer to a HIPAA problem than most teams realize. Session replay tools, event trackers, and even plain pageview analytics were built for e-commerce, not healthcare, and they default to capturing exactly the kind of detail HIPAA cares about.

This isn’t about whether you’re a “covered entity.” It’s about whether the data your analytics tool collects can identify a specific person and their health information. That’s a lower bar than most teams expect. It’s usually crossed by accident, through an autocomplete field, a URL parameter, or a form label, not by anyone intentionally sending patient data to a third party.

This guide covers three things: the 18 identifiers that make data PHI in the first place and where they typically leak into analytics; what a Business Associate Agreement (BAA) does and doesn’t cover, and what to check before you sign one; and a checklist you can use to audit your current analytics setup or evaluate a new vendor.

The 18 HIPAA identifiers and where they hide in analytics data

HIPAA’s Safe Harbor method (45 CFR § 164.514(b)(2)) lists 18 categories of identifiers that, combined with health information, turn ordinary data into Protected Health Information. Most explanations of this list stop at “here’s what PHI is.” The more useful question for a website owner is: which of these does my analytics tool actually capture, and how?

#	Identifier	How it typically leaks into analytics
1	Names	Typed into contact forms, appointment forms, or chat widgets and captured by session replay if the field isn’t masked.
2	Geographic subdivisions smaller than a state	Shipping/billing address fields, zip code fields, or “find a location near me” tools that pass an address as an event property.
3	Dates related to an individual (birth, admission, discharge, death), except year	Date-of-birth pickers on registration forms; appointment date/time captured as a custom event property.
4	Telephone numbers	Phone fields in contact/appointment forms, often auto-filled by browser autofill and picked up by unmasked session replay.
5	Fax numbers	Legacy referral or intake forms that still include a fax field.
6	Email addresses	Login forms, newsletter signups, and “email my results” buttons, frequently sent as event properties for marketing attribution.
7	Social Security numbers	Insurance verification or billing forms; rare but catastrophic if captured, since SSNs are almost never meant to be logged anywhere.
8	Medical record numbers	Passed in a URL path or query string (/patient/MRN12345) or embedded in a data-layer object pushed to analytics.
9	Health plan beneficiary numbers	Insurance/member ID fields on eligibility-check or billing pages.
10	Account numbers	Patient portal account numbers displayed on-screen and swept up by unmasked session replay.
11	Certificate/license numbers	Provider license numbers on “verify your provider” pages: lower risk, but still on the list.
12	Vehicle identifiers, including license plates	Rare for most healthcare sites; relevant for valet/parking or transport-service integrations.
13	Device identifiers and serial numbers	Connected-device or DME (durable medical equipment) portals that display a device serial number in the UI.
14	Web URLs	The URL of the page itself, if the path or query string encodes patient-specific information (see #8).
15	IP addresses	Collected by default by almost every analytics platform, usually without anyone realizing it needs to be anonymized or hashed.
16	Biometric identifiers	Voiceprint or fingerprint data from patient authentication flows: outside most web analytics, but relevant for health apps.
17	Full-face photographs and comparable images	Profile photo uploads, ID verification flows, or telehealth video thumbnails captured in a screenshot-based analytics tool.
18	Any other unique identifying number, characteristic, or code	The most overlooked one: session/device cookies, persistent visitor IDs, or internal user IDs that can be tied back to a specific patient record.

Two patterns show up over and over when this goes wrong in practice:

• Session replay is the biggest surface area. It doesn’t just log structured fields. It records the DOM, which means it can capture text the developer never intended to send anywhere: autofilled values, tooltips, error messages that echo back what a user typed (“No results found for John Smith”).
• URLs and custom events are the second-biggest. Teams mask form fields diligently but forget that the URL itself or a well-meaning custom event (patient_search, appointment_booked, with a name or MRN as a property) carries the same identifiers right past the masking.

Identifier #18 deserves a specific callout because it’s the one teams reason past most often: “we don’t collect names, so we’re fine.” A persistent device or session identifier that can be linked back to a specific person, even indirectly, even by someone else with access to the health record, is itself an identifier under Safe Harbor. This is exactly the kind of judgment call a BAA and a documented deployment configuration exist to resolve.

What a Business Associate Agreement actually covers

A BAA is often treated as a simple checkbox (“do they have one, yes or no”), but the content of the agreement matters more than its existence. Two vendors can both “offer a BAA” and mean very different things by it.

What a BAA is for. Under HIPAA, if a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity, that vendor is a “business associate” and the relationship must be governed by a BAA. The agreement establishes the vendor’s obligations: safeguards for any PHI it handles, breach notification timelines, restrictions on how the data can be used, and what happens to the data on request or at termination.

Who actually needs one. You need a BAA with an analytics vendor if there’s a realistic chance PHI will reach that vendor’s systems. Given the leak points above, that’s most healthcare websites with any form of patient interaction, not just portals that were designed to hold medical records. You generally don’t need one for a marketing site with no patient-specific forms, logins, or portals, but “we don’t think we send PHI” is a weaker position than “we’ve configured the tool so PHI can’t be sent, and verified it.”

What to look for before signing. A handful of questions separate a BAA that actually protects you from one that’s a formality:

• Does it match what the tool actually does, or is it boilerplate? A generic BAA template that doesn’t reference the specific product (session replay, event tracking, etc.) is a signal the vendor hasn’t thought through where PHI could enter their system.
• What’s the deletion timeline if PHI is inadvertently received? Look for a specific number of hours or days, not “promptly” or “as soon as practicable.”
• Does it say the vendor won’t use PHI for anything beyond the service? No analytics-on-your-analytics, no model training, no secondary use. This should be explicit, not implied.
• Are subcontractor obligations flowed down? If the vendor uses cloud infrastructure or sub-processors, their BAA obligations need to legally bind those subcontractors too (45 CFR 164.502(e)(1)(ii)).
• What’s the breach notification window? HIPAA sets an outer bound of 60 days (45 CFR 164.410); a vendor’s BAA shouldn’t just restate the legal maximum as their standard. Faster is better, and “without unreasonable delay” language in addition to the outer bound is a good sign.
• Does the BAA change the vendor’s default behavior, or just describe a hypothetical? The strongest signal is a vendor that turns on stricter defaults (e.g., full text redaction in session replay) specifically for BAA customers, rather than a BAA that just describes liability without changing the product.
• Does signing the BAA imply you can now use the tool as a PHI repository? It shouldn’t. A BAA exists to cover inadvertent transmission, not to authorize treating an analytics tool as a place to intentionally store patient data. If a vendor’s BAA reads that way, that’s a red flag about how seriously they’ve thought about data minimization.

Air360’s own Business Associate Agreement is built around this last point: it exists to govern the parties’ obligations if PHI is inadvertently transmitted, not to authorize using Air360 as a repository for patient data.

Vendor checklist: what to verify, and what Air360 does

Use this to audit your current analytics setup, or to evaluate a new vendor. Each row is something you should be able to confirm concretely, not take on faith.

Check	What to verify with any vendor	What Air360 does
BAA availability	Vendor offers a BAA specific to the product you’re using, not a generic template.	BAA available for eligible healthcare customers, covering Air360’s behavioral analytics and session replay service.
Text masking in session replay	User-entered text is masked by default, not opt-in.	Masks user-entered text in input fields by default for all customers; BAA customers get full-page text obfuscation (not just form fields) enabled by default.
Element/page exclusion controls	You can exclude specific page elements (patient portals, billing forms, medical record views) from capture entirely.	Configurable exclusion controls for sensitive page elements, custom events, and metadata.
Data minimization by default	The tool’s default configuration avoids collecting sensitive data, rather than relying entirely on the customer to lock it down.	Built on a data-minimization principle: designed to operate without collecting PHI even before customer-specific configuration.
IP address handling	IP addresses are anonymized, hashed, or not retained in identifiable form.	Used only to infer country, and not stored on Air360’s servers.
Data hosting location and security certifications	Know where data is processed and stored, and what certifications the infrastructure carries.	Customer data is processed and stored in datacenters covered by ISO 27001/27017/27018, SOC 1/2/3, and PCI DSS. (HIPAA itself does not require US-based hosting; it requires appropriate safeguards and a BAA. Confirm this matches your own organization’s policy.)
Encryption	Data is encrypted in transit and at rest.	State-of-the-art encryption used for data in transit and at rest across all products.
Access controls	Vendor enforces MFA and access logging on their own systems.	MFA required for all users accessing the Air360 application.
Third-party audits	Vendor undergoes independent security review, not just self-attestation.	Regular third-party security audits, including penetration testing and vulnerability scans, ahead of major releases.
Breach/incident reporting	Contractual commitment to a specific notification timeline, not just “as required by law.”	Reporting obligations defined in the BAA, with a 60-day outer bound per 45 CFR 164.410.
Deletion on request	Vendor commits to deleting inadvertently received PHI within a defined window.	Deletion within 24 hours of a customer request, or without unreasonable delay upon discovery.
No secondary use of PHI	PHI isn’t used for the vendor’s own analytics, model training, or marketing.	Air360 does not use PHI for advertising, profiling, marketing, or model training.

A five-minute self-check

Before evaluating a vendor, it’s worth checking your own implementation first. Most PHI exposure comes from configuration, not from the analytics tool itself:

1. Open a session replay recording of a real user flow through your patient-facing pages and read it as if you were a stranger. Is there any readable name, email, phone number, or ID on screen?
2. Check the URLs your analytics tool is capturing. Do any contain a patient name, MRN, or account number in the path or query string?
3. Look at your custom event properties. Would any of them mean something specific about a real patient if someone outside your organization saw them?
4. Confirm password fields, medical record forms, and billing/insurance forms are explicitly excluded from capture, not just relying on generic input masking.
5. If you have a BAA on file, re-read your customer responsibilities section and confirm your current configuration actually satisfies what it lists.

If you’re evaluating Air360 for a healthcare deployment, our HIPAA Statement and HIPAA Deployment Guide walk through exactly how to configure session replay, events, and custom properties so PHI never reaches the platform in the first place.