HIPAA Compliance Doesn’t Prove Your Website Is Protecting Patient Data

Healthcare organizations invest heavily in HIPAA compliance. They maintain policies, conduct risk assessments, train employees, execute business associate agreements, and review vendors. Those activities matter. But none of them, on their own, prove what happens when a patient visits a website.

A website can look compliant on paper while still sending information to third parties through pixels, tags, scripts, forms, and other tracking technologies. That is the gap privacy teams increasingly need to address: the difference between documented intent and observable behavior.

HIPAA compliance is essential. It is not a substitute for testing what your digital properties actually do

A current reminder from the FTC

On July 29, 2026, the Federal Trade Commission, joined by authorities in California and Utah, filed a complaint against Hims & Hers. The complaint alleges, among other things, that the telehealth provider shared sensitive health information with advertising platforms despite making promises about patient privacy.

According to the FTC, the alleged sharing occurred through customer lists and third-party tracking technologies that automatically transmitted certain website events. The allegations have not yet been decided by a court. Even so, the complaint offers an important operational lesson for healthcare privacy teams: regulators may examine the data that moved, the recipients that received it, and whether that behavior matched what consumers were told.

The lesson is not limited to one company, one pixel, or even HIPAA. It is that health-data risk often becomes visible in the technical behavior of a website and not in the wording of a policy or the settings displayed in a compliance platform.

HIPAA defines obligations. It does not test your website.

The HIPAA Privacy, Security, and Breach Notification Rules apply to covered entities and business associates and establish requirements for protecting protected health information. A well-designed HIPAA program creates the organizational foundation for doing that work.

But a policy cannot tell you whether an advertising tag fired before consent. A business associate agreement cannot show which parameters were included in a network request. A vendor questionnaire cannot confirm that a script behaved the same way after a marketing update as it did when the vendor was first approved.

Those questions require evidence from the live digital environment.

That distinction matters because modern healthcare websites are rarely static. Marketing teams launch campaigns. Agencies deploy new tags. Developers change forms and page structures. Vendors update their code. Consent-management rules evolve. A website that behaved as expected during last quarter’s assessment may behave differently today.

“We are HIPAA compliant” is not the end of the analysis

HIPAA also does not cover every organization, every type of health-related information, or every digital interaction. HHS explains that the HIPAA Rules generally apply when protected health information is created, received, maintained, or transmitted by covered entities and business associates. Health information outside those relationships may fall outside HIPAA even though it remains highly sensitive to the person involved.

That means privacy teams should avoid using a single question of “Is this PHI under HIPAA?” as the entire decision framework.

Other questions matter too:



• What information is being collected or inferred?
• What would the patient reasonably understand from the context?
• Which third parties receive the information?
• What promises has the organization made in its privacy notices, consent language, or marketing?
• Do state privacy, consumer-protection, health-data, or breach-notification requirements apply?
• Does the actual data flow match the organization’s approved purpose and configuration?

The legal analysis is important. But it should be informed by a reliable account of what the technology is actually doing.

The website itself is part of the evidence

When a patient visits a healthcare website, the browser may initiate dozens or hundreds of network calls. Some support core functions such as security, accessibility, scheduling, or authentication. Others may support analytics, advertising, personalization, video, chat, or campaign measurement.

The presence of a third-party technology does not, by itself, establish a violation. Context matters: the organization’s role, the data involved, the destination, the purpose, the applicable law, the user’s choices, and the contractual and technical safeguards all require analysis.



But privacy teams cannot perform that analysis accurately if they do not know what data is leaving the site.

Useful evidence may include:

• the page and user action that triggered a transmission;
• the consent state in effect at that moment;
• the script or tag responsible for the request;
• the third-party domain that received it;
• the data elements, event names, URLs, identifiers, or parameters transmitted;
• whether the behavior changed after a user opted out or withdrew consent; and
• whether the same behavior reappeared after a site or vendor update.

This is why a screenshot of a cookie banner is not enough. It shows what the patient saw. It does not show whether every technology respected the patient’s choice.

Consent configuration and consent enforcement are different things

Many healthcare organizations use a consent management platform to present choices and store user preferences. That is an important control, but it is only one part of the system.

Recording a choice is not the same as enforcing it.

A tag may be assigned to the wrong category. A script may load outside the tag manager. A vendor may set an identifier through a different mechanism. A new page template may omit the consent logic. A preference may be recorded correctly while a downstream request still fires.

From the user’s perspective, the distinction is irrelevant. The patient clicked a button and reasonably expects the website to honor the resulting choice. From the privacy team’s perspective, however, the distinction is crucial: the CMP can report success while the website behaves differently.

The only way to close that gap is to validate both sides—the recorded choice and the resulting technical behavior.

One-time audits cannot control a changing website

Traditional privacy reviews often happen at a point in time: before launch, during an annual assessment, or after a concern has already surfaced. That approach is poorly matched to websites that change every week.

Digital privacy risk drifts. It can reappear through routine activity rather than a dramatic failure:

• a marketing team publishes a new campaign page;
• an agency adds a conversion pixel;
• a vendor changes its endpoint;
• a developer modifies a form;
• a tag moves from testing to production; or
• a consent rule is updated in one jurisdiction but not another.

No policy can prevent every unintended change. A mature program therefore needs a feedback loop: observe, compare, investigate, correct, and verify.

What privacy officers should ask for

Privacy leaders do not need to become web developers. They do need access to evidence that allows legal, privacy, marketing, security, and engineering teams to work from the same facts.

A practical website-governance program should be able to answer:

1. What tracking technologies are present across our digital properties?
2. Which technologies activate before and after a user makes a privacy choice?
3. What information is transmitted, and to whom?
4. Does observed behavior match our policies, contracts, consent rules, and approved use cases?
5. Who owns remediation when behavior does not match expectations?
6. How will we detect new or changed behavior after today’s review is complete?

The objective is not to produce a longer inventory. It is to create an operating process that connects policy decisions to technical outcomes.

Compliance should be observable

HIPAA compliance remains foundational for covered healthcare organizations and their business associates. But the existence of a HIPAA program does not prove that every website tag, script, form, and network call is handling patient data as intended.

Policies document expectations. Contracts allocate responsibilities. Consent tools record choices. Technical validation shows whether those controls are working together in practice.

For healthcare privacy teams, that is the standard worth building toward: not compliance that is merely asserted, but protection that can be observed, tested, and verified over time.

This article provides general information and is not legal advice. Whether HIPAA or another law applies depends on the facts and circumstances.