Compliance

HIPAA compliance for cloud infrastructure: a DevOps guide

Jorge de los Santos, CTO & Co-Founder · April 23, 2026 · 9 min read

HIPAA is not a checkbox. It's a set of technical controls that have to be embedded in your infrastructure. Here's what DevOps teams shipping healthcare software need.

HIPAA compliance for cloud infrastructure: a DevOps guide

HIPAA Is Technical, Not Just Legal

Most engineering teams treat HIPAA as a compliance and legal problem — something to hand off to a privacy officer and revisit at audit time. That’s exactly backwards. HIPAA’s Security Rule is a technical specification. It prescribes specific controls for systems that create, receive, maintain, or transmit electronic Protected Health Information (ePHI). If your infrastructure processes healthcare data, those controls live in your code, your cloud configuration, and your DevOps workflows.

The good news: if you’re already following solid security engineering practices, you’re most of the way there. HIPAA’s technical requirements are largely a stricter version of what any security-conscious team should be doing. The difference is you need to prove it — with documentation, audit logs, and continuous monitoring.

What Counts as ePHI

Before you can protect it, you need to know what you’re protecting. Electronic Protected Health Information is any individually identifiable health information that’s created, stored, or transmitted electronically. This includes:

  • Patient names, addresses, birth dates, Social Security numbers, phone numbers, email addresses
  • Diagnosis codes, treatment records, prescription data, lab results
  • Health insurance identifiers, account numbers
  • Any other information that could identify a patient when combined with health data

The key phrase is “individually identifiable.” A dataset of aggregate claims statistics without identifiers is not ePHI. A CSV with patient names and diagnosis codes very much is.

If your application touches any of the above, your infrastructure must meet the HIPAA Security Rule’s requirements for that data, wherever it lives: databases, backups, logs, message queues, object storage, API responses.

The Three Pillars: Administrative, Physical, Technical Safeguards

HIPAA’s Security Rule divides requirements into three categories. DevOps teams own the technical safeguards and contribute heavily to the physical ones.

Technical Safeguards (You Own These)

Access Controls (Required): Only authorized users and systems can access ePHI. This means:

  • Unique user identification — no shared credentials, no service accounts used by multiple applications
  • Automatic logoff — sessions time out after inactivity
  • Encryption/decryption — ePHI must be encrypted in transit and at rest

Audit Controls (Required): Your systems must record and examine activity in information systems that contain ePHI:

  • CloudTrail for all API calls to AWS services handling ePHI
  • Database query logs for any database containing patient data
  • Application access logs showing which users accessed which records
  • Log integrity — logs must not be modifiable by application users (store in append-only systems)

Integrity Controls (Addressable): Protect ePHI from improper alteration or destruction:

  • Checksums or digital signatures on stored ePHI
  • Database referential integrity and backup verification
  • Audit trail for data modifications

Transmission Security (Required): Protect ePHI in transit:

  • TLS 1.2+ for all ePHI in transit — no exceptions
  • No ePHI in URLs, query parameters, or log files (these are often transmitted or stored in clear text)
  • End-to-end encryption for ePHI passed through message queues or event streams

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →


AWS Implementation Checklist

If you’re running on AWS, here’s what a compliant ePHI environment looks like:

Encryption at Rest

# Terraform: RDS with encryption enabled
resource "aws_db_instance" "phi_database" {
  identifier        = "phi-prod"
  engine            = "postgres"
  storage_encrypted = true              # Required
  kms_key_id        = aws_kms_key.phi.arn

  # Deletion protection
  deletion_protection = true
  skip_final_snapshot = false
  final_snapshot_identifier = "phi-prod-final"
}

# S3 bucket for PHI documents
resource "aws_s3_bucket_server_side_encryption_configuration" "phi" {
  bucket = aws_s3_bucket.phi_documents.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.phi.arn
    }
    bucket_key_enabled = true
  }
}

Access Logging

Every access to ePHI must be logged. For AWS:

  • CloudTrail — enable in all regions, log to a dedicated S3 bucket with Object Lock (WORM) enabled. Minimum 6-year retention for HIPAA.
  • RDS audit logging — enable pgaudit for PostgreSQL or the audit plugin for MySQL. Log all SELECT, INSERT, UPDATE, DELETE against tables containing ePHI.
  • S3 access logging — enable server access logging on all buckets containing ePHI.
  • VPC Flow Logs — capture all network traffic in and out of subnets containing ePHI systems.
# CloudTrail with log integrity validation
resource "aws_cloudtrail" "phi_audit" {
  name                          = "phi-audit-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true   # Detects log tampering
  kms_key_id                    = aws_kms_key.phi.arn
}

Network Isolation

ePHI systems should not be directly internet-accessible:

  • Run databases in private subnets with no internet gateway route
  • Use VPC endpoints for AWS services (S3, Secrets Manager, KMS) so ePHI traffic never leaves the AWS network
  • Implement security groups with least-privilege ingress — only the application tier can reach the database tier on the specific port

Secrets Management

No credentials to ePHI systems in code, environment variables, or CI/CD secrets. Use AWS Secrets Manager with automatic rotation:

import boto3

def get_db_credentials():
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(
        SecretId='phi/database/credentials'
    )
    return json.loads(response['SecretString'])

Enable CloudTrail logging for all Secrets Manager API calls — every credential access becomes an auditable event.

Business Associate Agreements (BAAs)

HIPAA requires you to have a signed Business Associate Agreement with every vendor that creates, receives, maintains, or transmits ePHI on your behalf. For cloud infrastructure, this means:

Vendor BAA Available Notes
AWS Yes Sign via AWS Artifact
GCP Yes Sign via Google Cloud console
Azure Yes Sign via Microsoft Service Agreement
Snowflake Yes Enterprise tier required
Datadog Yes Enterprise tier required
PagerDuty Yes Business tier or higher

Critical: A vendor offering a BAA does not mean all their services are HIPAA eligible. AWS has a specific list of HIPAA-eligible services. You must only store ePHI in those services, even with a signed BAA.

Audit Readiness: What You Need to Produce

When a HIPAA audit happens (or a breach investigation), you’ll need to produce:

  • Access logs showing who accessed which ePHI and when, for the period in question
  • Change logs showing modifications to ePHI with before/after values and actor identity
  • Security incident logs showing detection, investigation, and response to any anomalies
  • Risk assessment documentation — an annual written risk analysis of threats to ePHI
  • Workforce training records showing staff completed HIPAA training
  • BAA inventory — all signed Business Associate Agreements

The access and change logs must be retained for 6 years. Design your logging infrastructure for this retention period from day one — retrofitting it later is expensive.

How IAN Supports HIPAA Compliance

IAN’s compliance scanning maps directly to HIPAA technical safeguards:

  1. Encryption coverage audit — identifies unencrypted S3 buckets, RDS instances, and EBS volumes in your AWS environment
  2. Access control analysis — flags overpermissioned IAM roles, missing MFA on privileged accounts, and publicly accessible resources
  3. Audit logging gaps — detects missing CloudTrail coverage, disabled S3 access logging, and RDS instances without query logging
  4. Network exposure — identifies ePHI databases accessible from the public internet or overly broad security group rules
  5. Secrets scanning — detects credentials committed to repositories that could expose ePHI systems
  6. HIPAA evidence collection — generates compliance evidence reports mapped to HIPAA Security Rule controls, formatted for auditors

Every finding includes a severity, which HIPAA control it maps to, and a remediation step — not just a raw list of misconfigurations.

Start Your HIPAA Infrastructure Audit

The first step to HIPAA compliance is knowing where you stand. Connect your cloud accounts to IAN and get a HIPAA control gap analysis in minutes.

Get a free infrastructure audit → | See pricing →

Next step: talk to the team

30 minutes. We'll look at your cloud together and scope what we'd take off your plate — see pricing.

Related Posts

');">
Compliance

Internal developer platform security under FedRAMP and HIPAA

Backstage, Port, Cortex, and Humanitec made internal developer platforms standard practice in 2026. Here's what an IDP looks like when the platform team also has to satisfy FedRAMP, HIPAA, PCI, and SOC 2.

May 14, 2026 · 12 min