HIPAA Hosting: A Technical Guide for Developers

Last updated: March 2026

HIPAA hosting refers to infrastructure that meets the technical safeguards required by the HIPAA Security Rule for storing, processing, and transmitting protected health information. This includes encryption at rest and in transit, access controls with audit logging, backup and disaster recovery procedures, and a Business Associate Agreement with the hosting provider.

Signing a BAA doesn't make your application compliant. The provider handles infrastructure-level controls. You handle application security and organizational policies. Understanding this division determines whether your system actually meets HIPAA requirements or just appears to.

This guide covers the technical requirements, common architectures, and decisions you'll make when building on HIPAA hosting infrastructure.

What is HIPAA Hosting?

HIPAA hosting is infrastructure designed to meet the technical safeguard requirements of the HIPAA Security Rule (45 CFR §164.312). It provides the foundational controls needed to store, process, and transmit electronic protected health information.

No official "HIPAA certification" exists for hosting providers. When a provider claims HIPAA hosting, they mean their infrastructure implements controls that support compliance and they'll sign a BAA. Your system's actual compliance depends on how you configure and use that infrastructure.

What hosting providers handle:

What you still own:

• Application authentication and authorization

• How your code handles PHI

• User access management in your application

• Employee training and policies

• Incident response procedures

• Risk assessments

The shared responsibility model matters because HIPAA holds covered entities accountable regardless of where failures occur.

Technical Requirements for HIPAA Hosting

The Security Rule establishes administrative, physical, and technical safeguards. Hosting addresses technical and physical safeguards. Administrative safeguards remain your responsibility.

Encryption

HIPAA requires ePHI be "unusable, unreadable, or indecipherable to unauthorized persons."

At rest:

• AES-256 encryption for stored data

• Encrypted database storage

• Encrypted backups

• Key management with access controls

In transit:

• TLS 1.2 or higher

• Certificate management

• Encrypted service-to-service connections

Key management matters. Who controls keys? How are they rotated? Providers worth evaluating use hardware security modules and enforce rotation automatically. A provider that hands you encryption but leaves key management entirely to you hasn't reduced your compliance burden much.

Access Controls

The Security Rule requires unique user identification and verification procedures.

Infrastructure access should include:

• Role-based access control with least privilege

• Multi-factor authentication for admin access

• Session timeout and automatic logoff

• Emergency access procedures

Questions for providers:

• Can you define custom roles with granular permissions?

• Is MFA enforced or optional?

• How are emergency access requests logged?

Audit Logging

HIPAA requires mechanisms that "record and examine activity in information systems that contain or use ePHI."

Logs should capture:

• Who accessed the system and when

• What actions they performed

• What data they accessed or modified

• Failed access attempts

• Administrative changes

Retention: HIPAA requires six years minimum. Logs must be tamper-evident and exportable for analysis. Most teams underestimate this requirement until an auditor asks to see two-year-old access records.

Backup and Disaster Recovery

The Security Rule requires data backup and disaster recovery plans.

Requirements:

• Regular automated backups (daily minimum)

• Encrypted backup storage

• Geographic redundancy

• Tested recovery procedures

Ask providers:

• What's the recovery point objective? How much data could you lose?

• What's the recovery time objective? How long until operational?

• Are backups in a separate region?

• How often are recoveries tested?

  
  

Architecture Patterns

Different architectures trade off control, complexity, and compliance coverage. The right choice depends on your team's expertise and how much engineering time you can dedicate to infrastructure security.

VPS or Dedicated Servers

Maximum control, maximum responsibility.

You handle: OS hardening, patching, firewalls, intrusion detection, log aggregation, backups, encryption configuration.

When it fits: Specialized workloads, mature security teams, legacy applications.

Complexity: High. Most early-stage healthcare companies lack the expertise to maintain this correctly and consistently.

Cloud Infrastructure (AWS, GCP, Azure)

Major providers offer HIPAA-eligible services and sign BAAs. You configure the details.

AWS HIPAA-eligible services include EC2, RDS, S3, and Lambda. Eligibility doesn't mean compliant by default. You must configure encryption, VPCs, IAM policies, CloudTrail logging, and security groups, and keep all of it correct as your architecture evolves.

When it fits: Teams with cloud expertise, complex architectures, existing cloud investment.

Complexity: Medium-high. Requires ongoing security expertise. Teams that choose this path typically spend 30 to 40 hours per month on infrastructure-level compliance maintenance before they've built anything product-facing.

Platform as a Service

PaaS abstracts infrastructure, handling servers, networking, and often databases. HIPAA-focused PaaS layers compliance controls on top.

What PaaS handles: Server provisioning, network configuration, database management, patching.

What you handle: Application code, dependencies, application authentication.

When it fits: Teams focused on product, early-to-mid stage without dedicated DevOps, standard deployment patterns.

Complexity: Low-medium. You trade some flexibility for a significant reduction in operational burden.

Containers and Kubernetes

Container orchestration introduces HIPAA considerations that don't exist in simpler architectures. These apply whether you're running Kubernetes on a cloud provider or managing your own cluster.

What changes with containers:

• Image security: Container images must be scanned for vulnerabilities before deployment. Integrate scanning into your CI/CD pipeline, not as a manual step after the fact.

• Secrets management: Environment variables in plain text, which is how most teams start, is insufficient for secrets that grant PHI access. Kubernetes Secrets are base64-encoded by default, not encrypted. Use a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, or a platform that handles key management) for credentials that touch PHI systems.

• Network policies: Pods should not have unrestricted intra-cluster communication. Define network policies that limit which workloads can talk to which, particularly for services that store or process PHI.

• Runtime monitoring: HIPAA's audit requirements apply to container workloads. That means tracking what processes are running, what system calls they make, and what network connections they establish. Tools like Falco provide runtime security visibility without requiring custom instrumentation.

• RBAC: Kubernetes RBAC and HIPAA access control requirements map closely. Namespace isolation and service account permissions need to be configured deliberately, not left at defaults.

Self-managed Kubernetes: All of the above is your responsibility. Your team owns cluster configuration, node security, control plane access, network policy enforcement, runtime monitoring, and compliance documentation for all of it. Most early-stage health tech companies underestimate how much ongoing security engineering this requires.

Managed Kubernetes (EKS, GKE, AKS): The cloud provider manages the control plane. You still own node security, workload isolation, network policies, and runtime monitoring. HIPAA-eligible status from the cloud provider gives you a foundation, not a finished compliance posture.

When Kubernetes makes sense: when you have container expertise on the team, need fine-grained workload isolation, or run workloads that benefit from orchestration. It is not a HIPAA requirement, and it adds meaningful complexity for teams without dedicated platform engineering.

Which architecture fits your team

The most common mistake: choosing an architecture based on familiarity rather than compliance cost. A team that knows AWS well often underestimates how much ongoing security engineering a HIPAA-eligible AWS setup actually requires.

The Business Associate Agreement

A BAA is required when sharing PHI with a service provider. Without one, there is no legal basis for the vendor to handle PHI on your behalf, regardless of how secure their infrastructure appears.

What a BAA establishes:

• Provider obligations to protect PHI

• Permitted uses and disclosures

• Breach reporting requirements

• Obligations at relationship end

What a BAA does not do:

• Make your application compliant

• Transfer your compliance obligations

• Guarantee provider security

• Cover services outside its defined scope

Watch for:

1. Scope limitations. Some BAAs cover specific services only. Using uncovered services with PHI violates the agreement.

2. Breach notification timelines. HIPAA gives you 60 days from discovery to notify affected individuals. Your provider's timeline to notify you directly affects how much of that window you have left. Two calendar days is a reasonable commitment from a provider.

3. Subcontractor coverage. Does the BAA extend to the provider's own subcontractors? If they run on AWS, is AWS covered?

4. Termination obligations. What happens to your data when you leave?

BAA availability by platform:

Request the BAA before signing up. For a detailed breakdown of what a BAA must contain, what terms to push back on, and what to watch out for in the fine print, see What is a HIPAA BAA.

For a deeper comparison of how these platforms handle regulated workloads, see Heroku Alternatives.

Common Mistakes

Assuming BAA = Compliance

A BAA means your provider protects PHI per their agreement. It doesn't mean your application handles PHI correctly. Application vulnerabilities, weak authentication, or logging PHI to uncovered services create compliance failures regardless of provider certifications.

Logging PHI in Plain Text

Application logs capture more than developers intend. Request parameters, error messages, and debug output can contain PHI. If logs flow to uncovered services or lack access controls, you have a gap.

Fix: Audit what your application logs. Implement PHI scrubbing. Restrict log access. Treat your audit log store as a separate system with its own access controls.

Over-Permissioned Access

When everyone has admin access, you can't demonstrate controls to auditors.

Fix: Define roles by job function. Grant minimum permissions. Review access quarterly. Remove access when roles change. Document each change.

Missing Audit Trails

If you can't show who accessed what and when, you can't prove compliance.

Audit trails must be complete, tamper-evident, retained six years, and exportable. Gaps are discovered at the worst possible moment: during a customer security review or an OCR investigation.

Ignoring the Application Layer

Compliant infrastructure running a vulnerable application is still a compliance failure.

Application considerations: input validation, authentication, authorization at every access point, dependency vulnerabilities, API security, and PHI in URLs or query parameters.

Using Real PHI in Non-Production Environments

Development and staging environments rarely have the same security controls as production. PHI in those environments expands your compliance scope and creates exposure that's difficult to document or defend.

Evaluating Providers

Certifications

Third-party certifications validate controls independently and reduce your audit burden through control inheritance.

HITRUST CSF: The most rigorous framework for healthcare. R2 certification requires an assessment by an authorized external assessor and validation by HITRUST itself. Look for current certification, not "in progress" or "pursuing." Control inheritance from a HITRUST-certified provider meaningfully reduces your own assessment scope when you pursue HITRUST later.

SOC 2 Type II: Validates that controls operated effectively over a defined period. Request the report and check the scope. Type II is what matters. Type I only validates control design, not whether those controls actually ran correctly.

ISO 27001: A global information security standard. Valuable as an additional signal but less healthcare-specific than HITRUST.

Questions to Ask

Isolation: Is infrastructure shared? How is traffic isolated? Can other customers affect my environment?

Access: Who at your company can access my data? How is that access logged? Can you show me the audit trail?

Incidents: How quickly will you notify me of a breach? What's your response process? What's the documented SLA?

Evidence: How do I export logs? What compliance reports are available and to which plan tiers?

Pricing

HIPAA hosting costs more than standard hosting. Providers that hide pricing often add significant costs at contract time.

Look for: published pricing, what's included versus priced separately, data transfer costs, and whether compliance features are gated behind higher tiers.

FAQ

Is AWS HIPAA compliant?

AWS offers HIPAA-eligible services and signs BAAs. Compliance depends on how you configure those services. AWS provides building blocks. You assemble them correctly, maintain them over time, and document that everything is working. That distinction matters before you commit to the architecture.

What's the difference between HIPAA compliant and HIPAA certified?

No official HIPAA certification exists. "HIPAA compliant" means your organization meets Security Rule requirements. Third-party frameworks like HITRUST provide external validation of controls, but they're assurance frameworks, not government certifications.

Can I use shared hosting for HIPAA?

Shared hosting is inappropriate for PHI due to isolation concerns. Vulnerabilities in other customers' applications could expose your data, and you have no visibility into or control over the neighboring workloads. Use dedicated or container-isolated infrastructure.

Do I need a BAA with my hosting provider?

Yes, if they store, process, or transmit PHI. The BAA must be in place before you deploy PHI. "We'll sort it out later" is not a compliant posture.

What logging is required?

The Security Rule requires audit controls that record and examine ePHI activity. Logs should capture access, authentication, administrative actions, and system events. Retain for six years minimum. Protect from tampering and ensure they're exportable for analysis.

Is Heroku HIPAA compliant?

Heroku Shield is the HIPAA-eligible tier, offering Private Spaces and additional controls. Standard Heroku is not HIPAA eligible. Shield is available only to Enterprise customers, which makes it impractical for early-stage teams without an enterprise contract. If you're evaluating a move off Heroku, see Heroku Alternatives for a full breakdown of HIPAA posture across Render, Fly.io, Railway, and Aptible.

What is HITRUST and do I need it?

HITRUST is a certifiable assurance framework built specifically for healthcare. HITRUST R2 certification requires an external assessment and validation by HITRUST. It's more rigorous and more recognized in healthcare enterprise contexts than SOC 2.

You don't need HITRUST to be HIPAA compliant. HIPAA doesn't require it. Whether you need it depends on what your customers require, not what the regulation mandates. Enterprise health systems and payers increasingly ask for it, especially as a prerequisite for larger contracts.

The practical path for early-stage companies: build on infrastructure that is already HITRUST certified. Your hosting provider's certification creates control inheritance, which reduces your own assessment scope, cost, and timeline significantly when you eventually pursue it.

How do I know if my platform is actually HIPAA compliant?

You can't verify it with a yes/no question. Ask for the written shared responsibility model, request the SOC 2 Type II report (not Type I), confirm the BAA covers your specific plan and services, and get a documented breach notification SLA. If a provider can answer all of those with documentation, you can evaluate whether their controls satisfy the requirements. If they can't, that is the answer.

Next Steps

Still learning: The HIPAA Compliance Guide for Startups covers the regulatory background, who HIPAA applies to, and how to scope your compliance program before you start building.

BAA questions: What is a HIPAA BAA covers what a BAA must contain, what terms to push back on, and how to evaluate whether a vendor's agreement actually protects you.

Ready to deploy: See how Aptible handles HIPAA infrastructure with HITRUST R2-certified controls and compliance enforced by default. Get started.

Evaluating a Heroku migration: Heroku Alternatives covers the real technical and compliance tradeoffs across every major alternative.

References

• HHS Security Rule Summary

• NIST SP 800-66r2: HIPAA Security Rule Implementation Guide

• HHS Business Associate Agreement Guidance

• HITRUST Alliance

• AICPA SOC 2 Trust Services Criteria