HIPAA Website Requirements: What You Actually Have to Get Right

HIPAA is United States federal law. It applies to covered entities (providers, health plans, clearinghouses) and to their business associates - the vendors that handle protected health information on their behalf. Your web developer, your hosting company, and your form processor are all potential business associates.

Here is the part most builders get wrong: not every page on your site needs to be HIPAA compliant. HIPAA attaches to protected health information. A marketing page describing your services, your team, or your location collects no PHI and carries no HIPAA obligation on its own.

The moment a page collects, transmits, or stores PHI - an appointment request, a contact form with health details, a patient portal login - that page and everything behind it falls under HIPAA. The practical job is to map exactly where PHI enters your site and lock down those paths, not to gold-plate the entire domain.

One clarification worth making plainly: there is no such thing as a "HIPAA-certified website," and no builder or platform is "HIPAA compliant out of the box." No government body certifies websites. Compliance is something you implement and document, not a badge you buy or a setting you switch on.

Protected health information is any individually identifiable health information. On a website, the boundary is wider than most owners expect, and this is where audits find trouble.

PHI on your site can include: - Appointment and booking requests - the name, contact details, and reason-for-visit tied together

• Contact form submissions that mention a condition, symptom, medication, or treatment
• Patient portal data - logins, records, messages, billing
• IP addresses when combined with health context (a visit to a specific treatment page plus an identifier)
• Tracking identifiers and cookies that link a person to health-related browsing
• Any field that connects an identifiable individual to their care

That fourth and fifth point are the ones that surprise people. An IP address on its own is debatable, but an IP address captured alongside a visit to your oncology or addiction-treatment page, tied to a tracking cookie, becomes identifiable health information in the eyes of regulators. This is the exact mechanism behind the tracking-pixel enforcement actions covered later on this page.

HIPAA is built on four rules. Your website touches all of them.

The Security Rule organizes everything into three buckets. A compliant site needs all three - technical controls alone are not enough.

A Business Associate Agreement (BAA) is a signed legal contract that binds a vendor to HIPAA's safeguards and makes them liable for breaches. If a vendor touches PHI and you do not have a BAA with them, you are already non-compliant.

For a healthcare website, that means a BAA with: - Your hosting provider (the server storing or transmitting PHI)

• Your form and data handler (whatever processes and stores submissions)
• Your email provider if any PHI flows through email
• Your booking/scheduling tool if it captures patient information
• Your analytics vendor if it could receive PHI - and most consumer analytics will not sign one

Encryption is the technical safeguard regulators look at first, and it has two halves.

In transit - data moving between the visitor's browser and your server must be encrypted with TLS 1.2 or higher. That means HTTPS on every page, not just the form pages, enforced with HSTS (HTTP Strict Transport Security) so browsers refuse to connect over plain HTTP. A redirect from HTTP to HTTPS is not enough on its own; HSTS closes the window where a downgrade attack can intercept the first request.

At rest - PHI stored on your server or in your database must be encrypted, with AES-256 as the standard benchmark. Stored form submissions, patient records, and backups all qualify.

Once PHI is in your system, the Security Rule dictates who can reach it and demands a record of who did.

This is the single most active enforcement area in healthcare web today, and it has caught major hospital systems off guard.

Standard analytics and advertising tools - Google Analytics, the Meta (Facebook) Pixel, and similar tags - work by sending data about each visitor to a third party. On a healthcare site, that data can include the page someone viewed (which may reveal a condition), their IP address, and a tracking identifier. Bundled together, that is PHI being disclosed to a vendor who has not signed a BAA and will not sign one for this purpose.

The HHS Office for Civil Rights has issued specific guidance warning that the use of these tracking technologies on pages that handle PHI can violate HIPAA. Regulators have pursued health systems precisely over pixel data leaking to ad platforms. The risk is not theoretical.

Technical controls are only half the obligation. HIPAA expects documentation, and the absence of it is itself a finding.

Your site and practice need: - Privacy Policy - how you collect, use, and protect data on the site

• Notice of Privacy Practices (NPP) - the HIPAA-mandated notice of patients' rights and your duties
• Cookie and consent management - especially where any tracking runs
• A documented risk analysis - a written assessment of where PHI lives, what threatens it, and how you mitigate those risks

The risk analysis is the keystone. It is explicitly required by the Security Rule, it is the first thing OCR asks for in an investigation, and a missing or stale one is among the most commonly cited violations. Compliance is not just having safeguards - it is being able to prove you assessed the risks and chose those safeguards deliberately. This is guidance, not legal advice. Your privacy policy and NPP should be reviewed by qualified counsel before publishing.

Enforcement runs through the HHS Office for Civil Rights, and the penalties scale with culpability. Fines are tiered - from lower amounts for violations you did not know about, up the ladder for willful neglect - and they can reach into the millions in aggregate for a single year, alongside mandatory corrective action plans. Tracking-pixel cases have produced settlements and ongoing oversight for health systems that thought their analytics were harmless.

Beyond the dollar figure, a breach triggers the Breach Notification Rule: you have to tell affected patients, notify OCR, and in larger breaches notify the media. For a practice that runs on trust, that disclosure can cost more than the fine. Doing it right the first time is far cheaper than remediation under a corrective action plan.

Work through this in order. Each step assumes the one before it is done.

1. Map your PHI - list every page, form, and integration that collects, transmits, or stores patient information. Everything else is lower priority.
2. Run a documented risk analysis - assess threats to that PHI and write down your findings and mitigations.
3. Sign BAAs with every vendor that touches PHI: hosting, forms, email, booking, analytics. Drop any vendor that will not sign.
4. Enforce HTTPS everywhere with TLS 1.2+ and HSTS. No mixed content.
5. Encrypt PHI at rest with AES-256 across the database and backups.
6. Harden every form - POST-only, autocomplete off, no caching, encrypted storage, minimum necessary fields.
7. Implement access controls - unique IDs, RBAC, MFA, auto-logoff, least privilege on any PHI-bearing area.
8. Turn on audit logging and set six-year retention for compliance records.
9. Remove ad and analytics pixels from PHI pages; switch to compliant, privacy-first analytics.
10. Publish required policies - Privacy Policy, Notice of Privacy Practices, and cookie/consent handling.
11. Document everything and schedule a periodic review - compliance is ongoing, not one-time.

If you already have a site, you do not need to guess whether it is compliant. You can check.

Start with the network. Open your browser's developer tools, load your booking and contact pages, and watch the outgoing requests. If you see calls to Google Analytics, Facebook, or any ad network firing on a page that collects PHI, that is a live problem. Check that every page loads over HTTPS and that HSTS is present in the response headers.

Then check the forms. Confirm submissions go over POST, not GET. Confirm PHI is stored encrypted and behind authentication rather than emailed in plain text. Confirm autocomplete is off on sensitive fields and the pages are not cached.

Then check the paperwork. Do you have signed BAAs with every vendor in the data path? A current, documented risk analysis? A published Privacy Policy and NPP? If any of those are missing, the technical fixes are incomplete on their own.

Requirements only matter if the site they produce actually performs. Prime Home Health, a home-care clinic in Winnipeg operating under Manitoba's Personal Health Information Act (PHIA), is the proof.

When they came to me, the site was effectively invisible on Google. I rebuilt it custom, on compliant infrastructure, with secure forms and clean analytics, and paired the build with an SEO retainer. Within about 30 days the results were measurable in Google Search Console.

If you operate in Canada, HIPAA does not apply to you. Canada has no HIPAA equivalent. Instead you are governed by PIPEDA - the federal private-sector privacy law - layered with a provincial health-information act: PHIPA in Ontario, PHIA in Manitoba, Nova Scotia, and Newfoundland & Labrador, PHIPAA in New Brunswick, and HIA in Alberta.