What makes a website HIPAA compliant?
A website is HIPAA compliant when every part of it that handles protected health information does so through systems and vendors covered by business associate agreements, with appropriate safeguards, and when nothing on the site discloses PHI to third parties without permission. There is no official HIPAA certification or badge for websites. Compliance describes how data is handled, not how the site looks.
This guide is part of our healthtech website design hub. Its job is to draw a clear line: which parts of a healthcare or digital health website create HIPAA exposure, and which don't. Most guides blur that line, and the result is either panic about pages that hold no data, or carelessness about forms and pixels that do. This is a design brief, not legal advice; confirm your obligations with counsel.
Does HIPAA apply to my website?
HIPAA applies to your website if your organization is a covered entity, such as a healthcare provider that bills insurance electronically, a health plan or a clearinghouse, or a business associate that handles PHI on behalf of one. Many wellness apps and consumer health products aren't covered by HIPAA at all, though other rules may still apply to the health data they collect.
Who you are | Does HIPAA apply? | Notes |
|---|---|---|
Clinic, hospital or practice billing insurance | Yes, as a covered entity | Forms, booking and portals that collect PHI are in scope |
Health plan or insurer | Yes, as a covered entity | Member portals and enrollment flows are in scope |
Digital health vendor serving providers or plans | Usually, as a business associate | Depends on contracts and what data you handle |
Direct-to-consumer wellness app, no insurer or provider link | Often not | The FTC's Health Breach Notification Rule and state laws may apply |
Fitness or spa business | Usually not | Unless you bill insurance or act for a covered entity |
If you aren't covered by HIPAA, don't relax completely. The FTC enforces its Health Breach Notification Rule against health apps that share data without authorization, and several US states have their own consumer health data laws. Designing as if HIPAA applied is often the safer default for anyone collecting health information.
Which parts of a HIPAA compliant website actually need to be compliant?
The parts of a website that need HIPAA safeguards are the ones that collect, store, transmit or expose PHI: patient intake and symptom forms, appointment booking, eligibility checks, patient portals, notification emails and any scripts that can see those pages. Static marketing pages, blog posts and buyer-facing demo forms that don't ask for health details usually aren't in scope.
Site area | PHI risk | Why |
|---|---|---|
Home, about, service and blog pages | Usually none | No data collected; general information only |
B2B demo or partnership form | Low | Business contact details, as long as you don't ask about health |
General contact form with a free-text message | Medium | Patients often type symptoms into open fields |
Appointment booking | High | A booking with a provider can itself reveal a health relationship |
Intake, eligibility and symptom forms | High | Directly collects health information |
Patient portal | High | Stores and displays PHI |
Analytics and ad pixels | Depends on placement | Can transmit page URLs, form events and identifiers to third parties |
What are the HIPAA website requirements for forms, hosting and email?
The HIPAA website requirements for forms, hosting and email come down to three things: a signed business associate agreement with each vendor that touches PHI, technical safeguards such as encryption in transit and at rest with access controls, and no PHI in places that lack those safeguards, such as plain notification emails.
- Forms. Native form features in most website builders aren't covered by a BAA, so route PHI to a form provider that signs one. Our guide to HIPAA compliant forms on Webflow, Framer and Next.js walks through the setup for each platform.
- Hosting and backend. If your own server or database stores PHI, your hosting provider needs to sign a BAA for that service. Major cloud providers offer BAAs for eligible services.
- Email notifications. A form tool that emails the full submission to a staff inbox can undo everything. Send a notification without PHI and have staff log in to view the submission.
- Access. Limit who can see submissions, use unique accounts and keep audit logs where the vendor provides them.
The rules themselves are set by the HHS Security and Privacy Rules; the HHS HIPAA pages are the primary source.
How do tracking pixels create HIPAA exposure on a website?
Tracking pixels create HIPAA exposure when they run on pages where patients book, check eligibility or describe health conditions, because they can send page addresses, button clicks, form events and device identifiers to ad or analytics companies. For a covered entity, that disclosure can count as sharing PHI with a third party that hasn't signed a BAA.
The HHS Office for Civil Rights published guidance on online tracking technologies, and a federal court later vacated part of it, specifically around some public, unauthenticated pages. The risk on authenticated pages, booking flows and forms remains. Our guide to healthcare website tracking covers which tools and configurations are lower risk.
How does HIPAA compliant website design work in practice?
You design a HIPAA-aware website by mapping where health data enters and moves before you design any pages, then building the regulated parts on BAA-covered tools and keeping marketing scripts away from them. The decisions that matter most are architectural, which is why they belong at the start of the project, not at launch.
Map the data
List every place the site collects information and what fields it asks for. Mark which ones could contain PHI, including free-text fields.
Separate the regulated zone
Put booking, intake and portals on dedicated pages or a subdomain with their own, stricter script rules.
Choose BAA-covered vendors
Confirm in writing that each vendor handling PHI will sign a BAA on the plan you're buying, before design starts.
Set a script policy
Decide which analytics and ad scripts may run on which pages, and enforce it in the code, not just in a tag manager setting.
Ask for less
Remove every form field you don't need. Data you never collect can't leak.
Write the privacy notice to match reality
Describe what the site actually collects and shares, and keep it updated when tools change.
Hypothetical example: a telehealth startup's site, mapped
For example, suppose a telehealth startup's marketing site has a home page, service pages, a blog, an eligibility checker, a booking flow and a contact form, with an ad pixel and analytics site-wide.
The data map shows three PHI risks: the eligibility checker asks about conditions, booking reveals a provider relationship, and the contact form collects symptoms in free text. The redesign keeps the marketing pages on the visual builder with analytics, moves eligibility and booking to a subdomain using BAA-covered tools with no ad pixels, changes the contact form to business inquiries only with a link to the secure patient path, and switches staff notifications to alerts without submission content. This is illustrative and not legal advice.
Is my website HIPAA compliant? A quick check
Your website is likely in good shape if you can answer yes to every question below. Any no is worth fixing, starting with the forms and pixels, where most real exposure sits.
- Does every vendor that receives PHI from the site have a signed BAA?
- Are intake, booking and eligibility forms routed through those vendors rather than native builder forms?
- Are ad pixels and session recordings kept off pages where patients book or share health details?
- Do notification emails omit health information?
- Does the privacy policy describe what the site actually collects and shares?
- Is someone responsible for reviewing new scripts and tools before they're added?
Planning a new site? Our guide to the pages a digital health website needs helps scope it, and our healthcare website cost guide covers budgets. Virtual care products should also read our guide to telehealth website design. If you're vetting partners, our guide to choosing a healthcare website design agency lists the questions to ask.
