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
pgauditfor 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:
- Encryption coverage audit — identifies unencrypted S3 buckets, RDS instances, and EBS volumes in your AWS environment
- Access control analysis — flags overpermissioned IAM roles, missing MFA on privileged accounts, and publicly accessible resources
- Audit logging gaps — detects missing CloudTrail coverage, disabled S3 access logging, and RDS instances without query logging
- Network exposure — identifies ePHI databases accessible from the public internet or overly broad security group rules
- Secrets scanning — detects credentials committed to repositories that could expose ePHI systems
- 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.
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.