Is Your Website HIPAA Compliant? 8 Questions to Ask Your Hosting Provider

Building a web presence for a healthcare organization, medical practice, telehealth provider, or healthtech brand comes with a unique set of compliance challenges. When evaluating hosting infrastructure for a WordPress®¹ site, navigating terms like HIPAA compliance, encryption standards, and security certifications can quickly become overwhelming. Failing to handle protected health information (PHI) properly can lead to severe regulatory fines and catastrophic loss of patient trust.

The bottom line is that no hosting platform is inherently “HIPAA compliant” out of the box without a signed Business Associate Agreement (BAA). 

Furthermore, compliance is never solely the responsibility of your web host. It is a shared responsibility between infrastructure providers and application managers.

Whether you are designing a high-traffic brand platform or architecting a multi-layered digital health ecosystem, this guide breaks down what HIPAA compliant hosting actually requires, where the technical boundaries lie, and how to structure a secure architecture.

What “HIPAA Compliant Hosting” actually means

To understand HIPAA compliant hosting, you first have to understand that the U.S. Department of Health and Human Services (HHS) does not formally certify web hosts. There is no official government seal or stamp that makes a server “HIPAA certified.” 

Instead, hosting compliance means configuring infrastructure to meet the technical standards of the HHS HIPAA Security Rule under a binding legal contract known as a Business Associate Agreement (BAA).

Under HIPAA, any information that identifies a patient and relates to their health condition, provision of care, or payment details is classified as Protected Health Information (PHI). When it’s created, stored, or transmitted digitally, it’s known as Electronic Protected Health Information (ePHI).

When a third-party host processes or stores ePHI, that provider acts as a “Business Associate.” The HIPAA Security Rule requires web infrastructure to enforce controls across three distinct categories:

1. Administrative safeguards: Formal security management processes, threat analysis, access management policies, and ongoing workforce training.
2. Physical safeguards: Physical security measures protecting data center facilities, hardware, and workstation environments against unauthorized access and environmental hazards.
3. Technical safeguards: Technology mechanisms including end-to-end encryption, multi-factor authentication (MFA), role-based access controls, automated session timeouts, and comprehensive audit logging.

The Business Associate Agreement (BAA) is the linchpin of the entire relationship. A BAA is a legally binding agreement that contractually obligates the host to maintain HIPAA-level safeguards and establishes legal liability if a security incident occurs on their infrastructure. Without a signed BAA in place, standard web infrastructure cannot legally store or handle PHI.

When HIPAA applies: PHI touchpoints on healthcare websites and eCommerce

A common misconception in digital marketing is that merely being a healthcare business means every single web page must sit behind a BAA. In reality, HIPAA regulations are triggered by the handling of PHI, not by your industry sector alone.

Understanding where PHI is created, received, transmitted, or stored on your digital properties helps determine which workloads require dedicated, BAA-backed infrastructure and which can run on standard enterprise managed hosting.

eCommerce and transactional flows

Healthcare websites often offer digital commerce such as online pharmacy fulfillment, paid telehealth consultations, or prescription refills. In these cases, there are usually two kinds of private data involved, each with their own privacy standard. 

• Different protocols: While Payment Card Industry Data Security Standard (PCI-DSS) protocols safeguard credit card details, they do not cover clinical data.
• The HIPAA trigger: If a user completes a checkout flow that pairs payment details with a medical prescription, symptom treatment, or specialty care selection, that transaction creates ePHI. The backend processing system, database storage, and confirmation communications must reside within a BAA-backed environment.

Patient portals and member areas

Authenticated user areas are PHI environments by default. This includes patient dashboards, telehealth portals, secure messaging environments, lab result viewers, and document download centers..

• Security requirements: Accessing these areas requires strict technical controls, including forced multi-factor authentication (MFA), granular role-based access management, short session timeout windows, detailed audit logs, and encrypted database connections backed by an executed BAA.

Web forms that collect health information

Web forms are one of the most frequent vectors for accidental HIPAA non-compliance, as they often ask for sensitive health data.

• The risk vector: A simple contact form asking for a name and general inquiry is not typically ePHI. However, the moment a form asks a patient to select a condition, list current medications, upload a medical document, or describe a “chief complaint” during appointment booking, the entry becomes ePHI.
• Compliance rule: Once a form captures personal health details tied to an identifiable individual, the form handler, backend database, notification email routing, and hosting server fall directly under the jurisdiction of HIPAA.

Key Rule: Any touchpoint on your digital presence that handles ePHI must live in an isolated, BAA-backed hosting environment. Non-PHI surfaces, such as public marketing sites and content hubs, can run on a separate managed platform built for scale and performance.

Why standard shared hosting falls short for regulated data

For organizations dealing with sensitive or regulated data, relying on entry-level web architecture presents severe shared hosting security risks. Standard shared hosting places hundreds or thousands of distinct websites on a single physical server, sharing the same underlying RAM, CPU, and storage disk.

From an architectural standpoint, shared hosting falls short for regulated health data in several ways:

• Lack of tenant isolation: Basic shared hosting platforms often lack kernel- or OS-level isolation between accounts. If another tenant on a shared server experiences a remote code execution or severe malware infection, attackers can potentially leverage local privilege escalation to access neighboring site directories on the same system. Beyond data leakage, shared resource allocation means a DDoS attack targeted at any neighboring site can over-utilize server capacity and bring down your application.
• Resource contention: Heavy traffic spikes or denial-of-service (DDoS) attacks aimed at a neighboring site on a shared host can paralyze your application, leading to downtime that violates healthcare availability standards.
• Absence of granular logging: Shared hosting platforms rarely offer the immutable access logging, file integrity monitoring, or forensic audit trails mandatory under HIPAA Technical Safeguards.
• No BAA support: Budget shared hosting providers operating at scale will not sign a Business Associate Agreement, legally precluding them from hosting ePHI.

The shared responsibility model: What the host covers vs. what you own

Maintaining compliance across cloud infrastructure operates on a shared responsibility model. Working with a secure hosting partner does not delegate overall legal accountability away from your organization; ultimate responsibility always remains with the covered entity or business associate running the application.

Host responsibility: Infrastructure layer

Your hosting provider manages physical facility access, hardware integrity, hypervisor isolation, network edge protection, underlying server OS patching, and network-level DDoS mitigation. They ensure that physical servers cannot be accessed by unauthorized personnel and that platform-level threat monitoring remains active 24/7.

Typically, the host is responsible for:

• Physical data center security and hardware maintenance
• OS patching, network firewalls, and hypervisor isolation
• Edge security, managed WAF, and platform threat monitoring
• Hardware backups, physical redundancy, and core uptime SLAs

Your responsibility: Application layer 

Your organization is responsible for everything built on top of that infrastructure. This includes keeping WordPress core code, themes, and plugins updated, implementing strong password policies and MFA for site administrators, auditing third-party code for vulnerabilities, configuring SSL/TLS settings, restricting administrative access, and maintaining internal employee training programs.

Typically, your organization is responsible for:

• App configuration, plugins, and theme code
• User access controls, passwords, and MFA enforcement
• End-to-end application encryption controls
• Workforce HIPAA training and internal security policies
• Execution of Business Associate Agreements (BAAs)

What to look for in HIPAA compliant hosting 

Evaluate potential hosts using a detailed operational assessment when auditing infrastructure providers for your healthcare applications. Here are the core questions to ask any provider, mapped directly to compliance standards:

1. Will you sign a Business Associate Agreement (BAA)?

• Why it matters: This is the non-negotiable entry qualification for handling ePHI. If a host answers “no,” the discussion ends there.
• What a strong answer looks like: We execute custom BAAs covering our infrastructure, hardware, data centers, and managed hosting services for qualified health enterprise workloads.

2. How is data encrypted, in transit and at rest?

• Why it matters: HIPAA Technical Safeguards require robust cryptography to ensure health records are unreadable if intercepted or accessed by unauthorized actors.
• What a strong answer looks like: Data in transit is enforced using TLS 1.2 or TLS 1.3 encryption, with HTTP Strict Transport Security (HSTS) enabled. Data at rest uses modern AES-256 encryption across database volumes, file storage systems, and offsite backup repositories.

3. What access controls, MFA, and audit logging are in place?

• Why it matters: You must track who accessed ePHI, when it was modified, and where data moved during a session.
• What a strong answer looks like: The platform provides mandatory Multi-Factor Authentication (MFA) across user dashboards, single sign-on (SSO) integration, role-based access management, automated inactivity session timeouts, and centralized, write-once audit logs stored securely for security audits.

4. How are backups and disaster recovery handled?

• Why it matters: HIPAA requires a formal contingency plan including data backup, disaster recovery, and emergency mode operation plans.
• What a strong answer looks like: Automated, encrypted nightly backups stored in geographically redundant locations, with one-click restoration procedures and defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

5. What is your security policy and which audits do you pass?

• Why it matters: Independent, audited proof provides verification that platform controls function reliably under stress.
• What a strong answer looks like: Annual third-party audits confirming SOC 2 Type II compliance and ISO 27001:2022 certification, demonstrating audited operational excellence across security, availability, and confidentiality domains.

6. Do you offer isolated or dedicated environments?

• Why it matters: Preventing cross-tenant data leakage is essential when hosting critical health systems.
• What a strong answer looks like: Dedicated single-tenant architecture, virtual private cloud (VPC) isolation, or containerized environments that prevent hardware and memory space sharing with untrusted third parties.

7. What is the uptime SLA and who is accountable during an outage?

• Why it matters: Patient care platforms demand high availability to maintain access to critical services.
• What a strong answer looks like: Financially backed Service Level Agreements (SLAs) guaranteeing 99.95% to 99.99% uptime, paired with 24/7 technical incident response teams.

8. How responsive is support when something goes wrong?

• Why it matters: During critical events, you need direct access to trained security engineers rather than generic help queues.
• What a strong answer looks like: 24/7/365 global technical support staffed by security specialists, accessible via phone and priority ticketing, with short initial response time guarantees.

Certifications that signal a trustworthy provider

Understanding how various regulatory and industry standards fit together helps clear up common marketing confusion. While certifications validate operational mature practices, they serve distinct compliance purposes:

Standard	What it covers	What it doesn’t do
HIPAA BAA	Contractually binds a provider to federal HIPAA Security Rule compliance for handling ePHI.	Does not apply to infrastructure if your application code itself is improperly configured.
SOC 2 Type II	Audits internal controls over security and availability over an extended review period (6–12 months).	Does not fulfill federal HIPAA legal requirements or replace the legal need for a signed BAA.
ISO 27001:2022	Internationally recognized framework for establishing, implementing, and continually improving an Information Security Management System (ISMS).	Does not specifically mandate compliance with U.S. health privacy laws.
HITRUST CSF	Comprehensive certification framework combining HIPAA, NIST, ISO, and PCI rules into a single verifiable model.	Complex and costly to earn, absence of HITRUST does not mean an entity is non-compliant with HIPAA.
PCI DSS	Mandatory security standards for entities that process, store, or transmit credit card details.	Does not cover health data or satisfy ePHI protection requirements.
GDPR	European Union law regulating personal data privacy, consent, and user data rights for EU residents.	Does not map directly to U.S. HIPAA standards or cover clinical ePHI definitions.

HIPAA compliance checklist for healthcare websites and eCommerce

Use this self-assessment checklist when auditing your web architecture, technical requirements, and hosting relationships before processing sensitive data:

Requirement	Typically the host	Typically you
Executed Business Associate Agreement (BAA) in place before processing any ePHI	—	✓
Isolated or dedicated hosting environment (no unisolated shared tenancy)	✓	—
End-to-end encryption in transit (TLS 1.2+) and at rest (AES-256)	✓	Config
Role-based access control across all management and administrative portals	Platform	✓
Multi-factor authentication (MFA) enforced for all admin and staff users	Platform	✓
Automated session timeouts and forced re-authentication on sensitive screens	Platform	✓
Full immutable audit logging of ePHI views, exports, modifications, and deletions	✓	Review
HTTPS enforced everywhere; no sensitive parameters in URLs or referrer headers	Platform	✓
Application-level form validation; zero client-side logging of health inputs	—	✓
Encrypted storage for uploaded file assets (intake forms, medical records)	✓	Config
Regular vulnerability scanning, automated patching, and system updates	Shared	Shared
Documented workforce HIPAA compliance training and incident response plans	—	✓
Executed BAAs with all downstream third-party vendors (CDNs, analytics, email)	—	✓

Hosting for regulated industries and where WP Engine fits

Healthcare companies and enterprise brands operating in regulated spaces frequently implement a split architecture strategy. This model optimizes security, compliance budgets, and marketing flexibility by separating clinical systems from public brand assets.

Clinical workloads 

Systems handling active ePHI require dedicated infrastructure built for healthcare compliance. These workloads must be deployed within an isolated, BAA-signing cloud environment designed specifically for clinical data processing.

Typical clinical workloads include:

• Patient portals and member dashboards
• Telehealth streaming and consultation apps
• Electronic health record (EHR) integrations
• PHI-bearing intake forms and medical questionnaires

Public brand presence 

Your primary public web presence does not touch ePHI and can run separately on a secure, managed enterprise platform optimized for speed, reliability, global distribution, and content workflows.

Typical public brand surfaces include:

• Marketing sites and primary brand hubs
• Content hubs and educational blogs
• News portals and media pages
• Recruitment and career pages
• Investor relations resources

Where WP Engine fits

Transparency is central to building effective enterprise architecture. WP Engine’s Acceptable Use Policy strictly prohibits the storage or processing of Protected Health Information (as defined under HIPAA) and cardholder data covered under PCI DSS regulations. WP Engine does not sign BAAs and should not be used as a repository for patient health records.

Instead, WP Engine serves as a secure managed web platform for hosting your public-facing, non-PHI digital properties. By hosting public marketing and content surfaces on WP Engine, healthcare organizations gain access to enterprise security features without complicating their backend clinical environments:

• Audited security certifications: Standardized operations independently audited for both SOC 2 Type II and ISO 27001:2022 compliance.
• Enterprise threat mitigation: Integrated security features, with the option to add Global Edge Security for a managed Web Application Firewall (WAF), advanced DDoS mitigation, and continuous threat monitoring. 
• Granular identity and access controls: Support for Single Sign-On (SSO) integration and flexible Multi-Factor Authentication (MFA) options across portal accounts, providing security-minded organizations strict control over administrative user access.
• High-availability performance: Backed by an uptime SLA of 99.95% (and enhanced SLA of 99.99% for custom high-availability and failover architectures), ensuring marketing platforms perform smoothly under heavy traffic or during unexpected data center outages.
• Automated data protection: Nightly automated backups, one-click restoration, and automated system updates.
• GDPR compliance alignment: Support for handling standard non-PHI personal data (such as marketing newsletter subscriptions, analytics, and contact submissions) in compliance with global privacy regulation standards like GDPR.

By separating non-PHI public brand platforms from backend clinical databases, health organizations maintain compliance standards while delivering fast, user-friendly digital experiences. You can read more about how enterprise brands leverage managed web architecture in our collection of customer case studies.

Ready to optimize your healthcare web presence?

Running a regulated-industry site and not sure what belongs where? Talk to a WP Engine specialist about hosting your non-PHI web presence on our SOC 2 Type II and ISO 27001:2022 certified platform. Learn more about our secure hosting solutions.

FAQs about HIPAA-compliant hosting

What makes web hosting HIPAA compliant?

Web hosting achieves HIPAA compliance when infrastructure meets the technical, physical, and administrative standards of the HIPAA Security Rule and is backed by a signed Business Associate Agreement (BAA). Technical controls include data encryption at rest and in transit, strict role-based access management, continuous audit logging, regular vulnerability assessments, and isolated infrastructure environments designed to prevent unauthorized ePHI exposure.

Do I need a BAA with my hosting provider?

Yes. If your hosting environment stores, processes, or transmits Electronic Protected Health Information (ePHI) on behalf of a covered entity or business associate, an executed Business Associate Agreement (BAA) is legally required under federal law. Without a signed BAA, infrastructure cannot be considered HIPAA compliant, regardless of its technical security controls or independent certifications.

Is shared hosting safe for sensitive or regulated data?

No. Standard shared hosting environments lack the isolation required to protect regulated health data securely. Because multiple tenants share server hardware, memory, and operating systems, shared hosting introduces risks of cross-site contamination, resource contention, and unauthorized access. Furthermore, standard budget shared hosting providers generally refuse to execute the Business Associate Agreements required for handling ePHI.

How does HIPAA apply to healthcare eCommerce or telehealth sites?

HIPAA applies to eCommerce and telehealth platforms whenever transactional flows collect, transmit, or store details linked to an identifiable patient’s medical care, treatment, or prescription history. While payment processors manage cardholder details under PCI-DSS, any accompanying health details—such as treatment selection or intake forms—constitute ePHI and require a BAA-backed hosting environment.

Can my patient portal and marketing site run on the same host?

While technically possible, separating them using a split architecture is often best practice. Hosting patient portals on dedicated, BAA-backed infrastructure ensures ePHI compliance, while running your non-PHI public marketing site on a specialized, managed enterprise host maximizes performance, scalability, and content management efficiency without adding regulatory overhead to your marketing workflows.

Does my web host affect GDPR compliance?

Yes. GDPR governs how personal data (names, IP addresses, emails) belonging to EU residents is collected, processed, and stored. Your web host impacts GDPR compliance through data center locations, server-level encryption, data processing agreements (DPAs), and edge security measures. Ensure your provider offers adequate privacy controls and compliant data transfer mechanisms if handling European web traffic.

What should regulated industries look for in a hosting provider?

Regulated industries should prioritize hosting providers that maintain independently audited certifications (such as SOC 2 Type II and ISO 27001:2022), strong edge security (managed WAF, DDoS protection), end-to-end encryption, automated backups, high availability SLAs, and clear Acceptable Use Policies detailing supported data workloads and regulatory boundaries.

1. WP Engine is a proud member and supporter of the community of WordPress® users. The WordPress® trademark is the intellectual property of the WordPress Foundation. Uses of the WordPress® trademarks in this website are for identification purposes only and do not imply an endorsement by WordPress Foundation. WP Engine is not endorsed or owned by, or affiliated with, the WordPress Foundation. ↩︎