HIPAA for engineers who never asked for it

HIPAA is not a framework you install. It's a set of outcomes the federal law requires — and unlike GDPR or SOC 2, there's no certification to point at when an auditor asks what you've done. Here's the shape of what your code and your team have to do to be in defensible shape.

I've built and reviewed HIPAA-compliant systems at a regulated telehealth company for several years. Most engineers approaching HIPAA for the first time over-focus on encryption and under-focus on access control and audit trails. This post covers both.

What counts as PHI

Protected Health Information (PHI) is any information that can link a health condition or healthcare transaction to a specific person. It's broader than most engineers expect.

• Obvious PHI: diagnosis codes, medication names, lab results, clinical notes, treatment dates.
• Less obvious PHI: appointment timestamps (they imply a healthcare interaction), billing amounts (they link a person to a payment for care), device identifiers if attached to a health record.
• PHI in logs: if your application log contains a user ID and a health-related action ("user 1234 viewed prescription"), that log line is PHI. Log files need the same controls as your database.
• De-identified data is not PHI — but Safe Harbor de-identification requires removing 18 specific identifiers including full name, zip codes below 5 digits, dates more precise than year, and device identifiers. Half-measures do not count.

Encryption at rest

HIPAA requires encryption at rest as an addressable standard — meaning you have to implement it or document why an equivalent alternative is sufficient. In practice: just do it.

• Database volumes: use encrypted EBS volumes on AWS (AES-256). Enable at provisioning — encrypting a running instance requires a snapshot-and-restore.
• S3 buckets: enable SSE-KMS with a customer-managed key. Enforce via bucket policy that denies s3:PutObject without x-amz-server-side-encryption.
• Application-level encryption for the most sensitive fields: consider encrypting PHI fields (diagnoses, SSNs) at the application layer with a key stored in AWS KMS, separate from the database key. This protects against a DBA with direct DB access.
• Backups: encrypted at the same level as the source. RDS automated backups inherit encryption; manual snapshots shared to another account may not — verify explicitly.

Encryption in transit

All PHI in transit must be encrypted. "In transit" means everywhere: client to server, server to server, application to database, application to S3.

• TLS 1.2 minimum, 1.3 preferred: disable TLS 1.0 and 1.1 at the load balancer and in your MySQL/Postgres SSL config. Test with testssl.sh.
• Internal traffic is not exempt: service-to-service calls inside a VPC still carry PHI and should use TLS or mTLS. "It's internal" is not a HIPAA defence.
• HSTS in response headers: set Strict-Transport-Security: max-age=31536000; includeSubDomains to prevent browser downgrades.
• Certificate management: use ACM on AWS or Let's Encrypt with auto-renewal. A lapsed cert causing a patient-facing outage is a bad day; a lapsed internal cert that someone works around with verify=false is a breach.

Audit logs you can actually search

If you can't answer 'who accessed patient X's record last Tuesday at 3 PM?' in under five minutes, your audit log isn't doing its job. HIPAA's Security Rule requires audit controls — a mechanism to record and examine activity.

Every audit log entry needs three things: who (user_id, role), what (action, resource_type, resource_id), and when (timestamp in UTC with millisecond precision). If you only log the who and when, you can prove someone accessed the system but not what they saw.

• Log at the application layer, not just the DB layer: application logs capture intent ("user viewed appointment"). DB logs capture statements. You want both, but application logs are more useful for investigations.
• Immutable logs: audit logs must not be modifiable by application code. Write to a separate log store that application credentials can INSERT into but not DELETE or UPDATE from.
• Retention: HIPAA requires 6 years for policies and certain records. For audit logs, 6 years is a safe default. Cost is minimal with S3 Glacier.
• Searchable: index on user_id, resource_id, and created_at. If your audit table grows to 100M rows with no indexes, investigations become impractical.

Access control, written down

RBAC is the technical floor. What auditors actually want is a document that says who can access what data, under what circumstances, signed by someone accountable, and updated when it changes.

In code: enforce role checks at the service layer, not the controller layer. A controller check is easy to miss when a new endpoint is added. A service that enforces hasPermission('read:phi') before returning any PHI is harder to accidentally bypass.

• Minimum necessary: HIPAA's minimum necessary standard means users should only see the PHI required for their role. A billing clerk shouldn't have read access to clinical notes.
• Break-glass access: some workflows require a provider to access records outside their normal patient panel. Log these explicitly with a reason code and flag them in your compliance dashboard.
• Access reviews: HIPAA requires periodic review of who has access to what. Build an export that lists all users with PHI access by role. Running this quarterly is the minimum.

Business Associate Agreements

A Business Associate is any vendor or contractor who handles PHI on your behalf. You need a signed BAA with every one of them before PHI touches their systems.

The ones engineers forget most often: your cloud provider (AWS, GCP, and Azure all offer BAAs — you have to request them, they are not automatic), your error tracking tool (Sentry, Datadog — scrub PHI from payloads or get a BAA), your log aggregator, and any LLM API if you're sending patient data to it.

No BAA means you're moving PHI to a vendor without a legal framework. That's a direct HIPAA violation regardless of encryption or access controls.

Breach notification

If PHI is accessed by an unauthorised party, HIPAA's Breach Notification Rule kicks in. The clock starts when you discover the breach, not when it occurred.

• Under 500 individuals affected: notify each affected individual within 60 days of discovery. Report to HHS annually.
• Over 500 individuals affected: notify affected individuals within 60 days, notify HHS within 60 days, AND notify prominent media in the affected state. This is the one that makes news.
• Document everything: documentation that you assessed a potential incident and determined it was not a breach is almost as important as the breach response itself. Undocumented assessments look like cover-ups.
• Have a runbook before you need it: a breach at 2 AM is the wrong time to figure out who the Privacy Officer is and how to reach HHS.

The HIPAA engineer's practical checklist

Before any code is written in a regulated product, run through this list. Every item represents a gap I've seen cause real compliance problems in production healthcare systems. The encryption and audit requirements here also affect database performance in ways that aren't obvious — I covered MySQL and PHP performance in a telehealth context separately.

• Classify all data: decide before you write a line of code which fields are PHI and document it.
• Encrypt at rest and in transit: EBS, S3, database volumes — all encrypted. TLS 1.2+ everywhere, including internal traffic.
• Application-layer audit logging: who, what, when — immutable, retained 6 years, indexed for search.
• RBAC with minimum necessary enforcement: role checks at the service layer, not the controller.
• BAAs signed before PHI touches the vendor: cloud, error tracking, logging, LLM APIs.
• Scrub PHI from error payloads and logs: never let a stack trace carry a patient name or record ID.
• Incident response runbook: who is the Privacy Officer, what is the HHS notification process, who drafts the patient notification.
• Periodic access reviews: quarterly export of all users with PHI access, reviewed by someone accountable.

FAQ: HIPAA for engineers

Building in a regulated environment?

If your team is entering a HIPAA-regulated space for the first time — or inherited a codebase you're not sure is compliant — I've done this work hands-on at a telehealth company and can help you reach a defensible baseline.