Do I Need a Privacy Policy on My Website?

Written by Jessica Freeman, Web Designer and SEO Strategist since 2011 • Post Last Updated September 2026

Yes. Nearly every health and fitness practice website needs a privacy policy, and the answer doesn’t change based on how many pages your site has, how long you’ve been in practice, or how “simple” you think your setup is. If your site collects a name and an email address, this applies to you.

Here’s where most practitioners get tangled up: a privacy policy and a HIPAA Notice of Privacy Practices are not the same document, and treating them like they’re interchangeable is the single most common mistake I see when I audit a practice’s site.

Your HIPAA notice covers what happens to a patient’s clinical records once they’re in your care. Your privacy policy covers what happens to a visitor’s data the moment they land on your website, before they’ve ever booked with you. Different documents, different jobs, both required.

I know legal language makes people’s eyes glaze over, and I’m not going to pretend a privacy policy is thrilling reading. But this one’s not complicated once someone walks you through it, which is what the rest of this post is for. And skipping it isn’t just a compliance gap. It’s the kind of thing that quietly tells a potential patient “this practice doesn’t have its act together” before they’ve even filled out your intake form, which is the opposite of what you want your website doing.

I catch this constantly during site audits: a practice with a beautifully designed homepage and a footer link to nothing, or worse, a footer link to a document that isn’t actually a privacy policy at all.

What counts as a privacy policy on a health or wellness website?

A privacy policy is a disclosure of what data your website collects, how it’s used, and who it gets shared with. It covers your contact forms, your booking widget, any cookies or analytics tools running in the background, and your email opt-ins, whether that’s a newsletter signup or a lead magnet.

It is not your HIPAA Notice of Privacy Practices. Here’s how the two actually differ:

Website Privacy PolicyHIPAA Notice of Privacy Practices
Legal BasisState consumer privacy laws (CCPA/CPRA, Virginia’s VCDPA, Colorado’s CPA, Washington’s My Health My Data Act) plus vendor contract terms, including Section 7 of the Google Analytics Terms of Service and the Stripe Services AgreementThe HIPAA Privacy Rule, 45 CFR 164.520, enforced by the HHS Office for Civil Rights
Scope of DataWebsite form submissions, cookies, IP addresses, Google Analytics 4 identifiers, Meta Pixel event data, and email addresses captured through opt-insProtected health information: chart notes, diagnoses, treatment plans, and billing and claims records
Who It ProtectsAny visitor to your site, whether they ever become a patient or notEstablished patients and clients whose PHI you already hold
Where It AppliesYour website, linked in the footer of every pageYour practice as a whole. Provided at first delivery of service, posted in your office, and posted on your site per 164.520(c)

It is not your HIPAA Notice of Privacy Practices. I’ve opened client sites where the “privacy policy” link in the footer led straight to their HIPAA notice, which addresses none of the actual website data collection happening on that same page. It’s an easy mix-up, because both documents have “privacy” in the name and both feel like the same flavor of legal necessity, but a Google Analytics disclosure has nothing to do with how you store a patient’s chart.

Do I actually need a privacy policy, or is it optional?

You need one. Almost no practice website is exempt. Most states now have some form of privacy law that applies the moment your site collects personal data from a visitor, regardless of your practice’s size or location. Some of these laws are aimed at larger businesses, but plenty apply to a solo practitioner running a six-page Squarespace site just as much as they apply to a hospital system.

(Which is also why I use Termageddon (aff link), as it adds new clauses as more laws are added!)

Washington’s My Health My Data Act (MHMDA) is the one that catches health and fitness professionals most off guard. It took effect March 31, 2024, it has no revenue or headcount threshold, and it applies to any entity that conducts business in Washington or targets Washington consumers, which includes a telehealth dietitian in Georgia with clients in Seattle. It requires a separate consumer health data privacy policy linked distinctly from your homepage, not folded into your general policy. Violations are enforced by the Washington Attorney General through the state Consumer Protection Act (RCW 19.86), and the act carries a private right of action, which is rare among state privacy laws. Nevada passed a close cousin, SB 370, enforced by the Nevada Attorney General.

California’s CCPA, as amended by the CPRA, applies once you cross one of three thresholds: $25 million in annual gross revenue, personal information on 100,000 or more California consumers or households, or 50% or more of revenue from selling or sharing personal information. Most solo practices are under all three, so this often doesn’t apply yet. Worth knowing anyway, because it’s enforced by two bodies, the California Privacy Protection Agency and the California Attorney General, and because the CCPA’s HIPAA carve-out is data-level, meaning it exempts PHI but not the website visitor data your marketing tools are collecting.

Virginia’s VCDPA works differently and this trips people up in the other direction. It exempts HIPAA covered entities and business associates at the entity level, so if you’re a covered entity, the VCDPA doesn’t reach you at all. Enforcement sits with the Virginia Attorney General. That entity-level exemption is why “state privacy law” is not a single answer you can apply across the board.

Then there’s the FTC, which has become the most active enforcer in this space for anyone doing health marketing online. In February 2023, the FTC brought its first Health Breach Notification Rule case against GoodRx over tracking pixels that shared user health data with Meta and Google, resulting in a $1.5 million civil penalty. A month later, BetterHelp settled for $7.8 million over similar disclosures. In July 2023, the FTC and HHS Office for Civil Rights sent joint letters to roughly 130 hospitals and telehealth companies about exactly this issue. If you have a Meta Pixel firing on a page where someone books a therapy appointment, that’s the pattern regulators are looking at.

And separately from all of that: the trigger for needing a policy at minimum is the presence of any contact form, booking tool, or opt-in on your site, because your vendors require it contractually. Section 7 of the Google Analytics Terms of Service says you must post a privacy policy, provide notice of your cookie use, and disclose that you’re running Google Analytics and how it processes data. That obligation exists whether or not a single state law applies to you.

What happens if a practice website doesn’t have a privacy policy?

Nothing dramatic happens the day you launch without one, which is exactly why this gets pushed to the bottom of the list.

Some of your platform tools may potentially simply stop working. Payment processors and booking software increasingly require a published privacy policy to keep your integrations active, so this can turn into a functionality problem before it turns into a legal one.

I’ve caught this gap on client sites before it became a bigger issue, usually during the SEO or platform setup phase, when a missing privacy policy blocks a booking integration from going live. Better to catch it in an audit than to have a patient try to book and hit a wall.

What should a privacy policy for a health professional’s website include?

At minimum, your policy needs to spell out three things in plain language: what data you collect, how you use it, and who you share it with. No legalese required, just clarity.

Cookie and analytics disclosures belong here too. If you’re running Google Analytics 4, a Meta Pixel, Microsoft Clarity, or Hotjar, each one needs to be named, along with what it collects and how a visitor can opt out. Same with your third-party platforms: your scheduling tool, whether that’s Acuity Scheduling, SimplePractice, Jane App, IntakeQ, or Calendly; your email platform, whether that’s Kit, Mailchimp, or Flodesk; and your payment processor, usually Stripe or Square. Vague language like “we may use third-party services” doesn’t hold up the way naming the actual tools does.

When I’m reviewing a client’s policy, I always double-check that every tool actually running on their live site is named in the document. It’s a common gap: someone adds a new booking platform eighteen months after their site launched, and the privacy policy never gets updated to match.

Can I use a free privacy policy template?

A template can work as a starting point, but only if you actually customize it to reflect the tools running on your specific site. Where templates fall apart is when someone grabs a generic version, publishes it as-is, and it references data practices that don’t match what’s actually happening on their site, or leaves out tools they’re using entirely.

I’ve seen a template-based policy cause a real problem for a client: it referenced a data-sharing practice that didn’t apply to their setup at all, which is worse than having no policy, because now the document actively misrepresents what you’re doing. If your practice handles anything beyond standard forms and analytics, or if you’re in a state with stricter privacy requirements, it’s worth having a healthcare attorney review the final version. For most straightforward practice sites, a properly customized template with attorney review is a reasonable, non-overwhelming middle ground.

(Which is also why I use Termageddon (aff link), as it’s more cost-effective than working with a lawyer directly and it adds new clauses as more laws are added!)

Where should the privacy policy live on the website?

Footer link, standalone page, visible on every page of your site without anyone having to hunt for it. This is standard placement and patients expect to find it there.

Update it any time you add something new that touches data collection: a new booking tool, a new opt-in form, a new tracking pixel. If you added it to your site, it needs to be reflected in your policy. Beyond that, a simple annual review is a cadence most practices can actually stick to, timed to whenever you’re already doing a broader site check.

If you’re managing multiple sites or a growing practice with multiple locations, keep a running list of which sites are due for review and when. It’s a five-minute task that’s easy to forget without a system, and it’s the kind of thing that’s much easier to stay ahead of than to fix retroactively.

FAQ

Is a privacy policy the same as a HIPAA Notice of Privacy Practices?

Nope. Your privacy policy covers website data. Your HIPAA notice covers clinical records. Most practices need both, published separately.

Does a solo practice with a simple website still need one?

Yes. The requirement is triggered by data collection, not by practice size or how many pages your site has. A three-page site with a single contact form still needs a privacy policy.

Can I write my own privacy policy without a lawyer?

For a straightforward site, a properly customized template is a reasonable place to start. If your practice collects sensitive data beyond standard forms, operates in a state with stricter privacy laws, or you’re just not confident you’ve covered everything, attorney review is worth the investment. It doesn’t need to be either extreme of “fully DIY” or “full legal retainer.”

What if my website doesn’t collect any client information directly?

If you’re running analytics or cookies, and nearly every site is, that still counts as data collection. Passive tracking triggers the same requirement as an active contact form.

Will not having a privacy policy actually get my practice in trouble?

It can, depending on your state’s privacy laws and how your site is set up, but the more immediate risk is usually practical: broken integrations with payment processors or booking tools.

Final Thoughts

This is a small, manageable fix, not a legal project that needs to eat your whole week. Once it’s in place and reflects the tools actually running on your site, you can stop thinking about it until your next update or annual review.

Treat it the same way you’d treat any other routine maintenance on your site: something you check on a schedule, not something you only think about after a problem shows up. If you want a second opinion on whether your current policy actually covers what your site is doing, that’s the kind of thing I look at during a website audit or a consult call.