What Makes Session Replay HIPAA Compliant: Masking, Consent, and BAA Requirements

A hipaa compliant session replay must satisfy three simultaneous requirements: (1) all protected health information visible in the recording is masked or excluded before storage, (2) user consent is collected in a manner consistent with both HIPAA authorization standards and applicable state privacy laws, and (3) the session replay vendor has executed a Business Associate Agreement that covers the specific data flows involved. Failing any one of these conditions means the recording likely constitutes an impermissible disclosure of PHI under the HIPAA Privacy Rule. This article, current as of July 2026, provides the definitive reference for healthcare organizations evaluating or operating session replay tools.

TL;DR

• Session replay on a healthcare website is not inherently illegal; it becomes a HIPAA violation when it captures, transmits, or stores PHI without proper safeguards.
• Input masking must suppress PHI at the point of capture (client-side or proxy-layer), not merely redact it after storage.
• A BAA does not make data sending legal; it makes a vendor accountable for safeguarding what it receives.
• Consent alone does not satisfy HIPAA; authorization and minimum necessary standards still apply to any PHI a session replay captures.
• HHS OCR's December 2022 guidance (updated 2024) treats IP address plus health-condition page visit as PHI when collected by a tracking technology on a covered entity's site.
• State laws (Washington MHMDA, California CCPA/CMIA, Connecticut, Texas) may impose stricter requirements than HIPAA for session recordings involving health data.

Definitions You Need Before Going Further

Session Replay

A session replay is a reconstructed recording of a user's interaction with a website or application. It typically captures DOM changes, mouse movements, scroll depth, clicks, form inputs, and page transitions. The recording is rendered as a video-like playback but is stored as structured event data.

Protected Health Information (PHI)

Under 45 CFR 160.103, PHI is individually identifiable health information transmitted or maintained in any form. On a website operated by a covered entity or business associate, PHI can appear in form fields (name, date of birth, insurance ID), URL parameters (appointment type, condition), page content (diagnosis pages, patient portal screens), and metadata (IP address combined with health-context browsing behavior).

Business Associate Agreement (BAA)

A BAA is a written contract required under 45 CFR 164.502(e) and 164.504(e) between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on its behalf. The BAA defines permitted uses, safeguards, breach notification duties, and subcontractor obligations.

Requirement 1: Input Masking and PHI Exclusion

Masking is the single most critical technical control. If PHI enters the session replay data stream, every downstream system (CDN, storage, analytics dashboard, vendor employee access) becomes a potential point of impermissible disclosure.

What Must Be Masked

• All form input fields by default (opt-in unmasking only for non-PHI fields you have explicitly reviewed)
• Free-text areas where patients may type symptoms, medications, or personal details
• URL parameters that encode condition names, provider specialties, or appointment types
• On-screen text rendered dynamically from patient records (portal screens, lab results, messages)
• IP addresses, device fingerprints, and any cookie values that constitute unique identifiers when combined with health context

When Masking Must Occur

Masking must happen before data leaves the user's browser or, at minimum, before it reaches persistent storage. A system that records raw PHI, transmits it to a vendor's servers, and then redacts it after the fact has already created an impermissible disclosure during transit and temporary storage. The minimum necessary standard under 45 CFR 164.502(b) requires that you limit PHI exposure to the least amount needed; post-hoc redaction does not satisfy this requirement because the vendor has already received more than necessary.

Many popular session replay tools were not designed with this constraint. As we detail in Is Hotjar HIPAA Compliant? Session Recording Risks That Could Cost Your Practice Millions, tools that default to capturing all page content and rely on manual CSS-class exclusions create unacceptable risk when any page change introduces new PHI-bearing elements. Similarly, our analysis of Is FullStory HIPAA Compliant? Session Replay Alternatives for Healthcare User Research explains how even sophisticated AI-driven redaction may not satisfy the "before transmission" timing requirement.

Requirement 2: Consent and Authorization

Consent for session replay in healthcare operates on two parallel legal tracks: HIPAA authorization and general privacy law consent. They are not interchangeable.

HIPAA Authorization vs. Privacy-Law Consent

• HIPAA authorization (45 CFR 164.508) is required for uses or disclosures of PHI not otherwise permitted by the Privacy Rule. If your session replay captures PHI and the recording is used for marketing analytics (not treatment, payment, or healthcare operations), a valid HIPAA authorization signed by the patient is required.
• State and federal privacy consent (CCPA opt-out rights, Washington MHMDA affirmative consent for health data, FTC Act Section 5 deception standards) may require a separate, clearly worded disclosure and opt-in before any health-related browsing data is collected by a third-party tool.

Practical Consent Implementation Steps

1. Deploy a consent management platform that can block session replay scripts until affirmative consent is received. See our comparison in 5 Best HIPAA-Compliant Consent Management Platforms: CMP Comparison for Healthcare Marketers.
2. Write consent language that specifically names "session recording" or "interaction recording" as a data practice. Generic "analytics cookies" language is insufficient under FTC enforcement precedent (see the BetterHelp and GoodRx consent-related findings).
3. Provide granular opt-out that disables session replay independently from other analytics.
4. Log consent signals with timestamps and version identifiers so you can demonstrate compliance during an OCR investigation or state AG inquiry.

A critical rule: consent does not override the masking requirement. Even if a user consents to session recording, the covered entity must still apply the minimum necessary standard and must still have a BAA in place with the vendor receiving the data.

Requirement 3: Business Associate Agreement

No covered entity or business associate may permit a session replay vendor to receive PHI without an executed BAA. This is a bright-line rule under 45 CFR 164.502(e).

What a Valid Session Replay BAA Must Cover

• Explicit identification of session replay data (including DOM snapshots, event streams, and metadata) as the information being handled
• Restrictions on vendor use of PHI for its own product improvement, model training, or aggregate benchmarking
• Subcontractor flow-down requirements (the vendor's hosting provider, CDN, and any AI processing service must also be bound)
• Breach notification timelines (60 days under HIPAA; shorter under many state laws)
• Return or destruction of PHI upon contract termination
• Specification of encryption standards for data in transit (TLS 1.2+) and at rest (AES-256 or equivalent)

Many session replay vendors will sign a BAA only on enterprise plans, and some will not sign one at all. As discussed in Is Hotjar HIPAA Compliant? Session Recording Risks That Could Cost Your Practice Millions, Hotjar does not offer a BAA and explicitly states in its documentation that it should not be used to collect sensitive health data. Confirm current terms with any vendor before deployment.

A BAA does not make data sending legal; it makes a vendor accountable for it. You still must ensure that PHI exposure is minimized, that consent is properly obtained, and that the recording architecture satisfies the Security Rule's technical safeguard requirements (access controls, audit logs, transmission security).

Architecture Patterns: Compliant vs. Non-Compliant

Non-Compliant Pattern

• Client-side JavaScript captures full DOM including form values and health-context URLs
• Data transmitted directly to vendor servers without BAA
• No consent gate; script loads on every page for every visitor
• Masking relies on manual developer tagging of sensitive CSS classes (prone to drift)

Compliant Pattern

• Session replay script loads only after verified consent
• All input fields masked by default; only explicitly reviewed non-PHI fields are unmasked
• URL parameters stripped or generalized before capture
• Data routed through a first-party server-side proxy that enforces PHI filtering before forwarding to vendor
• Vendor has signed BAA covering session replay data specifically
• Recordings stored in SOC 2 Type II and HIPAA-compliant infrastructure with encryption, access controls, and audit trails
• Retention policy automatically deletes recordings after defined period (30 to 90 days typical)

Common Mistakes

1. Assuming "no forms on this page" means no PHI risk

HHS OCR's 2022 guidance (updated March 2024) establishes that an IP address combined with a visit to a health-condition-specific page constitutes PHI when the site is operated by a covered entity. A session replay of someone browsing your "Diabetes Management Program" page captures both the page context and identifying metadata. That is PHI.

2. Relying on the vendor's default masking settings

Default configurations vary by vendor and version. A tool may mask standard HTML input elements but miss custom components, Shadow DOM elements, iframes, or dynamically injected content. You must audit masking behavior on every page where the script runs, and re-audit after site updates. Our review of Is Hotjar HIPAA Compliant? Session Recording Risks for Healthcare Websites documents several scenarios where default settings leave PHI exposed.

3. Treating consent as a one-time checkbox

Consent must be re-obtained when material data practices change (e.g., switching vendors, adding new data types to recordings). Under Washington MHMDA and certain state laws, consent for health data collection expires and must be periodically renewed.

4. Believing a BAA alone is sufficient

OCR has repeatedly stated that a BAA is necessary but not sufficient. The covered entity retains responsibility for conducting a risk assessment of the session replay implementation, verifying the vendor's safeguards, and ensuring minimum necessary compliance.

5. Recording authenticated patient portal sessions

Session replay inside a patient portal (post-login) almost certainly captures clinical PHI: appointment details, lab results, medication lists, provider messages. The risk profile is dramatically higher than recording unauthenticated marketing pages. Most compliance officers recommend excluding authenticated sessions entirely from replay capture unless the use case is strictly for treatment-related UX improvement under healthcare operations, with full HIPAA-compliant architecture in place.

6. Ignoring the FTC Health Breach Notification Rule

If your organization is not a HIPAA-covered entity but handles health data (health apps, wellness platforms, condition-specific content sites), the FTC Health Breach Notification Rule (16 CFR Part 318, expanded 2024) still applies. Unauthorized disclosure of health information through session replay to a third party without consent constitutes a breach requiring notification. The GoodRx and BetterHelp enforcement actions established this precedent clearly.

State Law Overlay

HIPAA sets the federal floor, but several states impose additional requirements relevant to session replay in healthcare contexts.

Key State Requirements

• Washington My Health My Data Act (MHMDA): Requires affirmative opt-in consent before collecting, sharing, or selling "consumer health data," defined broadly to include browsing behavior on health-related pages. Applies to non-covered entities as well.
• California CCPA/CPRA and CMIA: Sensitive health information triggers opt-in consent requirements and limits on service-provider use. Medical information under CMIA has separate authorization requirements.
• Connecticut Data Privacy Act: Health data classified as sensitive; requires consent before processing.
• Texas Data Privacy and Security Act: Sensitive data (including health) requires opt-in; enforcement by state AG with significant penalties.

A session replay tool operating across multiple states must satisfy the strictest applicable standard for each user based on their location.

How BAA Requirements Apply to Adjacent Tools

Session replay does not exist in isolation. Healthcare organizations often deploy it alongside other tracking technologies that share similar compliance requirements. The same BAA, masking, and consent framework applies to video conferencing tools used for telehealth (see Is Zoom HIPAA Compliant? BAA Requirements and Telehealth Setup for 2026), conversion pixels, analytics platforms, and form-tracking scripts. Consistency across your entire tracking stack is essential; a compliant session replay tool deployed alongside a non-compliant Meta pixel still results in a violation.

Choosing a HIPAA-Compliant Session Replay Solution

Curve provides session replay, analytics, and conversion tracking purpose-built for healthcare marketers. The platform masks PHI at the point of capture, offers a signed BAA covering all data flows (including session recordings), routes conversion data server-side to Google, Meta, and Microsoft without exposing PHI, and stores recordings in HIPAA-compliant infrastructure with encryption, access controls, and configurable retention. If your organization needs to understand user behavior on healthcare websites without risking a Privacy Rule violation or state law enforcement action, visit curvecompliance.com to evaluate whether it fits your compliance requirements.

Frequently Asked Questions

Can I use session replay on a healthcare website without a BAA?

No. If the website is operated by a HIPAA-covered entity or business associate, and the session replay tool receives any data that constitutes PHI (which, per OCR guidance, includes IP address plus health-context page visits), a BAA with the session replay vendor is required under 45 CFR 164.502(e). Operating without one is a per-se violation regardless of what data you believe the tool captures.

Does masking all form fields make session replay HIPAA compliant by itself?

Masking form fields is necessary but not sufficient. You must also address PHI in URLs, page content, metadata (IP addresses, device identifiers), and any dynamically rendered clinical information. Additionally, masking does not eliminate the need for a BAA and proper consent. All three requirements (masking, consent, BAA) must be satisfied simultaneously.

Is patient consent enough to allow session recording under HIPAA?

Consent alone is not enough. HIPAA requires that any disclosure of PHI to a session replay vendor be either permitted under a specific Privacy Rule exception (treatment, payment, or healthcare operations) with a BAA in place, or authorized by a valid HIPAA authorization that meets the requirements of 45 CFR 164.508. Even with consent, the minimum necessary standard still applies, meaning you must mask PHI that is not needed for the recording's purpose.

What happens if a session replay tool accidentally records PHI despite masking settings?

An accidental capture of PHI by a session replay tool constitutes a potential breach under 45 CFR 164.402. You must conduct a risk assessment to determine whether the incident rises to the level of a reportable breach (considering who accessed the data, whether it was encrypted, and the probability of compromise). If reportable, you must notify affected individuals, HHS, and potentially media outlets within required timelines. Having a BAA ensures the vendor shares accountability and breach notification duties.

Do non-covered entities (health apps, wellness sites) need to worry about session replay compliance?

Yes. Even if HIPAA does not directly apply, the FTC Health Breach Notification Rule, state laws like Washington MHMDA, and general FTC Act Section 5 enforcement against deceptive practices all regulate how health-related browsing data is collected and shared with third parties. The BetterHelp and GoodRx settlements demonstrated that non-covered entities face significant enforcement risk from session replay and tracking tools that share health data without adequate disclosure and consent.

How often should I audit my session replay masking configuration?

Audit masking after every website deployment that changes page structure, form fields, URL patterns, or dynamic content rendering. At minimum, conduct a full audit quarterly. Automated monitoring that flags new unmasked DOM elements containing potential PHI patterns (names, dates, ID numbers) significantly reduces drift risk between manual audits.