◀ Knowledge hub

04, Identity & secrets

HIPAA and data residency on a modern stack

codeAmani Labs Engineering
Cinematic still for HIPAA and data residency on a modern stack

Compliance is an architecture, not a checkbox

You cannot bolt HIPAA or a data residency rule onto a finished system. The requirements are about where data lives, who can reach it, and whether you can prove what happened, and those are decisions baked into the architecture from the first commit. The good news is that a well built modern stack already has the pieces; the work is wiring them deliberately.

Keep protected data inside a boundary you control

The first question is where the regulated data physically lives and what touches it. Run the database in a region that satisfies the residency rule. Use a secrets manager you can self host so credentials never leave that boundary either. Where a third party model would otherwise see protected information, either strip the protected fields before the call or use a model you run yourself (see the self hosted models guide). The principle is simple: protected data does not cross a boundary you cannot account for.

Enforce access at the database, not just the application

A reviewer wants to know that one patient's record cannot reach another tenant's screen. The credible answer is row level security in the database (see the Supabase guide), so the isolation holds even if an application query is wrong. Identity comes from a managed auth provider; the database enforces what that identity may read. Access control that lives only in application code is access control one forgotten clause away from a breach.

Audit trails are a feature, not a log file

HIPAA expects you to know who accessed what and when. Build that as real data, an append only record of access events, not as lines in a log that rotate away. The audit trail is queryable, retained per policy, and never silently dropped. "We can tell you exactly who viewed this record" is a sentence the architecture must be able to back up.

Do not leave protected data in the fast layers

Caches, edge key value stores, and logs are where protected information leaks by accident. Keep it out of them. A medication form belongs in the governed database, not cached at the edge or printed into an error message. This was a real constraint on a healthcare build on this stack: no protected health information left in the cache, by design.

The honest posture

Name what is roadmap and what is in place. Overclaiming compliance is worse than admitting a gap, because a buyer who catches one overstatement stops believing all of them. Build the controls, prove them, and describe them exactly as they are.

Qualified conversation

Have a build to de-risk? Let's talk.

Tell us what you are building. We respond within two business days.