What "HIPAA-compliant" actually means for a website (and what it does not)

The disclaimer up front

This is not legal advice, and you should treat anyone who offers a turnkey "HIPAA-compliant website" with caution. HIPAA compliance depends on technical, administrative, and operational safeguards across the entire organization that handles protected health information. A website on its own is never compliant or non-compliant in any meaningful sense, because compliance is a property of how a covered entity or business associate operates, not a checkbox a vendor can ship. What a web team can actually do is build the site so it does not become the weak link. That is the honest framing, and the rest of this piece is about what it means in practice.

What the Security Rule actually requires

The HIPAA Security Rule sets the federal baseline for electronic protected health information. It lives in the regulations at 45 CFR Part 160 and Subparts A and C of Part 164, and it requires covered entities and their business associates to put three categories of safeguards in place: administrative, physical, and technical. Administrative safeguards are the policies, training, and risk analysis that govern how an organization manages access to health information. Physical safeguards protect the facilities and devices. Technical safeguards are the controls in the systems themselves, including access controls, audit logging, integrity protections, and transmission security. A website touches mostly the technical layer, which is exactly why a site alone can never carry the whole burden.

Two roles matter for anyone building or hosting a healthcare site. A covered entity is the practice, hospital, or health plan. A business associate is any outside party that handles protected health information on the covered entity's behalf, and that category is broader than people expect. A hosting provider, a form processor, an email tool, and an analytics vendor can all become business associates the moment they touch health information. The Security Rule's obligations follow the data into those vendors, which is why the contracts between them are not a formality.

Encryption is expected, not magically mandatory

It is common to hear that HIPAA requires encryption, full stop. The reality is more precise. Under the current Security Rule, encryption is an addressable implementation specification at 45 CFR 164.312, both for stored information and for information in transit. Addressable does not mean optional. It means an organization must implement encryption where its risk analysis finds it reasonable and appropriate, or document why it used an equivalent alternative instead. In practice, for a public-facing website handling any health information, encrypting traffic in transit is the obvious and expected choice. We say it plainly so you do not treat encryption as either a literal universal mandate or as something you can quietly skip.

What a HIPAA-aware build does

A HIPAA-aware site encrypts everything in transit with current TLS. It avoids holding health information in the browser or in client-side storage. It processes any form that collects health information through HIPAA-eligible infrastructure under a signed Business Associate Agreement, rather than through a generic form widget. It keeps access and audit logs so activity can be reconstructed. It surfaces patient-facing privacy notices clearly. None of this is exotic engineering. The work is mostly discipline: deciding deliberately where health information is allowed to flow, and refusing to let it leak anywhere a contract and a risk analysis have not accounted for.

The analytics and pixel trap, and how 2024 changed it

The single most current pitfall is third-party tracking. In December 2022 the HHS Office for Civil Rights issued a bulletin on the use of online tracking technologies, and it revised that bulletin on March 18, 2024. The core warning is straightforward. A HIPAA-regulated entity may not impermissibly disclose protected health information to a tracking-technology vendor through cookies, web beacons, or pixels. If a pixel ships health information to an advertising or analytics platform, that disclosure needs either a signed Business Associate Agreement with the vendor or a valid HIPAA authorization from the individual. Clicking a cookie banner is not a valid HIPAA authorization, and treating banner consent as cover for tracking that moves health information is exactly the mistake the bulletin calls out.

There is an important nuance that most generic HIPAA-and-the-web articles get wrong as of 2026, and getting it right is the honest version. On June 20, 2024, the U.S. District Court for the Northern District of Texas, in American Hospital Association v. Becerra, vacated the part of the bulletin that treated HIPAA as triggered merely because tracking technology connected a visitor's IP address to a visit to an unauthenticated public webpage about a health condition or provider. The court held that OCR had exceeded its authority on that point, and HHS withdrew its appeal on August 29, 2024, which finalized the result. So a bare public marketing page with analytics is no longer automatically a HIPAA event just because someone reads about a condition there. What did not change is the rest. Tracking inside authenticated environments such as patient portals, and tracking anywhere health information is actually disclosed to a vendor, remains squarely subject to HIPAA. The practical posture: keep generic tracking off authenticated and PHI-handling pages, and never let a pixel be the channel that hands health information to a vendor you have no agreement with.

Business Associate Agreements in plain terms

A Business Associate Agreement is the written contract that makes a vendor accountable for the health information it handles. HHS guidance is specific about what it must do: define the permitted uses and disclosures of the information, require appropriate safeguards including the Security Rule's requirements for electronic health information, require the vendor to report breaches to the covered entity, and require the vendor to return or destroy the information when the relationship ends. A covered entity cannot authorize a business associate to use health information in a way the entity itself could not. The sharp version of the old advice is this: a host, form provider, analytics tool, or email service that touches health information is a business associate and needs a signed agreement. A vendor that merely describes itself as HIPAA-compliant in its marketing, with no signed agreement in place, carries no weight at all. The contract is the thing that counts, not the badge on the pricing page.

What is coming, and why it is not law yet

There is a change on the horizon worth knowing about so you neither ignore it nor mistake it for current law. On December 27, 2024, OCR issued a Notice of Proposed Rulemaking to strengthen the cybersecurity of electronic protected health information, published in the Federal Register on January 6, 2025. As proposed, it would remove the addressable-versus-required distinction and make most specifications mandatory, require encryption of electronic health information both at rest and in transit, require multi-factor authentication and network segmentation, and require annual written verification of a business associate's technical safeguards. The comment period closed on March 7, 2025. As of mid-2026 this remains a proposed rule. OCR received more than 4,700 comments and has not issued a final rule, and there is no confirmed timeline, so it could still change, be delayed, or be withdrawn. The binding standard today is still the existing Security Rule, with encryption addressable rather than flatly mandatory. We build to the stricter posture anyway, because it is good engineering and because it is where the rules appear to be heading, but we will not tell you it is the law before it is.

If you take one thing from this, take the framing. Compliance is organizational. A web team's job is to make the website HIPAA-aware so it strengthens that posture instead of undermining it, and to be candid about the line between what a site can do and what only your organization, your policies, and your signed agreements can carry. Anyone who sells you the website as the whole answer is selling you something that does not exist.

Sources

External sources are provided for verification. NavoTech is not affiliated with and does not endorse the organizations cited.

Written by the team at NavoTech Digital Solutions. Have a project or counter-example? Get in touch.