Most healthcare organizations assume their website is HIPAA compliant because their practice is. That assumption is wrong – and it is one of the most expensive assumptions in healthcare administration.
HIPAA compliance in your clinical workflows does not transfer automatically to your website. Your contact form could be submitting patient data to an unprotected server. Your analytics setup could be capturing protected health information and sending it to Google. Your appointment scheduling widget could be operating without a Business Associate Agreement. Your live chat tool almost certainly is.
Each of these scenarios represents a real, documented category of HIPAA violation. Each has produced real enforcement actions. And each is entirely preventable – if you know what to look for.
This checklist exists to help physicians, practice owners, compliance officers, healthcare administrators, and IT managers audit their websites against the actual requirements – not the legal summaries, not the vague guidance, but the specific technical implementation decisions that determine whether your website creates regulatory exposure or eliminates it.
Work through all 20 items. Flag every “No” as a compliance gap requiring remediation. Prioritize by risk level – the risk classification for each item is included – and address the highest-risk gaps first.
What makes a healthcare website HIPAA compliant?
A HIPAA-compliant healthcare website protects Protected Health Information (PHI) at every point where patient data enters, is transmitted, is processed, or is stored through the website. This requires: SSL encryption across all pages, HIPAA-eligible hosting with a Business Associate Agreement, encrypted form and appointment request data handling with documented BAA coverage for all processors, HIPAA-compliant configuration of analytics tools (or HIPAA-safe alternatives), removal or proper configuration of tracking pixels on patient-facing pages, secure access controls, documented data retention and destruction policies, and a consent management framework. No single element makes a website HIPAA compliant – compliance is the sum of all these components working correctly together.
What HIPAA Actually Applies to on a Website
HIPAA does not regulate websites as objects. It regulates the handling of Protected Health Information – and your website is one of the most consequential places where your organization either protects or exposes PHI.
PHI is any individually identifiable health information that relates to an individual’s past, present, or future physical or mental health condition; the provision of healthcare to that individual; or the past, present, or future payment for the provision of healthcare. This includes much more than medical records.
On a healthcare website, PHI can include:
Name combined with any health-related information (reason for appointment, condition, treatment sought), IP address when connected to a health-related page visit or form submission, email address when collected through a health-related inquiry, phone number when collected through a scheduling or health-inquiry form, date of birth when collected in scheduling or intake forms, insurance information submitted through any web form, health history submitted through patient intake forms, and appointment scheduling data that connects an identifiable individual to a provider and an appointment time.
The critical phrase is “combined with.” A name alone is not PHI. An IP address alone is not PHI. But an IP address captured while a patient visits your “HIV Treatment” service page and then submits a contact form – that combination almost certainly constitutes PHI under HIPAA, as HHS has explicitly confirmed in its December 2022 tracking technology guidance.
What HIPAA does not regulate on websites:
General health education content that does not involve identifiable patient data, publicly available information about your practice (hours, location, staff credentials), marketing content that does not involve individual patient data, and de-identified aggregate analytics data (where re-identification is not possible under HIPAA’s de-identification standards).
Who Must Comply With HIPAA on Their Website
HIPAA applies to Covered Entities and their Business Associates. In the website context:
Covered Entities who must ensure their websites are HIPAA compliant include: physician practices of any size (solo, group, and multi-specialty), dental practices, mental health and behavioral health practices, physical therapy and rehabilitation practices, chiropractic offices, optometry practices, urgent care centers, hospitals and health systems, federally qualified health centers, home health agencies, and any other provider that transmits health information electronically as part of HIPAA-covered transactions.
Business Associates operating in the website ecosystem – including web agencies, hosting providers, analytics vendors, form processors, scheduling software companies, and chat tool providers – must also meet HIPAA requirements for the data they handle on behalf of covered entities, and must sign Business Associate Agreements before receiving or processing that data.
Who is frequently wrong about their obligation: Small practices (“We’re too small for HIPAA to apply to us” – HIPAA size exemptions do not exist for covered entities), cash-only practices (“We don’t bill insurance” – HIPAA applies to the provision of healthcare regardless of payment method, though billing-specific HIPAA rules may not apply), and telehealth practices (“HIPAA is about records, not websites” – HIPAA applies to any electronic transmission of PHI).
The 20-Point HIPAA Website Checklist
Each item includes a risk classification: Critical (immediate compliance gap, highest enforcement exposure), High (significant risk requiring prompt remediation), or Medium (compliance risk that should be addressed systematically).
1. SSL Certificate Active Across All Pages
Risk Level: Critical
Every page of your website – not just the contact page – must be served over HTTPS with a valid, current SSL certificate. An HTTP page on your website creates a transmission security gap regardless of whether that specific page collects patient data. Search engines and browsers both flag non-HTTPS content.
How to verify: Check your website URL – it should begin with https://. Use SSL Labs (ssllabs.com/ssltest) to audit your SSL certificate configuration, certificate chain, and expiration date. Look for any mixed content warnings (pages that load some elements over HTTP).
Compliant: All pages served via HTTPS; SSL certificate valid and not expiring within 30 days; no mixed content warnings; SSL Labs grade of A or A+.
Non-compliant: Any page served over HTTP; expired or soon-to-expire SSL certificate; mixed content errors; SSL Labs grade below B.
2. HIPAA-Eligible Hosting With a Signed Business Associate Agreement
Risk Level: Critical
Your website hosting provider physically stores data that may include PHI – form submissions, server logs, cached pages, and uploaded documents. The hosting provider must offer HIPAA-eligible infrastructure and must sign a Business Associate Agreement with your organization before your website is deployed in that environment.
How to verify: Contact your hosting provider and request their BAA. If they don’t offer one, they are not an appropriate hosting solution for any healthcare website that handles PHI. Confirm that the specific hosting tier you are using (not just a higher tier the provider offers) is covered under the BAA.
HIPAA-eligible hosting providers with BAA availability (2026): AWS (specific services with BAA), Microsoft Azure Healthcare, Google Cloud with BAA, WP Engine (Business and above), Kinsta (Business tier and above), Liquid Web, Pantheon (Enterprise), Nexcess HIPAA-compliant plans.
Not HIPAA-eligible: Standard shared hosting (Bluehost, HostGator, GoDaddy shared), standard Squarespace, standard Wix, standard Shopify.
Compliant: Signed BAA on file with hosting provider; hosting environment explicitly covered under that BAA; HIPAA-eligible infrastructure tier confirmed.
Non-compliant: No BAA with hosting provider; hosting provider unable to provide a BAA; BAA signed but website hosted on a plan tier not covered by that BAA.
3. Contact Forms Using HIPAA-Compliant Data Handling
Risk Level: Critical
Standard contact form plugins and tools – including standard Contact Form 7, basic Gravity Forms without encryption add-ons, Google Forms, Typeform, and similar – are not HIPAA compliant for collecting patient health information. The form submission must be encrypted in transit (SSL covers this) and encrypted at rest in the storage destination, and the form processor must sign a BAA.
How to verify: Identify where your contact form data goes when submitted. Is it emailed to a standard Gmail or Yahoo address? Stored in a database without encryption? Sent to a SaaS form tool without a BAA? Any of these represents a compliance gap.
HIPAA-compliant form solutions with BAA availability: Gravity Forms with HIPAA-compliant configuration (BAA available through certain hosting environments), Formstack (HIPAA tier), JotForm (HIPAA-compliant account), HubSpot (Healthcare tier with BAA), Zoho Forms (Enterprise with BAA), Klara (healthcare-specific), NexHealth.
Compliant: Form data encrypted in transit and at rest; form processor signs BAA; form submissions not routed through non-HIPAA-compliant email delivery without appropriate safeguards; confirmation email not containing PHI in unencrypted format.
Non-compliant: Contact form data emailed as plain text to Gmail/Yahoo; form data stored in standard database without encryption; no BAA with form processing vendor.
4. Appointment Request and Online Scheduling Tools Are HIPAA Compliant
Risk Level: Critical
Online scheduling tools collect a high concentration of PHI in a single transaction – name, date of birth, reason for visit, insurance information, provider preference, and appointment time. Every scheduling tool embedded in or linked from your website must operate under a signed BAA and use appropriate data security controls.
How to verify: Identify your scheduling platform. Contact the vendor and request their BAA and HIPAA compliance documentation. Confirm that the specific plan tier you use is covered.
HIPAA-compliant scheduling platforms with documented BAA availability: Epic MyChart, athenahealth, NexHealth, Klara, Luma Health, Jane App (Canadian-based with HIPAA program), DrChrono, Zocdoc (for participating practices with BAA in place), Acuity Scheduling (Business+ with BAA).
Common non-compliant scheduling tools used by healthcare practices: Standard Calendly (no BAA), Square Appointments (verify current BAA status), standard Google Calendar integrations, non-HIPAA-configured Acuity.
Compliant: Scheduling platform signs BAA; patient data encrypted in transit and at rest; scheduling data not shared with non-BAA-covered third parties; scheduling widget embedded within HIPAA-compliant hosting environment.
Non-compliant: Scheduling tool operating without a BAA; patient scheduling data stored on servers without HIPAA-eligible infrastructure; scheduling data shared with advertising or analytics platforms.
5. Live Chat and Chatbot Tools Are HIPAA Compliant or PHI-Free
Risk Level: Critical
Live chat tools are among the most commonly overlooked HIPAA risks on healthcare websites. Most popular chat tools – Intercom, Drift, HubSpot Chat in standard configurations, Tidio, Crisp – are not HIPAA compliant and do not offer BAAs on standard plans. When a patient types “I have chest pain and need to see someone today” into your chat widget, that message may be stored on a non-HIPAA-compliant server indefinitely.
How to verify: Identify your chat tool. Check whether it stores conversation transcripts. Determine whether the vendor offers a BAA and whether you have one signed. If it stores any patient health information without a BAA, it is non-compliant.
Options: Use only HIPAA-compliant chat tools that offer signed BAAs (Klara, NexHealth messaging, Salesforce Health Cloud, Microsoft Teams Healthcare), configure non-HIPAA chat tools to handle only non-PHI inquiries (hours, directions, insurance questions without patient-identifying information) with a visible disclaimer, or remove chat tools from pages where patients are likely to share PHI.
Compliant: Chat tool vendor signs BAA; conversation data encrypted and stored in HIPAA-eligible environment; chat transcripts not shared with advertising platforms; patients informed that the channel is for general inquiries and not for PHI submission.
Non-compliant: Drift, standard Intercom, or Tidio deployed without BAA on healthcare pages where patients submit health information; no patient disclosure about the limitations of the channel.
6. Google Analytics and Tag Manager Configured for HIPAA Compliance
Risk Level: Critical
This is the most widespread HIPAA compliance gap on healthcare websites in 2026. The HHS Office for Civil Rights December 2022 bulletin explicitly warned that standard implementations of web analytics tools – including Google Analytics – may constitute impermissible disclosures of PHI when deployed on healthcare websites.
The specific PHI risks in standard Google Analytics 4 implementations:
IP address capture (an identifier that, combined with a health-related page visit or form interaction, may constitute PHI), URL parameters that reveal health conditions or treatments in page path data sent to Google servers, referral string data that contains search queries patients used to find your site (which may include condition names or symptoms), form field data capture if event tracking is configured without exclusions, and User ID or cross-device tracking when combined with any health-related behavior.
How to verify: Review your GA4 configuration. Is IP anonymization enabled? Are referral exclusions configured for sensitive pages? Are form field values excluded from event data? Is data sharing with Google advertising products enabled? Is User ID collection in place?
Compliant configuration requirements for GA4 on healthcare websites: IP anonymization enabled (GA4 handles this by default in some regions – verify), data sharing with Google advertising products disabled, referral data exclusions configured for sensitive condition and treatment pages, form field value capture explicitly excluded from event tracking, User ID collection not used without explicit de-identification, and – most importantly – a HIPAA-eligible analytics alternative considered for practices where any of the above cannot be fully controlled.
HIPAA-safe analytics alternatives: Fathom Analytics (privacy-first, no PHI exposure), Matomo (self-hosted configuration), Plausible Analytics (no personal data collection), and server-side analytics configurations that process data before sending to external tools.
Compliant: Analytics tool configured to prevent PHI capture; IP anonymization verified; no PHI-containing data shared with advertising platforms; HIPAA-safe alternative deployed or Google Analytics configured with all applicable safeguards documented.
Non-compliant: Standard GA4 implementation without privacy configuration on a healthcare website; data sharing with Google advertising enabled; form event tracking capturing field values.
7. Facebook/Meta Pixel and Advertising Pixels Removed or Properly Configured
Risk Level: Critical
The Meta Pixel (formerly Facebook Pixel) deployed on healthcare websites has been the subject of multiple high-profile investigations, class action lawsuits, and enforcement actions. When the Meta Pixel is active on a healthcare website, it transmits data about patient page visits – including condition-specific service pages, appointment scheduling page interactions, and form submission events – to Meta’s advertising systems. This transmission occurs regardless of whether the patient has a Facebook account.
The documented PHI risk: A patient who visits your “HIV Treatment” page, then your “Make an Appointment” page, then submits a form – with the Meta Pixel active throughout – has had a combination of identifiers and health-related behavior transmitted to Meta’s servers. The HHS OCR bulletin explicitly identifies this as a potential HIPAA violation category.
How to verify: Use your browser’s developer tools (Network tab) while visiting your website to identify all third-party scripts loading. Look for connect.facebook.net or fbevents.js. Use a tool like Blacklight (themarkup.org/blacklight) to scan your website for advertising trackers.
Compliant: Meta Pixel not deployed on any page of the healthcare website; OR Meta Pixel deployed only on pages that collect zero PHI (e.g., a non-healthcare-related resource or careers page) with event data configured to exclude health-related interactions; advertising pixels replaced with privacy-compliant conversion tracking alternatives.
Non-compliant: Standard Meta Pixel active on appointment pages, service pages, or any page where patients submit identifying information; Meta Pixel triggering events on form completion without PHI exclusion configuration.
8. Google Ads Conversion Tracking Configured to Exclude PHI
Risk Level: High
Google Ads conversion tracking – when implemented through standard Google Tag Manager configurations – can capture page URL data, form interaction data, and user behavior signals from appointment and contact pages. The same PHI risks that apply to Google Analytics apply to conversion tracking implementations.
How to verify: Review your Google Tag Manager container. Identify all tags firing on appointment, contact, and condition-specific pages. Verify that no form field values are included in conversion event data sent to Google Ads. Verify that URL parameters on scheduling pages are not captured in conversion data.
Compliant: Conversion events configured to fire on general appointment confirmation pages without health-specific URL parameters; no form field values included in conversion event data; enhanced conversions (which use hashed PII) implemented only after legal review; conversion tracking limited to non-PHI-containing page interactions.
Non-compliant: Conversion tracking configured to capture form field values; enhanced conversions deployed without legal review in healthcare context; conversion events firing on pages with health-condition-specific URL parameters that are transmitted to Google Ads.
9. Cookies and Tracking Scripts Managed With Consent
Risk Level: High
Beyond HIPAA, healthcare websites serving patients in California (CCPA/CPRA), the EU (GDPR), and an increasing number of US states with comprehensive privacy laws must manage cookie consent appropriately. For HIPAA purposes, tracking scripts that set cookies enabling cross-site patient tracking – and that do so without patient awareness or consent – compound PHI exposure risks.
How to verify: Audit all scripts loading on your website using browser developer tools or a tool like Cookie Metrix. Categorize each: essential (necessary for site function), functional (preferences), analytical (traffic analysis), and advertising (cross-site tracking). Determine which categories require user consent under applicable law.
Compliant: Consent Management Platform (CMP) deployed for practices serving patients in consent-required jurisdictions; essential cookies only deployed without consent; analytics and advertising cookies blocked until consent is given; cookie consent banner WCAG-accessible; consent records maintained.
Non-compliant: No consent mechanism for cookies; advertising cookies firing on page load before any patient consent; consent banner that does not actually block non-essential scripts until consent is granted (a common implementation error).
10. Patient Portal and EHR Integration Links Are Secure
Risk Level: Critical
Many practice websites link to or embed patient portals (Epic MyChart, athenahealth, FollowMyHealth, NextGen, Healow) for scheduling, records access, and messaging. These integrations must be implemented securely – specifically: links must open the portal over HTTPS, embedded portal widgets must operate within HIPAA-eligible hosting environments, and no PHI should pass through your website’s own infrastructure in the process.
How to verify: Review all patient portal links and embedded widgets. Confirm that links direct to the portal provider’s HTTPS environment directly rather than routing through your website infrastructure. Confirm that any SSO (Single Sign-On) implementations are documented in your BAA with the portal vendor.
Compliant: Patient portal links direct to HTTPS portal environment; no PHI routed through website infrastructure to reach portal; portal integration covered under BAA with portal vendor.
Non-compliant: Portal links served over HTTP; portal embed widgets loading non-HTTPS content; PHI routed through website infrastructure without appropriate safeguards.
11. Email Notification Systems for Form Submissions Are HIPAA Compliant
Risk Level: Critical
When a patient submits a contact form or appointment request, most website configurations automatically send an email notification to the practice staff. If that email notification includes the patient’s submitted data – name, reason for visit, symptoms, insurance information – and is delivered to a standard Gmail, Yahoo, or non-HIPAA-configured Microsoft 365 account, the email transmission itself constitutes a potential HIPAA violation.
How to verify: Submit a test form through your website. Examine the notification email received by the practice. Does it contain patient-submitted data? Where does it go (Gmail, Yahoo, Outlook without BAA, practice management system)?
Compliant: Form submission notifications route to a HIPAA-compliant email system (Microsoft 365 with Business Associate Agreement, Google Workspace with signed BAA, practice management system inbox); notification emails contain minimal PHI (e.g., “A new appointment request has been submitted – log in to review”); or form submissions route directly to a HIPAA-compliant practice management system without email transmission of PHI.
Non-compliant: Form notification emails containing patient PHI delivered to standard Gmail; notification emails sent through standard SMTP without encryption; form submission data emailed to personal email addresses.
12. Access Controls and Administrative Security for Website Management
Risk Level: High
Healthcare websites – particularly those built on WordPress or similar CMS platforms – require administrative access controls that meet HIPAA’s Technical Safeguard requirements under the Security Rule. If unauthorized individuals can access the website backend and view form submissions, patient data, or uploaded patient documents, that represents a security breach exposure.
How to verify: Review who has administrator access to your website CMS. Verify that all admin accounts use strong, unique passwords. Verify that two-factor authentication (2FA) is enabled for all admin accounts. Verify that former staff or former agency employees no longer have access. Review what data is accessible in the CMS admin area.
Compliant: All CMS admin accounts protected with unique strong passwords and two-factor authentication; access limited to individuals who require it (minimum necessary access principle); admin access audited and revoked promptly when staff leave; no PHI stored in unencrypted CMS database fields; admin login page protected against brute force attacks.
Non-compliant: Shared CMS admin passwords; admin accounts for former employees still active; no two-factor authentication on website admin login; form submission data including PHI accessible in CMS database without encryption.
13. Data Encryption at Rest for Form Submissions and Patient Data
Risk Level: Critical
Encryption in transit (SSL) addresses data security while data moves between the patient’s browser and your server. Encryption at rest addresses security of data stored on the server after transmission. Both are required. If patient form submissions are stored in an unencrypted database on your hosting server – even behind a secure login – they represent a breach risk that HIPAA’s Security Rule addresses.
How to verify: Ask your hosting provider or web developer: “Where is form submission data stored, and how is it encrypted at rest?” If the answer is “in the WordPress database” without specifying encryption, that is not encrypted at rest in most standard configurations.
Compliant: Form submissions containing PHI encrypted at rest using AES-256 or equivalent; database-level encryption enabled on hosting server; HIPAA-compliant form tools that handle encryption by design (Formstack, JotForm HIPAA) used; PHI not retained in website database longer than operationally necessary.
Non-compliant: Form submissions stored in standard unencrypted WordPress database; PHI stored indefinitely on website server without data retention policy; no database-level encryption on hosting server.
14. Website Security Monitoring and Intrusion Detection
Risk Level: High
HIPAA’s Security Rule requires covered entities to implement procedures to guard against and detect malicious software, to monitor activity in information systems, and to respond to security incidents. For websites, this means active security monitoring – not simply installing a security plugin and forgetting it.
How to verify: Does your website have active malware scanning? Are scan results monitored? Is there a web application firewall (WAF) in place? Are failed login attempts logged and monitored? Is there a documented incident response procedure for a potential website breach?
Compliant: Active malware scanning with monitoring and alerting (Wordfence, Sucuri, or hosting provider security tool); web application firewall active; failed login attempts monitored and auto-blocked after threshold; security scan results reviewed by a responsible party; documented security incident response procedure referencing website breach scenarios.
Non-compliant: No active malware scanning; security plugin installed but notifications ignored; no WAF; no intrusion detection; no incident response procedure for website breaches.
15. Regular Security Patching and Software Updates
Risk Level: High
Unpatched CMS software, plugins, and themes are the most common entry point for healthcare website breaches. WordPress alone accounts for a significant proportion of hacked websites globally – and most successful attacks exploit known vulnerabilities in unpatched plugins. The HIPAA Security Rule’s Technical Safeguard requirements include maintaining protection against reasonably anticipated threats to PHI security.
How to verify: Log into your website CMS and check for available updates. Are there outstanding WordPress core, plugin, or theme updates? How long have they been available? Is there a documented schedule for applying security patches?
Compliant: WordPress core, all plugins, and themes updated within 7 days of security patch release; automated update protocols in place for minor security releases; plugin inventory maintained (unused plugins removed); monthly maintenance verification documented.
Non-compliant: CMS or plugins with outstanding security updates older than 30 days; abandoned plugins no longer maintained by their developers still installed; no documented patching schedule or responsible party.
16. Website Backups – Secure, Regular, and Tested
Risk Level: High
Data backup is both a HIPAA contingency planning requirement (under the Administrative Safeguards) and a fundamental operational security control. If your website is compromised or corrupted, the ability to restore from a clean backup determines whether a security incident becomes a reportable HIPAA breach.
How to verify: Ask your hosting provider or developer: How often is the website backed up? Where are backups stored? Are backups encrypted? When was the last backup restoration tested? Are backup files stored separately from the live server (so a server compromise doesn’t also destroy the backups)?
Compliant: Daily automated backups; backups stored in a location separate from the live server; backups encrypted; restoration procedure tested at minimum annually; backup retention policy documented (30-day rolling minimum); backups included in HIPAA contingency planning documentation.
Non-compliant: No automated backups; backups stored on the same server as the live site; backup restoration never tested; no backup retention policy.
17. Business Associate Agreements With All Website Vendors
Risk Level: Critical
Every third-party vendor whose tool or service receives, stores, transmits, or processes PHI on behalf of your practice must sign a Business Associate Agreement before that relationship begins. This is not optional and cannot be retroactively applied to cover a period of prior non-compliance.
How to verify: Audit every vendor whose tool is embedded in or connected to your website. For each vendor that handles any patient data – form submissions, appointment data, chat transcripts, analytics data, email notifications – confirm that a signed BAA exists. A BAA offered as a checkbox in a vendor’s settings panel or linked in their terms of service may not constitute a valid, fully executed BAA under HIPAA. Consult your attorney on BAA validity requirements.
The complete vendor audit list for a typical healthcare website:
Table 1: HIPAA Vendor Evaluation Table
| Vendor Type | Example Tools | BAA Required? | Compliant Options |
| Web hosting | WP Engine, Kinsta, AWS, Bluehost | Yes | WP Engine Business+, Kinsta Business+, AWS with BAA |
| Form processor | Gravity Forms, JotForm, Formstack | Yes | JotForm HIPAA, Formstack HIPAA, Gravity Forms + HIPAA hosting |
| Scheduling tool | Calendly, NexHealth, Acuity | Yes | NexHealth, Klara, Acuity Business+, Zocdoc |
| Email delivery (notifications) | Mailgun, SendGrid, Gmail, Outlook | Yes | Google Workspace with BAA, M365 with BAA |
| Analytics | Google Analytics, Fathom, Matomo | GA4: Not available | Fathom, Plausible, Matomo self-hosted |
| CRM / Marketing automation | HubSpot, Salesforce | Yes (healthcare tier) | Salesforce Health Cloud, HubSpot Healthcare |
| Live chat | Drift, Intercom, Tidio | Verify per vendor | Klara, NexHealth messaging |
| CDN (Content Delivery Network) | Cloudflare, Fastly | Yes | Cloudflare (BAA available for Business+) |
| Video hosting | YouTube, Vimeo, Wistia | Use with caution | Self-hosted for PHI-adjacent content |
| Patient portal | Epic, athenahealth, FollowMyHealth | Yes | Covered under respective vendor BAA |
Compliant: Signed BAA on file for every vendor that handles PHI; BAA review date documented; BAA renewal process in place.
Non-compliant: Any vendor handling PHI without a signed BAA; BAA offered as a clickwrap terms-of-service checkbox without proper execution; BAA not reviewed since initial vendor engagement.
18. Privacy Policy Accurate, Current, and Accessible
Risk Level: Medium
Your website’s privacy policy must accurately describe how you collect, use, store, and protect patient information through the website – and it must be accessible from every page of the site. A privacy policy that describes HIPAA compliance while your actual practices don’t support those claims creates both regulatory and legal exposure.
How to verify: Read your current privacy policy. Does it accurately describe how your contact forms work? Does it mention the analytics tools you use? Does it reflect your current hosting and data handling practices? Is it linked from the footer of every page? Was it last updated after the HHS October 2022 tracking technology guidance?
Compliant: Privacy policy accurately describes all data collection, use, and sharing practices; updated post-2022 to reflect tracking technology guidance; linked from footer of every page; includes HIPAA Notice of Privacy Practices reference (or incorporates NPP content for single-page practices); includes contact information for submitting privacy concerns.
Non-compliant: Privacy policy that doesn’t accurately reflect current data practices; last updated before 2022 (likely missing tracking technology considerations); not accessible from all pages; generic template policy not customized to actual practices.
19. HIPAA Notice of Privacy Practices Integration
Risk Level: Medium
HIPAA’s Privacy Rule requires covered entities to provide patients with a Notice of Privacy Practices (NPP). For practices with websites, the website is an appropriate – and for many patients the primary – channel for NPP delivery. The NPP must be available on the website, easily accessible, and linked from relevant points in the patient journey.
How to verify: Is your current, accurate NPP available on your website? Is it linked from your privacy policy, your contact/appointment pages, and your footer? Is it the current version reflecting your actual practices?
Compliant: Current NPP accessible on website (dedicated page or downloadable PDF); NPP linked from footer, contact page, and appointment request pages; NPP content reviewed and updated within the last 12 months; NPP references website data collection practices.
Non-compliant: No NPP on website; outdated NPP not reflecting current practices; NPP not linked from appointment and contact pages where patients submit PHI.
20. Data Retention and Destruction Policy for Website-Collected PHI
Risk Level: High
HIPAA requires covered entities to have policies for retaining PHI for the minimum necessary period and disposing of it securely when no longer needed. For websites, this applies to: form submissions stored in the CMS database or hosting environment, appointment request data stored by third-party scheduling tools, and any patient-submitted documents or health history forms.
How to verify: Determine how long patient data submitted through your website is retained. Is there a policy? Is it enforced? Is PHI collected through the website that is no longer needed actually deleted from the hosting environment?
Compliant: Documented retention policy for website-collected PHI (minimum necessary principle applied); form submission data purged from website server after transfer to practice management system; automated deletion schedules in place for temporary form data storage; data destruction method documented (secure deletion, not simple file deletion).
Non-compliant: No data retention policy for website-collected PHI; form submissions accumulating in CMS database indefinitely; no process for transferring web form PHI to practice management system and deleting from website environment.
HIPAA Requirement vs. Website Component
Table 2: HIPAA Rule Mapping to Website Components
| HIPAA Rule | Specific Requirement | Website Component Affected | Implementation |
| Security Rule – Technical Safeguard | Transmission security | All pages, forms, scheduling | SSL/HTTPS across entire site |
| Security Rule – Technical Safeguard | Encryption and decryption | Form submissions, stored data | Encryption at rest on hosting server |
| Security Rule – Technical Safeguard | Audit controls | Admin access, form access | Access logs, 2FA, admin audit trail |
| Security Rule – Technical Safeguard | Automatic logoff | CMS admin access | Session timeout on admin login |
| Security Rule – Technical Safeguard | Authentication | CMS, portal integrations | Strong passwords + 2FA for all admin |
| Security Rule – Administrative Safeguard | BAA with Business Associates | All third-party vendors | Vendor audit + signed BAAs |
| Security Rule – Administrative Safeguard | Contingency plan | Website data backup | Encrypted off-site daily backups |
| Security Rule – Administrative Safeguard | Security awareness | Web agency, staff | Documented security training |
| Security Rule – Administrative Safeguard | Incident response | Security breach on website | Documented breach response procedure |
| Security Rule – Physical Safeguard | Workstation security | CMS admin access devices | Device-level security for admin users |
| Privacy Rule | Minimum necessary | Analytics, form data | Data minimization in collection |
| Privacy Rule | Permitted uses and disclosures | Pixels, analytics sharing | Pixel removal; analytics data sharing disabled |
| Privacy Rule | Notice of Privacy Practices | Patient-facing pages | NPP accessible and linked from site |
| Breach Notification Rule | Breach identification | Security monitoring | Active monitoring with alert protocols |
| Breach Notification Rule | Breach reporting | Incident response | Documented 60-day notification procedure |
Compliant vs. Non-Compliant: Real-World Examples
Table 3: Compliant vs. Non-Compliant Website Implementations
| Scenario | Non-Compliant | Compliant |
| Contact form | Standard Contact Form 7 with email notification to Gmail | JotForm HIPAA form with encrypted storage; notification routes to Google Workspace with BAA |
| Analytics | Standard GA4 with advertising data sharing enabled | GA4 with IP anonymization, advertising sharing disabled, and Fathom Analytics as PHI-safe alternative |
| Pixel tracking | Meta Pixel active on appointment scheduling page | Meta Pixel removed from all healthcare pages; server-side conversion tracking via CAPI reviewed by counsel |
| Hosting | Shared GoDaddy hosting with no BAA | WP Engine Business with signed BAA and HIPAA-eligible infrastructure |
| Live chat | Standard Drift widget collecting patient name and reason for visit | Klara messaging (HIPAA-compliant) OR Drift configured for non-PHI inquiries only with visible disclaimer |
| Appointment scheduling | Standard Calendly (no BAA) embedded in website | NexHealth scheduling with signed BAA and HIPAA-eligible data storage |
| Email notification | Form submission data emailed as plain text to practice Gmail | Form submissions route to HIPAA-configured PMS; email notification contains only “New submission received – log in to review” |
| Backup | No automated backup; manual backups every few months | Daily automated encrypted backups stored off-server; tested quarterly |
| Access control | Shared WordPress admin password; former web agency still has access | Individual admin accounts with 2FA; former vendor access revoked; admin access audit log reviewed monthly |
| Privacy policy | Generic 2019 template privacy policy with no mention of analytics tools | Custom privacy policy updated post-2022; accurately describes all tracking tools and data handling; linked from all pages |
| BAA audit | Hosting and scheduling vendors in use without BAAs | Full vendor inventory with BAA status; all PHI-adjacent vendors have signed BAAs on file |
| SSL | Valid SSL certificate on main domain; no SSL on mobile subdomain | SSL active across all subdomains and pages; SSL Labs grade A |
Website Risk Assessment Matrix
Use this matrix to prioritize remediation based on both likelihood of violation and severity of consequence.
Table 4: Website Risk Assessment Matrix
| Compliance Item | PHI Exposure Likelihood | Breach Severity | Enforcement Risk | Remediation Priority |
| Meta Pixel on appointment pages | Very High | High | Critical (active investigations) | Immediate |
| GA4 without HIPAA safeguards | High | High | High (OCR guidance exists) | Immediate |
| No BAA with hosting provider | High | Very High | Critical | Immediate |
| Unencrypted form submissions | High | Very High | Critical | Immediate |
| Scheduling tool without BAA | High | High | High | Immediate |
| Live chat without BAA | High | Medium | High | Within 30 days |
| No SSL across all pages | Medium | High | High | Immediate |
| Email notification routing PHI to Gmail | Medium | High | High | Within 30 days |
| No website security monitoring | Medium | High | Medium | Within 30 days |
| Unpatched CMS/plugins | Medium | High | Medium | Within 14 days |
| No data retention policy | Medium | Medium | Medium | Within 60 days |
| Cookie consent missing | Medium | Medium | Medium (varies by state) | Within 60 days |
| Outdated privacy policy | Low-Medium | Medium | Medium | Within 60 days |
| NPP not accessible on website | Low | Medium | Medium | Within 60 days |
| Admin access controls insufficient | Medium | High | High | Within 14 days |
| No regular backups | Low | Very High | Medium | Within 14 days |
| EHR/portal integration gaps | Medium | High | High | Within 30 days |
| No access log or audit trail | Low | Medium | Medium | Within 60 days |
| Advertising pixel on general pages | Low | Low | Low | 60-90 days |
| BAA not current / not executed properly | High | High | High | Within 30 days |
Common HIPAA Website Compliance Mistakes
Mistake 1: Assuming “we don’t have a patient portal” means no website HIPAA risk. A patient portal is not required to create HIPAA risk on a website. A standard contact form that asks for a patient’s name, phone number, and reason for visit – followed by an automated email containing that information sent to a standard Gmail account – is a HIPAA violation. The presence or absence of a patient portal is irrelevant to the HIPAA risk created by basic web forms.
Mistake 2: Relying on a web agency’s verbal assurance of HIPAA compliance. “Our websites are HIPAA compliant” is not a HIPAA compliance posture – it is a marketing claim. Before accepting any agency’s assurance, request documentation: which hosting provider they use, whether that provider offers a BAA, which form solution they use and whether it has a BAA, and how they configure analytics. If they cannot answer these questions with specificity, they are not equipped to build a HIPAA-compliant website.
Mistake 3: Installing a security plugin and considering the job done. A WordPress security plugin (Wordfence, iThemes Security) provides valuable technical controls – malware scanning, login protection, firewall – but it does not make a website HIPAA compliant. It addresses one component of the Security Rule. HIPAA compliance requires addressing the Administrative, Physical, and all Technical Safeguards, plus the Privacy Rule requirements and BAA requirements, simultaneously.
Mistake 4: Not auditing website compliance after vendor changes. A practice may have achieved HIPAA compliance at website launch, then switched hosting providers, added a chat widget, or installed a new scheduling tool without evaluating HIPAA implications. Website compliance is not a one-time achievement – it is a continuous state that requires re-evaluation whenever vendor relationships change.
Mistake 5: Thinking that because advertising pixels are “industry standard” they’re acceptable. The HHS OCR 2022 guidance was explicit: widespread industry use of tracking technologies does not make their use on healthcare websites HIPAA-compliant. The covered entity bears responsibility for their deployment decisions regardless of how common those decisions are in general digital marketing practice.
Mistake 6: Considering only federal HIPAA while ignoring state-level requirements. Several states – including California (CMIA, CCPA/CPRA), New York (SHIELD Act), Texas (THIPA), Virginia (VCDPA), and others – have enacted healthcare data privacy laws that in some cases exceed HIPAA’s requirements. A healthcare website that is HIPAA-compliant may still violate state law depending on patient geography. Multi-state practices should have state-specific privacy obligations reviewed by counsel.
Mistake 7: Not having a HIPAA-compliant option for patient-initiated contact. Some practices, attempting to avoid PHI exposure through their website, remove all contact forms and scheduling tools – leaving only a phone number. While this eliminates the digital collection risk, it creates an operational problem: patients who prefer digital contact will not call. The solution is not to avoid digital contact channels but to implement them with proper HIPAA safeguards.
Mistake 8: Using YouTube embeds on HIPAA-sensitive pages. Embedded YouTube videos set cookies and may collect viewer data. While a YouTube embed of a general practice overview video on your homepage is unlikely to create meaningful HIPAA risk, embedding video content on condition-specific pages (a video about HIV treatment on your HIV services page, for example) creates potential PHI exposure through the combination of viewer identification data and health-related context. Self-hosted video or HIPAA-reviewed platforms should be used for video content on sensitive condition pages.
HIPAA Website Audit Framework: Conducting Your Own Review
Step 1: Inventory All Website Components
Before evaluating compliance, create a complete inventory. List every tool, platform, and vendor connected to your website: CMS, hosting, form tools, scheduling platforms, analytics, advertising pixels, chat tools, CDN, email notification systems, patient portal integrations, and any SaaS widget embedded in any page.
Step 2: Map Each Component to PHI Exposure
For each component, answer: Does this component receive, process, store, or transmit patient-identifiable information? The answer may not always be obvious – your analytics platform receives IP addresses and page visit data that may constitute PHI when combined with health-related page visits.
Step 3: Verify BAA Status for Each PHI-Adjacent Vendor
For every component that touches PHI, confirm whether a signed BAA is in place. If not, this is your highest-priority remediation action.
Step 4: Test Each PHI Collection Point
Submit test data through every form, scheduling widget, and chat tool on your website. Follow the data: Where does it go? How is it stored? What email notification is generated? Does that notification contain PHI? Where does it arrive?
Step 5: Run Technical Security Verification
Use SSL Labs to verify SSL configuration. Use browser developer tools or Blacklight to identify all tracking scripts. Use Google PageSpeed Insights to identify any third-party scripts creating performance or privacy issues. Review your CMS admin panel for outstanding security updates.
Step 6: Review Legal Documentation
Gather all signed BAAs. Review your privacy policy against your actual practices. Confirm your Notice of Privacy Practices is current and accessible. Review your data retention and destruction policies.
Step 7: Document Gaps and Assign Remediation Ownership
Every compliance gap identified should be documented: what the gap is, which HIPAA rule it implicates, what the remediation action is, who is responsible for remediation, and the target completion date.
Step 8: Establish a Recurring Audit Schedule
HIPAA website compliance requires ongoing maintenance. Establish a quarterly review of BAA status and vendor list, semi-annual technical security audit, annual comprehensive HIPAA website compliance review, and an immediate review trigger whenever new website vendors or tools are added.
Frequently Asked Questions
- Does HIPAA apply to my practice website?
HIPAA applies to your website if your practice is a covered entity and your website collects, transmits, or stores any information that qualifies as PHI – including information submitted through contact forms, appointment requests, chat tools, or scheduling widgets. The fact that your website is a public-facing marketing tool does not exempt it from HIPAA’s requirements when it is used as a channel for patient communication or data collection.
- What triggers a HIPAA investigation related to a website?
HIPAA investigations related to websites most commonly arise from three sources: patient complaints (a patient discovers their health information was shared with advertising platforms), OCR audit selection (the HHS Office for Civil Rights conducts periodic audits of covered entities), and breach notification events (a website hack or data exposure that triggers mandatory breach reporting). The HHS 2022 guidance on tracking technologies has also prompted OCR to give increased scrutiny to analytics and pixel practices on healthcare websites.
- What is a Business Associate Agreement and do I need one for my web hosting company?
A Business Associate Agreement is a legally required contract under HIPAA between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on the covered entity’s behalf. If your hosting provider stores server-side form submissions, server logs, or any other data that could constitute PHI, they are a Business Associate and must sign a BAA before your website is deployed in their environment. Yes – you need a BAA with your hosting company.
- Does Google offer a Business Associate Agreement for Google Analytics?
Google offers a BAA for certain Google Workspace (Gmail, Drive, Calendar) services, but does not offer a BAA for Google Analytics or Google Ads. This is one of the central reasons that standard Google Analytics is not HIPAA-compliant for healthcare websites, regardless of configuration. Privacy-respecting analytics alternatives (Fathom, Plausible, Matomo self-hosted) are the recommended path for healthcare websites that require HIPAA-safe analytics.
- Can I still use the Meta Pixel on my healthcare website?
Use of the Meta Pixel on healthcare websites has been the subject of explicit HHS OCR guidance (December 2022) warning of potential HIPAA violations, multiple class action lawsuits, and significant regulatory and legal risk. Most healthcare privacy attorneys advise removing the Meta Pixel from healthcare websites entirely. If advertising measurement is required, privacy-compliant server-side conversion API (CAPI) configurations reviewed by HIPAA-qualified counsel are a potential alternative – but this is an area of active legal development that requires case-specific legal guidance, not a generic checklist recommendation.
- Is my website HIPAA compliant if I only have a phone number on my contact page and no forms?
A website with only a phone number and no forms, scheduling widgets, or chat tools has significantly lower HIPAA risk – but is not necessarily fully compliant. Analytics tools that capture IP addresses in combination with health-related page visits may still create PHI exposure. The website must still be hosted on HIPAA-eligible infrastructure with a BAA, particularly if the website is in any way associated with the practice’s PHI-handling systems. Complete HIPAA risk elimination on a website requires more than form removal.
- What is the penalty for a HIPAA violation on a website?
HIPAA civil monetary penalties for violations discovered in 2026 range from $141 to $71,162 per violation, with annual maximums up to $2,134,831 per violation category, depending on culpability level. Violations resulting from willful neglect – which includes having knowingly deployed non-compliant tracking technologies after the HHS 2022 guidance – carry the highest penalty tiers. Fines are cumulative across violation categories and can reach tens of millions of dollars for systemic failures. Criminal penalties (up to 10 years imprisonment) apply in cases of knowing misuse of PHI.
- What is the difference between a HIPAA Notice of Privacy Practices and a website privacy policy?
A HIPAA Notice of Privacy Practices (NPP) is a legally required document under HIPAA’s Privacy Rule that describes how a covered entity uses and discloses PHI and patients’ rights regarding their health information. A website privacy policy is a broader disclosure document describing how the website specifically collects, uses, and protects visitor information – including non-PHI data like analytics. Healthcare organizations need both: an NPP (accessible on the website) and an accurate, current website privacy policy that reflects actual data practices including tracking tool use.
- Does HIPAA apply to my dental or mental health practice website?
Yes. HIPAA applies to any covered entity, including dental practices, mental health providers, behavioral health practices, physical therapy offices, and all other healthcare providers that conduct HIPAA-covered transactions electronically. The type of healthcare provided does not determine HIPAA coverage – the practice’s status as a covered entity and its electronic handling of patient information does. Mental health practices have an additional sensitivity consideration: mental health information carries among the highest patient harm potential if disclosed, making compliance particularly important.
- How often should I audit my website for HIPAA compliance?
A minimum annual comprehensive HIPAA website audit is necessary. Additionally, audits should be triggered whenever: a new third-party tool or vendor is added to the website, a new website feature involving patient data is launched, a vendor changes their terms of service or data handling practices, HHS issues new guidance on website compliance, or a security incident is detected on the website. The 2022 HHS tracking technology guidance is an example of a regulatory development that should have triggered an immediate re-audit for any healthcare organization.
- What should I do if I discover my website has been HIPAA non-compliant?
First, assess what PHI was potentially exposed and for how long. Second, remediate the compliance gap immediately – remove or properly configure the non-compliant element. Third, determine whether the exposure constitutes a reportable breach under HIPAA’s Breach Notification Rule (PHI disclosure that was not permitted, not excepted, and not low probability of compromise). Fourth, consult HIPAA-qualified legal counsel before self-determining that no breach notification is required. Fifth, document the discovery, assessment, remediation, and legal consultation for your HIPAA compliance file.
- Is Squarespace or Wix appropriate for a healthcare website?
Standard Squarespace and Wix plans are not appropriate for healthcare websites that collect patient information, as neither platform offers a Business Associate Agreement on standard plans. Squarespace has historically not offered BAAs; Wix similarly lacks HIPAA-eligible infrastructure commitments for standard accounts. Healthcare practices require hosting environments that can sign a BAA and operate HIPAA-eligible infrastructure – which points toward managed WordPress hosting, cloud providers with healthcare BAA programs, or healthcare-specific website platforms.
- What is the safest analytics tool for a healthcare website in 2026?
Fathom Analytics and Plausible Analytics are the most commonly recommended HIPAA-safe web analytics alternatives for healthcare websites. Both are privacy-first platforms that do not collect personal data, do not use cookies that track individuals, and process all data in aggregate – eliminating the PHI exposure risk of traditional analytics tools. Matomo (self-hosted) is another option that can be configured to comply with HIPAA when deployed on HIPAA-eligible hosting with appropriate data isolation. None of these tools replaces the full functionality of GA4, but all provide actionable traffic and conversion data without HIPAA compliance risk.
- Can my web agency manage my HIPAA compliance?
A qualified healthcare-specialist web agency can implement the technical components of HIPAA website compliance – HIPAA-eligible hosting with BAA, compliant form solutions, analytics configuration, pixel removal, access controls, security monitoring, and patching protocols. However, HIPAA compliance responsibility for the covered entity cannot be delegated to a web agency. The practice remains the covered entity and is ultimately responsible for ensuring compliance. The web agency is a Business Associate – and should sign a BAA with your practice before handling any aspect of your website that touches PHI.
- What is the HHS 2022 tracking technology bulletin and why does it matter?
In December 2022, the HHS Office for Civil Rights issued a bulletin titled “Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates.” The bulletin explicitly stated that tracking technologies – including Google Analytics, Meta Pixel, and other web analytics and advertising tools – deployed on healthcare websites may constitute impermissible disclosures of PHI when they transmit individually identifiable information to tracking technology vendors. The bulletin clarified that IP addresses, combined with health-related page visits or form interactions, can constitute PHI. This guidance fundamentally changed the HIPAA risk landscape for healthcare website analytics and advertising tracking, and any healthcare website audit should evaluate compliance against this guidance.
Final Recommendations
Remediate in order of risk, not order of convenience. The highest-risk compliance gaps – tracking pixels on patient pages, unencrypted form submissions, missing BAAs, and standard analytics without HIPAA configuration – should be addressed within days of identification, not scheduled into the next website redesign cycle.
Get legal guidance on breach exposure before self-determining no notification is required. If your audit reveals that PHI was potentially transmitted to a third party (through a pixel, analytics tool, or form submission to an uncovered email system) without a BAA, that fact pattern may meet HIPAA’s definition of a reportable breach. The decision to self-determine that breach notification is not required should never be made without counsel.
Treat HIPAA compliance as infrastructure, not a project. The practices with the strongest HIPAA website posture are not the ones who completed a HIPAA audit once – they are the ones who built compliance into their website operations: quarterly vendor BAA reviews, monthly security patch protocols, immediate impact assessment for any new vendor addition, and an annual comprehensive audit on a calendar.
Document everything. HIPAA enforcement actions rarely result from regulators discovering violations proactively. They arise when a complaint or breach event forces scrutiny of practices over time. An organization that can demonstrate documented, good-faith compliance efforts – even if imperfect – is in a materially better position than one with no compliance documentation at all. Every BAA, every audit, every remediation action should be documented and retained.
The cost of compliance is trivial compared to the cost of non-compliance. HIPAA-eligible hosting costs $50–$150/month more than shared hosting. A HIPAA-compliant form solution costs $20–$80/month more than a free plugin. Removing the Meta Pixel costs nothing – and eliminates one of the most documented HIPAA risks on healthcare websites in 2026. The financial and reputational cost of an enforcement action, a breach, or a class action lawsuit is several orders of magnitude greater than the cost of the compliant infrastructure.
Why Healthcare Organizations Work With DevRivo for HIPAA-Compliant Website Design
DevRivo builds medical and dental websites with HIPAA compliance as a foundational architectural requirement – not an afterthought or a checkbox. Every website DevRivo delivers includes documented BAA coverage with the hosting provider and form processor, HIPAA-safe analytics configuration, tracking pixel management, encrypted form handling, access controls, and security monitoring protocols.
Practices that have audited their current website against this checklist and identified compliance gaps can request a HIPAA website compliance review from DevRivo’s team.
Start with a consultation at devrivo.com.