What Makes a Dental Website HIPAA-Compliant?

A website can't be "HIPAA certified." There's no official certification, and a badge in your footer doesn't change anything. What makes a HIPAA compliant dental website is how the site and the tools connected to it handle protected health information: what patients type into it, where that data goes, who can see it, and whether every vendor that touches it has signed the right agreement.

For most practices, the risk isn't the homepage or the photo of your team. It's the appointment request form that emails "chipped front tooth, PPO insurance, DOB 4/12/1981" in plain text to a shared inbox, or a tracking pixel quietly sending page visits to an ad platform. This guide walks through where the real exposure is and what to check.

This is general information, not legal advice. HIPAA questions depend on your setup, so confirm decisions with a healthcare attorney or your compliance advisor.

What HIPAA actually cares about on a website

HIPAA's Privacy and Security Rules apply to protected health information (PHI): health information that can be linked to an individual. On a dental website, PHI usually shows up when a patient:

Fills out an appointment request or contact form that mentions symptoms, treatment, insurance or date of birth
Books online and the booking details identify them and the reason for the visit
Completes intake forms, medical history or consent forms online
Uses a chat widget or AI assistant and describes their dental problem
Logs into a patient portal or pays a bill

A page that only describes your services and shows your hours generally isn't handling PHI. A page that collects information from a patient may be.

The practical test: follow every piece of information a patient can type into your site, and see where it ends up.

The parts of a HIPAA compliant dental website

Here's how the common pieces of a dental site line up against HIPAA risk.

Website element	Typical risk level	What to check
Informational pages (services, team, hours)	Low	HTTPS on every page; nothing else usually needed
General contact form	Medium	What fields it asks for; where submissions are stored and sent
Appointment request form	Medium to high	Encryption in transit and at rest; BAA with the form vendor; no PHI in plain email
Online booking tool	High	BAA with the vendor; how it connects to your PMS
Online intake and medical history	High	Use a vendor built for healthcare that signs a BAA
Chat widget or AI booking assistant	Medium to high	Whether chats are stored; BAA; what the bot asks
Tracking pixels and analytics	Medium to high	What data they send, from which pages
Patient portal and bill pay	High	Usually a separate, vendor-hosted system with its own BAA
Embedded reviews	Low to medium	Your public replies, not the widget, are the risk

Forms: the most common problem

Most dental websites have at least one form, and many are built with a generic plugin that emails each submission to the office. That's convenient and often a problem, because standard email isn't designed to protect PHI, and the submissions frequently sit in the website's database too.

To tighten this up:

Ask for less. A new-patient request form needs a name, a phone number or email, and a preferred time. It doesn't need a date of birth, insurance ID or medical history. Our guide to dental website lead forms covers which fields actually help.
Make clinical details optional. A "reason for visit" field invites PHI. If you keep it, consider a short dropdown (new patient exam, cleaning, emergency) instead of a free-text box.
Use a form tool that will sign a business associate agreement (BAA) if the form will collect PHI. Many general-purpose form builders offer HIPAA-eligible plans; free tiers often don't.
Stop emailing the full submission. Better setups send a notification that "a new request is waiting" and require staff to log in to see the details.
Clear out old submissions. If your website database has years of stored form entries, decide with your advisor whether to keep them, move them or delete them.

Business associate agreements

Under HIPAA, a vendor that creates, receives, stores or transmits PHI on your behalf is generally a business associate, and you need a signed BAA with them before they handle that data.

On the website side, vendors that may need one include:

Your form provider
Your online booking and scheduling vendor
Your intake form or patient portal vendor
Your chat or AI assistant provider
Your call tracking provider, if it records calls
Your web host, if PHI is stored on its servers
Your marketing agency, if it can see form submissions or recordings

A vendor that says "we're HIPAA compliant" but won't sign a BAA hasn't answered the question. Keep signed copies on file with the rest of your compliance documents.

Tracking pixels and analytics

This is the area that's changed most in recent years. Tracking technologies such as advertising pixels, session recording tools and some analytics setups can send data about what visitors do on your site to third parties. If that data can be tied to a person and to their health (for example, a logged-in patient viewing a page, or a form submission event that includes details), regulators have treated it as a potential disclosure of PHI.

The HHS Office for Civil Rights issued guidance on online tracking technologies, and parts of it have since been revised and challenged in court. Exactly where the lines fall is a question for your compliance advisor. A cautious approach in the meantime:

Don't place advertising pixels on forms, booking flows, patient portals or thank-you pages that could reveal who a patient is and why they're coming in.
Don't pass form contents (names, emails, phone numbers, reasons for visit) into analytics or ad platforms.
Turn off session recording on any page where patients enter information.
Audit what's actually installed. Old pixels from past agencies are common, and nobody remembers adding them.

Google Analytics 4 is still useful for understanding which pages and channels bring visitors. Configure it so it never receives PHI, and treat that as a hard rule. Our guide to Google Analytics for dentists covers what to measure without crossing that line.

Security basics a compliant site needs

HIPAA's Security Rule calls for reasonable safeguards. For a website, the baseline is:

HTTPS everywhere, with a valid certificate and no mixed-content warnings
Strong, unique logins and multi-factor authentication for anyone who can edit the site or view submissions
Separate accounts for each person instead of one shared admin login
Regular updates to the website platform, theme and plugins
Backups that are themselves stored securely
Removing access promptly when staff or vendors leave

Our dental website security guide goes deeper on keeping the site itself from being compromised.

Required notices and policies

Two pages often get confused:

Notice of Privacy Practices. HIPAA requires covered entities that maintain a website describing their services to post this notice prominently on the site. Link to it from your footer.
Website privacy policy. This explains what your website collects (cookies, analytics, form data) and how you use it. It's separate from the Notice of Privacy Practices, and state privacy laws may affect what it needs to say.

Have your compliance advisor review both, especially if you use tracking or advertising tools.

Don't forget your public replies

A website can be well built and still create a disclosure if someone on your team confirms a patient relationship in a public reply to a review or a social media comment. That's not a website setting, but it often lives on the website through embedded review widgets. See responding to patient reviews without violating HIPAA for safe reply patterns.

A quick self-audit

Work through this with whoever manages your site:

[ ] Every page loads over HTTPS
[ ] We know every form on the site and every field it collects
[ ] Forms that can collect PHI use a vendor that signed a BAA
[ ] Form submissions aren't emailed in full to a regular inbox
[ ] Booking, intake, chat and call tracking vendors have signed BAAs where needed
[ ] No ad pixels or session recording on forms, booking or portal pages
[ ] Analytics doesn't receive names, contact details or visit reasons
[ ] Each person who edits the site has their own login with MFA
[ ] Notice of Privacy Practices is posted and linked from every page
[ ] We've removed access for former staff and vendors

If several boxes stay unchecked, that's your project list.

Frequently asked questions

Does my dental website need to be HIPAA compliant?

If your website collects, stores or transmits protected health information, such as appointment requests with symptoms, online intake forms or booking details, then HIPAA's rules apply to how that data is handled. A purely informational site with no forms carries much less risk. Ask your compliance advisor to review your specific setup.

Is there a HIPAA certification for websites?

No. HHS doesn't certify websites or vendors as HIPAA compliant. Compliance depends on your safeguards, your policies and your agreements with vendors, so treat any "HIPAA certified" badge as marketing rather than proof.

Are contact forms on dental websites HIPAA compliant?

It depends on what they collect and where the data goes. A form that only asks for a name and phone number is lower risk. A form that asks about symptoms or insurance and emails the results in plain text is a common problem. Use a vendor that signs a BAA and limit the fields you collect.

Can I use Facebook or Google ad pixels on my dental website?

Use them cautiously and keep them away from forms, booking flows, patient portals and confirmation pages. Federal guidance on tracking technologies has shifted and been challenged in court, so check current requirements with your healthcare attorney or compliance advisor before installing them.

Does my web host need to sign a BAA?

If PHI is stored on the host's servers, for example in a form database, the host likely needs to sign one. If your site stores no PHI and all patient data goes directly to HIPAA-eligible vendors, the host may not need one. Confirm the specifics with your compliance advisor.