A patient fills out a contact form on your medical practice’s website. A telehealth platform collects appointment requests. A healthcare app stores symptom data. A mental health service lets users message their therapist online. In each of these cases, a website is handling some of the most sensitive personal information that exists — health data — and the federal law governing how that data must be protected is called HIPAA.

HIPAA — the Health Insurance Portability and Accountability Act — sets strict rules for how protected health information must be stored, transmitted, and secured. Those rules extend directly to the hosting infrastructure that powers healthcare websites and applications. Choosing the wrong host, or failing to structure your hosting relationship correctly, can put your organization in violation of federal law before a single patient complaint is filed.

This guide explains what HIPAA requires from a hosting perspective: who needs to comply, what protected health information actually is, what technical safeguards your hosting must provide, what a Business Associate Agreement means and why you must have one with your host, and what a HIPAA-compliant hosting setup actually looks like in practice. Written for healthcare organizations, medical practices, telehealth platforms, and health tech developers who need to understand the rules — not just be told they exist.

1. What Is HIPAA?

HIPAA is a federal law enacted in 1996 and significantly expanded since then, most notably by the HITECH Act in 2009 and the Omnibus Rule in 2013. Its primary purpose relevant to healthcare websites is the protection of individually identifiable health information — defining who can access it, how it must be secured, and what happens when it’s improperly disclosed.

HIPAA is enforced by the U.S. Department of Health and Human Services Office for Civil Rights (HHS OCR). Violations can result in civil monetary penalties ranging from $100 to $50,000 per violation, with annual caps up to $1.9 million per violation category. Criminal penalties apply for willful neglect and intentional misuse of PHI. HHS OCR investigates complaints and conducts random audits — and breach notifications trigger automatic investigations.

HIPAA in the Context of Websites and Hosting

HIPAA’s technology requirements were written before cloud hosting, SaaS platforms, and modern web applications existed at scale. The law doesn’t specify particular technologies — it specifies outcomes and safeguards. This means the burden falls on covered entities and their advisors to interpret how the required safeguards apply to their specific technical infrastructure, including their web hosting environment.

What’s clear is that if your website or application handles Protected Health Information — even indirectly, even just in transit — your hosting infrastructure is within HIPAA’s scope, and your hosting provider becomes a Business Associate under the law.

2. Who Must Comply

HIPAA applies to two categories of organizations: Covered Entities and Business Associates. Understanding which category you fall into — and which your vendors fall into — is the starting point for everything else.

Covered Entities

Covered Entities are the organizations directly subject to HIPAA. There are three types:

• Healthcare providers — doctors, dentists, therapists, hospitals, clinics, chiropractors, pharmacies, and any other provider that transmits health information electronically (which in 2026 means virtually all of them)
• Health plans — health insurance companies, HMOs, Medicare, Medicaid, and employer-sponsored health plans
• Healthcare clearinghouses — organizations that process nonstandard health information into a standard format, or vice versa

Business Associates

A Business Associate is any person or organization that performs services for a Covered Entity that involve creating, receiving, maintaining, or transmitting PHI. This is where hosting providers and technology vendors come in. If a hosting company stores or processes data for a healthcare organization that includes PHI — even if the host never reads that data — the host is a Business Associate and is directly subject to HIPAA’s security requirements.

Who Is Exempt

Not every health-adjacent business is a Covered Entity. A personal fitness app that doesn’t share data with a healthcare provider is not covered. An employer wellness program that doesn’t share data with a health plan is not covered. A life insurance company (absent certain circumstances) is not covered. The key test: does your organization transmit health information in connection with covered healthcare transactions?

3. What Counts as PHI

Protected Health Information (PHI) is individually identifiable health information that is created, received, maintained, or transmitted by a Covered Entity or Business Associate. “Individually identifiable” means the information can be used to identify a specific person — either directly or in combination with other data.

The 18 HIPAA Identifiers

HIPAA specifies 18 categories of information that, when combined with health data, constitute PHI and must be protected:

The critical point: health data alone is not PHI if it cannot be linked to a specific individual. Properly de-identified data — from which all 18 identifiers have been removed — falls outside HIPAA’s scope. But in practice, healthcare websites almost always collect data that includes at least one identifier (a name, email, or IP address) alongside health-related information, which means the data is PHI.

4. The Three HIPAA Rules

HIPAA’s requirements for protecting PHI are organized into three rules. All three are relevant to website hosting decisions.

The Security Rule in Detail

The HIPAA Security Rule is the most technically specific of the three rules and the one most directly applicable to hosting decisions. It requires three categories of safeguards for electronic PHI (ePHI):

• Administrative safeguards — policies, procedures, training, risk analysis, and workforce management. These are largely internal organizational requirements.
• Physical safeguards — controls over the physical facilities and equipment where ePHI is stored. For hosted environments, this falls primarily on the hosting provider.
• Technical safeguards — access controls, audit controls, integrity protections, and transmission security. These are the most directly relevant to your hosting and application choices.

5. Hosting’s Role in HIPAA

Your hosting provider is not just a vendor — under HIPAA, they are a Business Associate, and they share legal responsibility for protecting the PHI that passes through or is stored on their infrastructure. The hosting relationship sits at the intersection of the Security Rule’s physical and technical safeguard requirements.

What Your Host Is Responsible For

• Physical data center security — secure facilities with controlled physical access, environmental protections, and surveillance (HIPAA Physical Safeguards)
• Server infrastructure security — network firewalls, intrusion detection systems, and infrastructure-level access controls
• Encryption in transit — TLS/SSL encryption for all data moving between your application and users, and between servers
• Encryption at rest — encrypting stored data on disk so that physical access to hardware doesn’t expose PHI
• Access logging and audit trails — maintaining logs of who accessed what data and when
• Disaster recovery and backups — ensuring data can be restored after a system failure
• Breach notification — notifying you promptly if they discover a security incident affecting your data

What Your Host Cannot Cover for You

No hosting provider — however HIPAA-capable — makes your website compliant on its own. Your organization remains responsible for:

• Conducting and documenting a HIPAA risk analysis
• Implementing administrative policies and workforce training
• Configuring your application to handle PHI securely (access controls, session management, form handling)
• Signing BAAs with every vendor that touches PHI — not just your host
• Your privacy policy and patient notice of privacy practices
• Managing patient rights requests (access, amendment, restriction)

6. Business Associate Agreements

A Business Associate Agreement (BAA) is a legally required written contract between a Covered Entity and any Business Associate that handles PHI on their behalf. If you are a healthcare organization using a hosting provider that stores or processes any PHI — including patient contact form submissions, appointment data, or health records — you must have a signed BAA with that provider before any PHI is transmitted or stored.

Operating without a required BAA is itself a HIPAA violation, independent of whether any breach or unauthorized disclosure occurs. HHS OCR has imposed significant penalties for missing BAAs alone.

What a BAA Must Include

• The permitted uses and disclosures of PHI by the Business Associate
• Prohibition on using or disclosing PHI in ways not permitted by the agreement or required by law
• Required safeguards — the Business Associate must implement appropriate security measures
• Subcontractor obligations — the Business Associate must ensure any subcontractors also sign BAAs
• Breach notification requirements — the Business Associate must report breaches to the Covered Entity promptly
• Termination provisions — what happens to PHI when the agreement ends (return or destruction)
• Government access — the Business Associate must allow HHS to audit their compliance

Which Vendors Need a BAA

7. Technical Safeguards for Hosting

The HIPAA Security Rule’s technical safeguards define the specific controls your hosting environment must implement for ePHI. Here’s what each requirement means in practical hosting terms.

Access Control (§164.312(a))

Only authorized users and systems should be able to access ePHI. In a hosting context this means:

• Role-based access control — database and server access granted only to those who need it
• Unique user IDs for all accounts with access to PHI systems — no shared logins
• Automatic logoff after periods of inactivity on systems accessing ePHI
• Emergency access procedures — documented process for accessing PHI systems in an emergency

Audit Controls (§164.312(b))

Hardware, software, and procedural mechanisms must record and examine activity on systems that contain ePHI. Your hosting must provide:

• Server access logs — who logged in, when, and from where
• Database query logs — records of data access and modifications
• Application-level audit trails — user actions within your application
• Log retention — HIPAA doesn’t specify a retention period but six years is the standard minimum

Integrity Controls (§164.312(c))

ePHI must not be improperly altered or destroyed. Hosting-level integrity controls include:

• File integrity monitoring — detecting unauthorized changes to system files or data
• Database integrity checks — verifying data hasn’t been corrupted
• Backup verification — confirming backups are complete and uncorrupted

Transmission Security (§164.312(e))

ePHI transmitted over electronic networks must be protected against unauthorized interception. Requirements include:

• Encryption in transit — TLS 1.2 or higher for all connections. TLS 1.0 and 1.1 are deprecated and insufficient.
• HTTPS enforced sitewide — all pages, not just those with PHI forms
• Secure email — if PHI is transmitted via email, it must be encrypted (standard email is not HIPAA compliant)
• Encrypted APIs — all API connections transmitting PHI must use TLS

Encryption at Rest

While HIPAA designates encryption at rest as “addressable” rather than “required,” HHS OCR has made clear that encryption at rest is the expected standard for ePHI stored on servers, databases, and backups. Any decision not to encrypt at rest must be documented with a risk analysis justification — in practice, for hosted environments, encryption at rest is simply required.

8. HIPAA-Compliant Hosting Providers

Not every hosting provider is willing or able to sign a BAA and support HIPAA compliance. Here’s what the landscape looks like across different tiers of hosting.

Major Cloud Providers (Enterprise-Grade)

The three major cloud providers all offer HIPAA-eligible services and will sign BAAs with qualifying customers:

• Amazon Web Services (AWS) — offers a broad set of HIPAA-eligible services (EC2, RDS, S3, and many others). BAA available. AWS’s HIPAA whitepaper provides detailed guidance on architecting compliant environments.
• Google Cloud Platform (GCP) — offers HIPAA-eligible services and will sign a BAA. Google Workspace also offers a BAA for qualifying healthcare plans.
• Microsoft Azure — offers HIPAA-eligible services and a comprehensive BAA covering a wide range of services. Azure has strong healthcare-specific compliance documentation.

Managed WordPress / Healthcare-Specific Hosts

9. Website Features & PHI Risk

Every feature you add to a healthcare website carries a potential PHI risk that must be evaluated. Here’s a practical rundown of the most common website features and their HIPAA implications.

Contact Forms

Any contact form where a user can enter their name, email, and a health-related question creates PHI the moment they submit it. The form submission must be encrypted in transit (HTTPS), stored securely on a HIPAA-compliant server, and any email notification triggered by the form must be handled securely. Standard WordPress contact form plugins (Contact Form 7, WPForms) are not HIPAA compliant out of the box — they store submissions in the WordPress database and send unencrypted email notifications. HIPAA-compliant form solutions exist but require deliberate selection and configuration.

Online Appointment Scheduling

Scheduling tools that collect patient names, contact information, and reason for visit — or that allow patients to select appointment types that reveal health conditions — are handling PHI. The scheduling platform must sign a BAA and provide appropriate encryption and access controls. Popular general-purpose scheduling tools (Calendly, Acuity standard plans) do not offer BAAs and are not appropriate for healthcare use without a specific HIPAA-compliant plan.

Patient Portals

A patient portal — allowing patients to view records, request appointments, message their provider, or access test results — is a full-scale ePHI environment. These require robust authentication (including MFA), complete audit logging, role-based access control, and end-to-end encryption. Patient portals should be built on or integrated with healthcare-specific platforms (EHR systems, HIPAA-compliant portal solutions) rather than built on standard WordPress installations.

Live Chat and Messaging

Chat widgets that allow patients to ask health questions create PHI in real time. Standard live chat tools (Intercom, Drift, HubSpot Chat standard plans) are not HIPAA compliant. If you use live chat on a healthcare site, it must be a HIPAA-compliant solution with a signed BAA — or the chat must be restricted to non-PHI interactions (e.g., office hours and directions only, with an explicit notice not to share health information).

Google Analytics and Tracking Pixels

As noted in Section 6, analytics tools can inadvertently collect PHI. The HHS OCR guidance on tracking technologies is clear: if your analytics tool collects information (IP addresses, browsing patterns on condition-specific pages, referral sources) that could identify an individual in connection with their health status, it may constitute ePHI. Options include removing analytics from PHI-touching pages, using a HIPAA-compliant analytics alternative (Matomo self-hosted, HIPAAcompliant.io analytics), or blocking analytics from loading on sensitive pages.

10. Breach Notification Requirements

When a HIPAA breach occurs — defined as unauthorized acquisition, access, use, or disclosure of PHI that compromises its security or privacy — specific notification timelines apply. Your hosting provider’s incident response capabilities directly affect your ability to meet these requirements.

Notification Timelines

• Affected individuals — must be notified without unreasonable delay and no later than 60 days after discovery of the breach
• HHS OCR — breaches affecting 500 or more individuals must be reported to HHS within 60 days of discovery; smaller breaches are reported annually
• Media — breaches affecting 500 or more individuals in a state or jurisdiction must be reported to prominent media outlets in that state
• Business Associates to Covered Entities — your host must notify you of a breach without unreasonable delay and no later than 60 days after discovery — this notification period should be specified in your BAA

What Your Host Must Provide

For your organization to meet breach notification timelines, your hosting provider must:

• Detect security incidents promptly through active monitoring and intrusion detection
• Notify you rapidly when an incident is discovered — many BAAs specify 24–72 hour notification windows
• Provide detailed incident reports documenting what data was affected, when, and how
• Cooperate with your investigation and any regulatory inquiries

11. Common HIPAA Hosting Mistakes

These are the most frequently occurring HIPAA compliance failures in healthcare website and hosting environments — most of which are avoidable with the right setup.

Using a Host That Won’t Sign a BAA

The most fundamental mistake. If your host won’t sign a BAA and your site handles PHI in any form, you are in violation. No amount of encryption, access controls, or security plugins on your side compensates for a missing BAA. This is a contractual and legal requirement, not a technical one.

Assuming Shared Hosting Is Acceptable

Standard shared hosting environments — where your site shares server resources with potentially thousands of other customers — are not compatible with HIPAA compliance for PHI. The shared environment makes proper isolation of ePHI impossible, physical and logical separation from other tenants doesn’t exist at the level HIPAA requires, and shared hosts don’t offer BAAs.

Not Getting BAAs with Every PHI-Touching Vendor

Healthcare organizations often secure a BAA with their host and assume that’s sufficient. But every service in your technology stack that touches PHI requires its own BAA: your email provider, your form service, your scheduling tool, your analytics platform, your CDN, your backup service. A single uncovered vendor in the chain is a compliance gap.

Using Standard Google Analytics

Covered extensively in Section 6, but worth repeating: standard Google Analytics on healthcare websites is a documented and active compliance risk following HHS OCR’s 2022–2023 guidance. Many healthcare organizations are still running standard GA on their sites. This should be remediated immediately.

Forgetting About Backups

Backups containing PHI must be encrypted and protected by the same safeguards as production data. Unencrypted backups stored on a non-HIPAA-compliant backup service negate all the protections on your production environment. Your BAA must cover your backup destination.

Not Conducting or Documenting a Risk Analysis

HIPAA requires covered entities to conduct a thorough, accurate assessment of the potential risks to ePHI — and to document it. This risk analysis must be updated when significant changes occur (new system, new vendor, new feature). Hosting changes — upgrading to a new provider, migrating data, adding a new integration — should trigger a risk analysis update.

12. Your HIPAA Hosting Checklist

Use this checklist as a practical starting framework. This is not a substitute for a formal HIPAA risk analysis, but it covers the hosting and technical safeguard requirements most directly relevant to healthcare websites.

Hosting Provider

• Hosting provider will sign a Business Associate Agreement (BAA) — confirmed in writing
• BAA covers the specific services being used (not just generic hosting)
• Hosting environment is isolated — dedicated server, VPS, or container (not shared hosting)
• Hosting provider has documented HIPAA compliance program and will cooperate with audits
• Hosting provider’s subcontractors (data center, CDN) are also covered under BAA chain
• Breach notification terms in BAA — provider must notify you within specified timeframe

Encryption & Transmission Security

• TLS 1.2 or higher enforced on all connections — TLS 1.0/1.1 disabled
• HTTPS enforced sitewide with HSTS header — no HTTP fallback on any page
• All stored ePHI encrypted at rest — AES-256 minimum for databases, file storage, and backups
• Backups encrypted and stored on a HIPAA-compliant backup service with BAA
• Internal connections between servers (database to app server) also encrypted

Access Controls & Auditing

• Unique user accounts for all staff with access to systems containing PHI — no shared credentials
• Multi-factor authentication enabled on all admin and hosting accounts
• Role-based access — staff can only access PHI relevant to their role
• Automatic session timeout on systems accessing ePHI
• Server access logs enabled and retained for minimum six years
• Database query logs enabled for all tables containing PHI
• Intrusion detection or file integrity monitoring active

Third-Party Vendors & Website Features

• BAA signed with every vendor that touches PHI — email, forms, scheduling, analytics, CDN
• Google Analytics (standard) removed from pages where PHI is collected or health-related browsing occurs — or replaced with HIPAA-compliant analytics
• Contact forms using a HIPAA-compliant solution — or submissions handled without storing PHI on server
• Appointment scheduling platform has signed BAA
• Live chat restricted to non-PHI interactions — or using a HIPAA-compliant chat platform with BAA
• Telehealth video using a HIPAA-compliant platform (Zoom for Healthcare, Doxy.me, etc.)

Policies & Documentation

• Current HIPAA risk analysis documented and on file
• Risk analysis updated to reflect current hosting infrastructure and all PHI-touching systems
• Privacy policy posted on website — compliant with HIPAA Notice of Privacy Practices requirements
• Workforce HIPAA training current for all staff with access to PHI systems
• Incident response plan documented — including breach assessment and notification procedures
• All BAAs on file and accessible