How to Build a Website That Is HIPAA Compliant

A Health Insurance Portability and Accountability Act (HIPAA)-compliant website protects patients’ health information across its forms, portals, databases, vendors, and tracking tools, not just its servers.

The risk goes beyond OCR enforcement.

Advocate Aurora Health reached a $12.225 million private class-action settlement covering more than 2.5 million people, while Novant Health reached a $6.66 million settlement over Meta Pixel-related disclosures affecting about 1.3 million people. Neither settlement was an admission of wrongdoing.

This guide explains how to determine whether HIPAA applies to your website, which rules govern it, how to build the necessary safeguards, and what common mistakes can expose protected health information (PHI).

It also includes a step-by-step process, a HIPAA-compliant website checklist, and realistic build and operating costs.

What Makes a Website HIPAA Compliant?

A HIPAA-compliant website collects, stores, transmits, or displays PHI using the safeguards required by HIPAA. It must also have written BAAs with vendors that create, receive, maintain, or transmit PHI on the organization’s behalf.

For electronic protected health information (ePHI), the HIPAA Security Rule requires reasonable and appropriate:

• Administrative safeguards, such as risk assessments, policies, and staff training
• Physical safeguards, such as controls protecting devices and hosting facilities
• Technical safeguards, such as access controls, audit logs, and secure transmission

These measures must protect the confidentiality, integrity, and availability of ePHI.

HIPAA compliance is not a badge, hosting plan, or plugin you can purchase. It depends on how the entire system handles PHI, including:

• Forms and file uploads
• Databases and backups
• User accounts and permissions
• Email, chat, and notification tools
• Analytics and tracking technologies
• Vendors, policies, and documentation

A public marketing site that neither collects nor discloses PHI has different requirements from an intake form, appointment system, telehealth service, or patient portal.

Tracking tools can also create compliance problems when they send PHI to third parties without the required permission and BAA.

On unauthenticated public pages, however, an IP address combined only with a visit to a page about a health condition or provider is not automatically PHI. A federal court vacated that portion of HHS’s tracking guidance in 2024.

The analysis still depends on what information is transmitted and whether it relates to an identifiable person’s health, care, or payment.

How to Tell If Your Website Falls Under HIPAA

HIPAA applies to websites operated by or on behalf of a covered entity or business associate.

Covered entities include health plans, health care clearinghouses, and health care providers that conduct certain standard transactions electronically.

Business associates are companies or individuals that handle PHI while providing services to a covered entity, including many healthcare software, hosting, billing, and technology vendors.

You likely need HIPAA-compliant handling if your website performs any of these functions for a covered entity or business associate:

• Collects symptoms, diagnoses, treatment details, or insurance information through a form
• Lets patients request or schedule appointments
• Provides a patient portal or telehealth service
• Accepts medical records, images, or other file uploads
• Uses live chat or a chatbot that may receive health information
• Displays prescriptions, test results, invoices, or treatment history
• Lets users submit support requests containing health details
• Collects or publishes reviews and testimonials that identify a patient and their treatment
• Sends identifiable health information to analytics, advertising, or tracking vendors

A contact form can collect PHI even when it appears on an otherwise public marketing website.

For example, asking for someone’s name and what medical issue brought them to the practice may connect an identifiable person with information about their health or care.

Two common assumptions cause problems:

1. A HIPAA-eligible host does not make the entire website compliant. Your forms, databases, access controls, analytics, vendors, policies, and BAAs must also meet the applicable requirements.
2. Calling it a marketing website does not exempt the information it collects. The actual data flow matters more than the label placed on the site.

Organizations that are not covered entities or business associates may not fall under HIPAA, although other federal or state health privacy laws can still apply.

The Four HIPAA Rules That Apply to Your Website

Four HIPAA rules shape how a healthcare website collects, protects, shares, and responds to incidents involving PHI.

The Privacy Rule

The Privacy Rule governs how PHI may be used and disclosed and gives patients rights over their information.

For a website, this means:

• Collecting only the PHI needed for the stated purpose
• Clearly explaining how patient information will be used
• Limiting access and disclosures to authorized people and vendors
• Avoiding unauthorized disclosures to analytics or advertising platforms

A form should not request detailed medical information when basic contact information is enough.

Third-party trackers are also a concern when they receive identifiable health information without proper authorization or safeguards.

The Security Rule

The Security Rule protects ePHI through three categories of safeguards:

• Administrative: Risk assessments, security policies, staff training, and incident procedures
• Physical: Controls protecting devices, offices, servers, and data centers
• Technical: Authentication, access controls, encryption, audit logs, and secure transmission

These safeguards must protect the confidentiality, integrity, and availability of ePHI. Most of the technical build requirements for a HIPAA-compliant website come from this rule.

The Breach Notification Rule

A breach is generally an unauthorized use or disclosure of unsecured PHI that compromises its privacy or security.

Affected individuals must be notified without unreasonable delay and no later than 60 days after discovering a reportable breach.

The US Department of Health and Human Services (HHS) must also be notified, while breaches affecting more than 500 residents of a state or jurisdiction may require notice to prominent local media.

Improper disclosures through website trackers may trigger these duties unless a documented risk assessment determines that there is a low probability the PHI was compromised.

The Enforcement Rule

The Enforcement Rule gives the HHS Office for Civil Rights (OCR) authority to investigate complaints, conduct compliance reviews, require corrective action, negotiate settlements, and impose civil monetary penalties.

Penalties depend on the organization’s level of responsibility and whether it corrected the violation.

For penalties assessed on or after January 28, 2026, amounts range from a minimum of $145 per violation for cases involving no knowledge to a maximum of $2,190,294 per violation for uncorrected willful neglect.

OCR commonly asks for evidence such as:

• Written risk assessments
• Security policies and procedures
• Signed BAAs
• Access and audit records
• Staff training documentation
• Incident-response and breach-notification records

Technical safeguards matter, but organizations must also be able to show that they evaluated risks, implemented controls, and documented their compliance work.

Can You Use Wix, Squarespace, or WordPress for a HIPAA-Compliant Website?

You can use some mainstream website builders for a HIPAA-compliant website, but only under specific plans and configurations.

A standard account, Secure Sockets Layer (SSL) certificate, or security plugin is not enough.

Wix can support HIPAA compliance on eligible paid plans after you enable PHI protection and sign its BAA. Third-party apps and integrations remain your responsibility.

Squarespace supports HIPAA-enabled Acuity Scheduling only on the Powerhouse or Premium plan after the BAA is signed. The BAA does not cover the main Squarespace website platform or its standard form features.

WordPress.com does not offer a BAA. Self-hosted WordPress can run in a HIPAA-eligible environment, but every host, plugin, form, backup, and vendor that handles PHI must also meet the requirements.

When a builder cannot safely handle PHI, you can either:

• Keep the public website informational and connect it to a separate compliant form, scheduler, or portal.
• Build a full-stack application you control in a HIPAA-eligible environment.

Packaged builders are faster, while a custom build gives you more control over the code, infrastructure, access, and audit logging.

Neither route is automatically compliant without proper configuration, BAAs, policies, and risk assessments.

How to Make a Website HIPAA Compliant: Step-by-Step

Learning how to make a website HIPAA compliant starts with understanding where PHI moves through the system.

Each step below addresses a specific privacy, security, or vendor risk.

1. Map where PHI enters, moves, and is stored.
2. Choose HIPAA-eligible vendors and sign BAAs.
3. Encrypt PHI in transit and at rest.
4. Add authentication, roles, and access controls.
5. Secure forms, uploads, intake tools, and chat.
6. Remove unsafe analytics and tracking tools.
7. Turn on audit logging and monitoring.
8. Back up PHI and define retention and disposal rules.
9. Complete a risk assessment and document your safeguards.

Step 1. Map Where PHI Flows

List every place where PHI enters, moves, rests, or leaves the website.

Include:

• Intake and contact forms
• Patient portals
• Appointment scheduling
• Chat and support tools
• File uploads
• Databases and backups
• Emails and notifications
• Analytics and advertising tools
• Third-party integrations

For each point, record what data is collected, where it goes, who can access it, and which vendor processes it. This map becomes the foundation of your security risk assessment.

Step 2. Choose HIPAA-Eligible Hosting and Sign BAAs With Every Vendor

Choose hosting that supports the safeguards your risk assessment requires, including access controls, backups, monitoring, and encryption.

A cloud provider that stores or processes ePHI on your behalf is generally a business associate, even when it stores only encrypted information and cannot access the encryption key.

You must sign a BAA before giving that vendor access to PHI.

Review every vendor that creates, receives, maintains, or transmits PHI, including:

• Hosting and database providers
• Form and file-storage services
• Email and notification platforms
• Chat and support tools
• Analytics providers
• Backup and monitoring services

A BAA does not make a poorly configured service compliant, but a vendor that qualifies as a business associate generally cannot handle PHI without one.

Step 3. Encrypt PHI in Transit and at Rest

Use Hypertext Transfer Protocol Secure (HTTPS) and modern Transport Layer Security (TLS) across the entire website, not only the login page. Encrypt databases, file storage, backups, and other locations where ePHI is stored.

Keep encryption keys separate from the encrypted data and restrict access to them.

Encryption is currently an addressable implementation specification under the Security Rule, meaning you must assess whether it is reasonable and appropriate and document your decision.

Properly encrypted PHI may also qualify for breach-notification safe harbor when the decryption key has not been compromised.

Step 4. Add Authentication, Roles, and Access Controls

Give every user a unique account rather than sharing credentials. Apply role-based access controls so people can reach only the information required for their work.

For example:

• Patients can access only their own records.
• Clinicians can access records for patients under their care.
• Billing staff can view payment details without seeing unnecessary clinical information.
• Administrators receive only the system access their duties require.

Add multi-factor authentication (MFA) for administrators and anyone who can access PHI.

The current Security Rule requires access controls, unique user identification, and identity verification, although HHS’s proposal to make MFA expressly mandatory remains a proposed rule as of July 2026.

Remove access promptly when someone leaves the organization or changes roles.

Step 5. Secure Forms, Uploads, and Intake or Chat

Any form, upload field, or conversation that may contain health information must send the data securely to an approved system.

Check that:

• The form submits through an encrypted connection.
• Its vendor will sign a BAA when required.
• PHI is not copied into an unsecured inbox.
• Uploaded files use protected storage.
• Access is limited to authorized users.
• Temporary files and form logs do not expose PHI.

A basic contact form can collect PHI when it asks for a person’s identity and symptoms, treatment needs, or appointment details.

Do not send that information through a generic form provider or email platform that cannot support your HIPAA obligations.

Step 6. Fix Your Analytics and Tracking

Audit every script, pixel, cookie, session-recording tool, and advertising tag running on the website.

Google states that it does not offer a BAA for Google Analytics and instructs HIPAA-regulated customers not to expose PHI to the service. Google Analytics should therefore be removed from authenticated pages and any other page where its tags could collect PHI.

Apply the same review to Meta Pixel, advertising tags, chat widgets, and session-recording tools.

HHS requires regulated organizations to evaluate whether tracking vendors receive PHI and, when the vendor acts as a business associate, ensure the disclosure is permitted and covered by a BAA.

Use a provider that supports your compliance requirements or a self-hosted analytics system that keeps the data under your control.

Step 7. Turn On Audit Logging and Monitoring

Audit logs should record activity involving systems that contain or use ePHI.

Capture details such as:

• Who accessed the system
• Which record or file they opened
• What they created, changed, downloaded, or deleted
• When the activity occurred
• Failed login attempts and permission changes

HIPAA requires mechanisms for recording and examining activity in systems containing ePHI. Review the logs regularly and configure alerts for suspicious access, unusual downloads, and repeated authentication failures.

Protect the logs from unauthorized changes and avoid recording unnecessary PHI inside them.

Step 8. Back Up PHI and Set Retention and Disposal Rules

Create encrypted backups and maintain a tested process for restoring lost data.

HIPAA’s contingency-plan requirements include data backup, disaster recovery, emergency operations, and periodic testing.

Define:

• How frequently backups run
• Where backups are stored
• Who can restore them
• How recovery procedures are tested
• When records should be archived or deleted
• How PHI is removed from old devices, test systems, and storage

HIPAA does not set one universal retention period for all medical records. Follow applicable federal and state requirements, while securely disposing of PHI once it no longer needs to be retained.

Step 9. Run a Risk Assessment and Document Everything

Complete a written risk analysis that identifies where ePHI is stored, the threats and vulnerabilities affecting it, the likelihood and impact of those risks, and the actions required to reduce them.

HHS describes risk analysis as the foundation for selecting appropriate Security Rule safeguards.

It should be updated when technology, vendors, workflows, or risks change rather than treated as a one-time exercise.

Keep records of:

• Risk assessments and remediation work
• Security policies and procedures
• Signed BAAs
• Staff training
• Access reviews
• Incident-response plans
• Backup and recovery tests
• Security incidents and corrective actions

Required Security Rule documentation must generally be retained for six years after the later of its creation date or the date it was last in effect.

A secure technical build is only part of compliance.

You must also be able to demonstrate how risks were identified, which safeguards were chosen, and how those safeguards are maintained.

HIPAA-Compliant Website Checklist

Use this HIPAA-compliant website checklist to identify gaps in how your site handles PHI.

Hosting and vendors

• Use hosting that can support your HIPAA security requirements.
• Sign a BAA with every vendor that creates, receives, maintains, or transmits PHI.
• Confirm that databases, storage, backups, email, chat, and monitoring tools are covered.
• Review third-party plugins and integrations before giving them access to PHI.

Data protection

• Use HTTPS and modern TLS across the entire website.
• Encrypt PHI stored in databases, files, and backups.
• Protect encryption keys separately from the data.
• Maintain encrypted backups and test the recovery process.
• Remove PHI securely when it no longer needs to be retained.

Access controls

• Give every user a unique login.
• Apply role-based access so users see only the PHI needed for their work.
• Enable MFA for administrators and other high-risk access.
• Remove access promptly when employees leave or change roles.
• Review user permissions regularly.

Forms, uploads, and communication

• Send form submissions and uploads through encrypted connections.
• Store submitted PHI only in approved systems.
• Avoid sending PHI to unsecured email inboxes.
• Secure chat, appointment, and intake tools that may collect health details.
• Test that patients cannot access another user’s files or records.

Analytics and tracking

• Remove Google Analytics, Meta Pixel, and similar trackers from pages where they may receive PHI.
• Review every cookie, script, chat widget, and session-recording tool.
• Use only analytics vendors that meet your requirements or keep analytics self-hosted.
• Confirm that marketing tools do not receive identifiable health information.

Monitoring and governance

• Log who accessed, changed, downloaded, or deleted PHI.
• Monitor failed logins, permission changes, and unusual downloads.
• Complete and document a security risk assessment.
• Maintain written privacy, security, incident-response, and breach-notification procedures.
• Train employees who handle PHI.
• Keep required HIPAA documentation for at least six years.
• Reassess the website after major updates, vendor changes, or security incidents.

Completing the checklist does not automatically make a website compliant.

Your safeguards must match the risks identified in your assessment and remain effective as the website and its vendors change.

Common Mistakes That Break HIPAA Compliance

Most HIPAA website mistakes come from everyday tools and overlooked processes rather than sophisticated attacks.

• Running analytics or advertising trackers on PHI pages: Google does not offer a BAA for Google Analytics and instructs HIPAA-regulated organizations not to expose PHI to it. Remove Google Analytics, Meta Pixel, session-recording tools, and similar scripts from pages where they may collect PHI.
• Assuming compliant hosting makes the whole website compliant: A HIPAA-eligible host covers only one part of the system. Forms, databases, backups, email, tracking tools, user permissions, vendors, and internal policies must also meet the applicable requirements.
• Collecting health details through unsecured forms: A basic contact form may collect PHI when it connects a person’s identity with symptoms, treatment needs, or appointment information. Send submissions through an encrypted connection to approved storage instead of a generic form service or inbox.
• Skipping BAAs with smaller vendors: A software, hosting, support, or storage provider becomes a business associate when it can access PHI while providing its service. Sign the required agreement before allowing that access.
• Sending PHI through ordinary email without safeguards: HIPAA does not completely prohibit email, but organizations must assess the risks and protect ePHI against unauthorized access during transmission. Use secure communication methods unless a patient specifically requests unencrypted email after being warned of the risks.
• Never completing or documenting a risk assessment: A risk analysis is the foundation for choosing appropriate safeguards. Complete it in writing, record how identified risks were addressed, and repeat it after significant changes to the website, vendors, or data flows.

A secure-looking website can still fail HIPAA requirements when its data flows, third-party services, or compliance decisions are not reviewed and documented.

How Much Will a HIPAA-Compliant Website Cost You?

The cost of a HIPAA-compliant website depends on the size of the organization, the features it needs, and the systems it must integrate with.

These are third-party planning estimates from a cost-estimation source updated in June 2026, not official HIPAA fees or guaranteed market prices. The figures above were verified against the cited source in July 2026.

Costs rise when the website requires patient accounts, portals, telehealth, audit logging, or connections to electronic health record (EHR) and billing systems.

Building the site yourself may reduce development fees, but you must still budget for compliant hosting, security, testing, risk assessments, maintenance, and documentation.

Building a HIPAA-Compliant Website With Modelence

Building a HIPAA-compliant website requires control over where PHI is stored, who can access it, how activity is logged, and which vendors handle the data.

Website builders that do not provide code ownership or support the necessary vendor agreements can make end-to-end compliance difficult.

Modelence provides a full-stack foundation using TypeScript, React, Node.js, and MongoDB. It includes:

• Authentication and role-based access controls
• A connected database
• Backend application logic
• Logs, traces, and production monitoring
• Code ownership and GitHub export
• Deployment to infrastructure you control

These features can support secure forms, patient portals, admin dashboards, audit trails, and other healthcare workflows without relying on a collection of disconnected website plugins.

Modelence does not make a website automatically HIPAA compliant.

You remain responsible for choosing HIPAA-eligible hosting, signing required BAAs, configuring encryption and access controls, completing risk assessments, and maintaining policies and documentation.

The advantage is that you own the code and can configure the full application around your compliance requirements rather than being limited by a closed website builder.

You can start building your healthcare website on Modelence for free, then deploy it into an environment that meets your organization’s security and compliance needs.