Last updated: March 2026

If you're evaluating cloud platforms for a healthcare application, you've probably run into the phrase "HIPAA compliant hosting" without a clear definition of what it actually means. Most platforms that use it are pointing to a signed BAA and a few infrastructure checkboxes. What HIPAA actually requires from your hosting infrastructure is more specific than that, and understanding the difference matters before you commit to an architecture or sign your first enterprise deal.

This guide covers the HIPAA hosting requirements that apply at the infrastructure layer: the technical, administrative, and physical safeguards your platform must support, what you're responsible for regardless of which platform you choose, and how to evaluate whether a provider actually meets those requirements.

The wrong mental model (and why it matters)

Most teams start with the wrong question. "Is this platform HIPAA compliant?" isn't answerable in isolation, because HIPAA doesn't certify platforms. It defines requirements. Compliance is a state your organization achieves or doesn't. It's not a badge a vendor earns.

"HIPAA compliant" is not a certification

No federal agency certifies platforms as HIPAA compliant. The HHS Office for Civil Rights enforces HIPAA through investigations and audits after violations occur. What vendors mean when they say "HIPAA compliant" is that their infrastructure supports the controls HIPAA requires. That's a meaningful distinction.

When evaluating platforms, the question isn't "are they certified?" It's "do they implement the specific safeguards required, and how much of that work lands on me?"

A BAA is not the same as compliance

A Business Associate Agreement is required. Under HIPAA, any vendor that handles or stores ePHI on your behalf must sign one. No BAA means no legal basis for sharing PHI with that vendor, full stop.

But a signed BAA doesn't mean the platform has implemented all the required safeguards. It establishes legal accountability and allocates responsibility. Some platforms sign BAAs while requiring customers to configure most of the actual security controls themselves. The BAA tells you who's responsible for what. It doesn't tell you whether the work has been done.

For a deeper look at what a BAA should contain and what to watch out for, see What is a HIPAA BAA.

"HIPAA-eligible" and "HIPAA-compliant" are not the same thing

AWS describes its infrastructure as "HIPAA-eligible," not "HIPAA compliant." That's accurate. It means the infrastructure can support HIPAA workloads if you configure it correctly. The configuration work (VPC isolation, encryption key management, logging, monitoring, backup policies, and several dozen other controls) is yours.

The distinction between "HIPAA-eligible infrastructure" and "HIPAA-compliant by default" is one of the more consequential architectural decisions early-stage health tech companies make. Most make it without realizing they've made it.

The three safeguard categories HIPAA imposes on hosting infrastructure

The HIPAA Security Rule organizes its requirements into three categories: technical safeguards, administrative safeguards, and physical safeguards. Your hosting infrastructure is relevant to all three, but in different ways. Some requirements land squarely on the platform. Others are split. A few are yours alone regardless of what the platform does.

Technical safeguard requirements (§164.312)

Technical safeguards are the controls most directly tied to infrastructure choices. They're where the platform either does the work for you or leaves it to you.

Encryption: at rest and in transit

HIPAA currently identifies encryption at rest as an "addressable" implementation specification under §164.312(a)(2)(iv). Addressable does not mean optional. It means you must either implement encryption or document a reasoned justification for why it isn't reasonable and appropriate in your specific environment, and implement something else that achieves equivalent protection. For virtually any production healthcare workload, no such justification exists. AES-256 at rest and TLS 1.2 or higher in transit are the practical baseline.

Note on pending regulatory change: HHS published a proposed rulemaking on December 27, 2024 that would reclassify encryption at rest as a required specification, eliminating the addressable designation. OCR has included a review of the proposed changes in its official regulatory update scheduled for May 2026. If finalized, the distinction becomes moot, but the compliance expectation is already clear under current rules.

Enforcing TLS 1.2+ means explicitly disabling older protocol versions. A compliant nginx configuration:

This is one layer. It doesn't cover enforcement at the load balancer or ingress layer (if your app sits behind one), internal service-to-service traffic, database connections, or certificate rotation. A load balancer that accepts TLS 1.0 from clients while your app config says TLS 1.2 is a compliance gap. The platform layer determines whether you're managing that risk manually or whether it's handled by default.

On Aptible, TLS termination with enforced TLS 1.2+ is configured at the platform's endpoint layer. You can't accidentally expose a production service over an unencrypted connection.

Access controls: unique user IDs, automatic logoff, emergency access

§164.312(a) requires unique user identification, automatic logoff, emergency access procedures, and encryption. Automatic logoff is typically implemented at the application layer, but the session storage layer matters too.

A baseline Express.js session configuration with enforced timeout:

const session = require('express-session');
const RedisStore = require('connect-redis')(session);

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true,             // HTTPS only — never HTTP
    httpOnly: true,           // Not accessible to JavaScript
    maxAge: 15 * 60 * 1000,  // idle timeout — adjust based on application risk classification
    sameSite: 'strict'
  }
}));

The appropriate timeout depends on the risk classification of your application. A clinical decision support tool accessed by providers has different exposure than a patient-facing scheduling app. There is no single correct value. Document your reasoning.

If session data contains tokens that grant PHI access, the session store must be treated as PHI. That means the Redis instance (or whatever you're using) needs to be encrypted, isolated, and within your audit boundary. This is an infrastructure requirement, not just an application one.

Audit logging: what must be logged, how long, and who can access it

This section covers the infrastructure requirements for audit log storage. For what your application code must log at the event level, see App Development. For retention periods, what auditors check, and common gaps, see Audit Log Retention.

§164.312(b) requires audit controls that record and examine activity on information systems containing ePHI. The regulation is intentionally non-prescriptive about format. The practical standard: you must be able to answer "who accessed this record, when, from where, and what did they do?" for any PHI access event.

A structured log entry for a PHI access event:

import json
import logging
from datetime import datetime, timezone

audit_logger = logging.getLogger('phi_audit')

def log_phi_access(user_id, action, resource_type, resource_id, ip_address):
    entry = {
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "user_id": user_id,
        "action": action,            # READ | WRITE | DELETE | EXPORT
        "resource_type": resource_type,
        "resource_id": resource_id,
        "contains_phi": True,
        "ip_address": ip_address
    }
    audit_logger.info(json.dumps(entry))

Retention enforcement doesn't belong in the log entry itself. A field saying "retention_required": "6_years" doesn't retain anything. Retention is enforced at the infrastructure layer: S3 lifecycle policies, CloudWatch log group retention settings, or equivalent controls in your log management platform.

Writing this function is the easy part. The hard part: these logs must go to a centralized, tamper-evident store that is isolated from your application logs, retained for the required period (six years under HIPAA), and accessible for audit without the possibility of modification. On raw AWS, that's CloudWatch Logs with KMS encryption, S3 lifecycle policies for retention, appropriate IAM policies, and operational procedures to ensure nothing can write to the audit store that shouldn't.

On Aptible, a single command routes all container output (including your application's audit log entries) to your SIEM or log management platform over encrypted transport:

aptible log_drain:create \\\\
  --environment my-hipaa-env \\\\
  --type syslog-tls \\\\
  --host logs.yourcompany.com \\\\
  --port 6514

This handles the infrastructure layer of the audit logging problem. The platform activity logs (SSH sessions, deployments, database connections, and administrative actions) are captured separately and automatically. Those records exist whether or not your application code generates them.

Transmission security: network segmentation and isolation

§164.312(e) requires that ePHI not be modified or accessed without authorization during transmission. At the network layer, this means private networking, no public internet exposure of PHI workloads, and segmentation between environments.

On shared-tenant platforms, your workloads run on shared network infrastructure. You're relying on the platform's internal controls to prevent cross-tenant access, with limited visibility into whether those controls are operating correctly. Dedicated environments with private networking give you an isolation boundary you can verify and document, which matters when an enterprise customer's security team asks how your infrastructure is segmented.

Administrative safeguard requirements (§164.308)

Administrative safeguards are largely your responsibility. Your hosting platform doesn't own them. But the platform you choose affects how costly they are to satisfy.

Risk assessment: your responsibility, but your platform changes the math

§164.308(a)(1) requires a documented risk assessment that identifies risks to ePHI confidentiality, integrity, and availability. This can't be delegated to your hosting provider. But a platform that automates encryption, centralized logging, intrusion detection, and backups by default shrinks your attack surface and makes the resulting risk assessment more defensible.

A risk assessment for a team on a managed platform with pre-configured controls looks different from one for a team managing their own VPC, key management, and security monitoring from scratch. The latter involves significantly more to document, more risk to quantify, and more controls to evidence.

Aptible maintains its own independent third-party security assessment covering the controls we operate on your behalf. That assessment is available to customers and can be referenced directly in your own risk documentation, which means the reduced attack surface isn't just a claim, it's evidenced.

For more on what a HIPAA risk assessment involves, see HIPAA Compliance Guide for Startups.

What your host must commit to on incident response

Under §164.308(a)(6), you need documented procedures for responding to security incidents. Your hosting provider is a material part of that response. What to require of them:

• Breach notification timeline: HIPAA requires notification to affected individuals within 60 days of discovery. Your provider's timeline to notify you affects your ability to meet that deadline. Aptible commits to two calendar days. That margin matters.

• Incident scope: The provider should commit to notifying you of incidents affecting your environments specifically, not just platform-wide events that happen to be public.

• Sub-contractor obligations: Your provider must require equivalent security obligations from their own sub-processors who may touch your PHI.

What to look for in a BAA before you sign

The BAA should specify: which services are in scope for PHI processing, the breach notification timeline, how sub-contractors are handled, what happens to your data on termination, and how shared responsibility is allocated. Vague language in any of these areas transfers risk to you.

One thing easy to miss: some BAAs apply only to specific service tiers or add-ons, not the platform broadly. If your plan doesn't include BAA coverage and you deploy PHI workloads on it, the agreement doesn't protect you, and the compliance gap is yours to own. Verify scope before assuming coverage, and do it before your first deployment, not after.

Physical safeguard requirements (§164.310)

Physical safeguards under §164.310 cover more than data center hardware. They include workstation controls, device and media controls, and facility access procedures for any office or location where PHI might be accessed. For cloud-hosted workloads, the data center portion of this burden transfers to your provider. The rest (workstation policies, device management, media disposal procedures for your own offices) remains yours regardless of where your application runs.

Data center controls: what to ask

Your provider's data centers need facility access controls, workstation security policies, and media disposal procedures. In practice: ask for their SOC 2 Type II report. Section 9 (Physical and Environmental Security) documents these controls and whether they're operating effectively. A provider without a SOC 2 Type II report is asking you to trust controls you can't examine.

SOC 2 Type I validates control design. Type II validates that controls operated effectively over a period of time. When you're doing vendor due diligence, Type II is the relevant report.

Why shared-tenant environments complicate physical safeguards

In a shared-tenant environment, your ePHI resides on physical hardware alongside other customers' data. Storage-level encryption prevents co-tenants from reading each other's data, but the physical media isolation is incomplete. For regulated workloads, dedicated environments provide a cleaner compliance narrative: the hardware running your workloads isn't shared, and documentation of that isolation is straightforward. When an enterprise customer's security team asks how you isolate PHI at the infrastructure layer, "dedicated environment on dedicated hardware" is a simpler answer than "shared tenancy with encryption-based isolation."

What HIPAA hosting requirements mean in practice: infrastructure checklist

Use this checklist to evaluate a hosting platform or audit an existing setup. Every item represents a control that is either provided by the platform, requires customer configuration, or falls entirely on you. For a complete compliance checklist across all three safeguard categories (including application-layer controls, BAAs, and audit readiness), see HIPAA Compliance Checklist.

• Dedicated/isolated environments: PHI workloads on dedicated, not shared-tenant, infrastructure

• Encryption at rest: AES-256 or equivalent for all storage containing ePHI (volumes, databases, backups)

• Encryption in transit: TLS 1.2+ enforced at the network layer, not just the application layer

• Centralized, tamper-evident audit logging: Platform-level and application-level logs centralized, immutable, and retained for a minimum of six years

• Automated backups with tested restore: Encrypted, off-site or multi-region, with documented recovery procedures and tested restore intervals

• Intrusion detection and monitoring: Active monitoring with alerting, not just logging after the fact

• Private networking: PHI workloads not directly internet-accessible; private subnets with controlled ingress

• Signed BAA: With documented scope, breach notification timeline under 60 days, and sub-contractor coverage

• Shared responsibility documentation: Written breakdown of what the platform covers versus what you own

• Third-party validation: SOC 2 Type II at minimum; ISO 27001 as an additional signal of security program maturity

Common hosting setups that fail these requirements

Shared-tenant PaaS without dedicated environments

This is the most common compliance gap for health tech startups on general-purpose platforms. Shared-tenant compute means your containers run on shared hardware, shared networking, and sometimes shared storage. The platform's isolation controls are all that stands between your PHI and co-tenants. You have limited visibility into whether those controls are functioning, and you can't document them independently. This gap surfaces reliably in enterprise security reviews.

Platforms that gate BAAs behind enterprise plans

Several major PaaS providers offer HIPAA-eligible infrastructure but restrict BAA availability to enterprise contracts. For an early-stage company, this creates a choice: operate without a BAA (out of compliance from day one) or pay enterprise pricing before you need enterprise scale. HIPAA doesn't include a startup exception for BAA requirements.

→ For a detailed look at how this plays out in practice (including what Heroku Shield covers, where teams hit gaps, and what changed in February 2026), see Heroku and HIPAA.

DIY on AWS: technically possible, operationally expensive

AWS is HIPAA-eligible. A correctly configured AWS environment can satisfy every requirement on the checklist above. Here's what that configuration looks like in practice:

# Two resources out of dozens required for a HIPAA-eligible AWS setup

resource "aws_vpc" "hipaa" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = { Name = "hipaa-vpc", Environment = "production" }
}

# Network-level audit trail required for §164.312(b) coverage
resource "aws_flow_log" "hipaa" {
  vpc_id          = aws_vpc.hipaa.id
  traffic_type    = "ALL"
  iam_role_arn    = aws_iam_role.flow_log.arn
  log_destination = aws_cloudwatch_log_group.flow_logs.arn
}

# Also required: KMS key management, CloudTrail, GuardDuty, Config rules,
# Security Hub, IAM boundary policies, NACLs, security groups, WAF,
# ACM certificate management, encrypted EBS volumes, RDS parameter groups,
# S3 bucket policies with MFA delete, cross-region backup configuration,
# private subnets, and the operational runbooks to keep all of it correct over time

On Aptible, deploying to a production-ready HIPAA environment is:

aptible apps:create my-app --environment my-hipaa-stack
aptible deploy --app my-app --docker-image

The environment includes private networking, encrypted storage, host hardening, intrusion detection, centralized logging, automated backups, and TLS termination. All of it is documented by default, which means it's auditable from day one.

The real cost of DIY HIPAA on AWS isn't the infrastructure bill. It's the ongoing engineering time to keep the controls running correctly:

• Configuration upkeep: Rotating credentials, updating TLS configurations, patching hardened AMIs, and keeping security group rules current as your architecture changes.

• Documentation: Maintaining written evidence that controls are in place and operating, required for your own risk assessment and expected by enterprise security reviewers.

• Audit prep: Pulling logs, access records, and control evidence together when a customer security questionnaire arrives or an internal audit is due.

• Troubleshooting: When a GuardDuty alert fires at 2am or a CloudTrail anomaly surfaces, diagnosing whether it's a real incident or configuration drift takes time that has no equivalent in a managed environment. This is the hardest cost to quantify, and the one where operational experience across hundreds of healthcare deployments is hardest to replicate on your own.

Based on what we see from teams migrating to Aptible, the total across these categories runs 30 to 40 hours per month. At a loaded engineering cost of $100 to $150 per hour, that's $3,000 to $6,000 per month in compliance overhead: time that isn't going toward your product.

How to evaluate a hosting provider against these requirements

Five questions worth asking directly, not just looking for in documentation:

1. What's the isolation model? Are my workloads on dedicated or shared infrastructure? Can you provide documentation of what's shared and what isn't?

2. What do you cover in the shared responsibility model, specifically? Ask for the written breakdown. Verbal assurances don't hold up in a security review.

3. What's your BAA scope? Which services does it cover? Is coverage tied to a specific plan tier or available from day one?

4. What's your breach notification SLA? HIPAA requires 60 days to notify affected individuals. Your provider's timeline to notify you determines how much of that window you have left.

5. What third-party validation do you have? SOC 2 Type II, not Type I. Type I validates that controls are designed correctly. Type II validates that they operated correctly over a period of time.

If a provider can't answer these clearly, that is the answer.

For a side-by-side comparison of how Heroku, Render, Railway, Vercel, and Aptible handle each of these requirements, see HIPAA compliant hosting: how major platforms compare.

Ready to deploy on infrastructure that meets these requirements by default? See how Aptible handles HIPAA hosting.

FAQs

Does HIPAA require specific certifications from a hosting provider?

No. HIPAA requires reasonable and appropriate safeguards, not specific certifications. SOC 2 Type II and ISO 27001 are valuable because they provide independent evidence that controls are operating correctly, the kind of evidence you'll need for enterprise vendor reviews and your own risk documentation. But neither is mandated by the regulation.

Is a signed BAA sufficient to make a hosting provider HIPAA compliant?

No. A BAA establishes legal accountability and allocates responsibility. It doesn't mean the provider has implemented the required technical safeguards. A provider can sign a BAA while leaving most of the security configuration to you. It's a prerequisite, not a proxy for compliance.

Can a startup meet HIPAA hosting requirements on shared-tenant infrastructure?

Technically, yes, if the platform's isolation controls are sufficient and you can document them. In practice, "sufficient isolation" on a shared-tenant platform is harder to verify independently and harder to explain to an enterprise customer's security team. Dedicated environments give you a cleaner compliance narrative and a simpler answer when the security questionnaire arrives.

What's the difference between HIPAA-eligible and HIPAA-compliant hosting?

"HIPAA-eligible" means a platform can support HIPAA workloads if you configure it correctly. The configuration work is yours. "HIPAA-compliant by default" means the required controls are pre-configured, documented, and operating before your first deployment. The practical difference is how much of your engineering capacity goes toward compliance maintenance rather than product development.

Next steps

If you haven't confirmed your shared responsibility model, start there. Request your provider's written breakdown of which controls they own and which ones you own. Verbal assurances don't hold up in a security review.

Audit your current platform against the requirements in this guide. Encryption at rest and in transit, audit logging, access controls, backup and disaster recovery, network isolation. Map what your platform handles versus what you've configured yourself. Gaps at the infrastructure layer are harder to close than application-layer gaps.

Check your BAA scope. Confirm it covers your current plan and every service you're using. A BAA that covers your compute tier but not your logging add-on has a gap.

Review the application layer alongside the infrastructure layer. This guide covers what your infrastructure must provide. For how to write audit log entries in application code, see App Development. For retention, protection, and auditor expectations, see Audit Log Retention.

Run through the full checklist. Hosting requirements are one piece of your compliance program. HIPAA Compliance Checklist maps all Security Rule safeguards across infrastructure, application, and organizational controls.

References

• HHS Security Rule Summary

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

• HHS Business Associate Agreement Guidance

• AICPA SOC 2 Trust Services Criteria

• Aptible Security Documentation

• Aptible Shared Responsibility Model