HIPAA engineering practices: what the BAA doesn't build for you
Practice · HIPAA Security Rule
A signed Business Associate Agreement is a legal contract, not an engineering control: the HIPAA Security Rule at 45 CFR §164.312 requires 5 controls (access control, audit control, integrity, authentication, and transmission security), and its §164.312(b) audit control means an automated, append-only audit trail of every ePHI access that a BAA presumes already exists.
What does HIPAA require of engineering beyond a signed BAA?
A Business Associate Agreement is a legal contract, not an engineering control. The HIPAA Security Rule at 45 CFR §164.312 requires 5 technical controls: access control, audit control, integrity, authentication, and transmission security.
A vendor SDK embedded for convenience is exactly where those safeguards quietly go missing, because nobody on the engineering team can see what it actually transmits.
A BAA is a contract; §164.312 is an engineering spec
The Business Associate Agreement establishes who is liable if ePHI is mishandled. It does not implement access control, does not generate an audit trail, and does not encrypt anything. The HIPAA Security Rule's technical safeguards at 45 CFR §164.312, 5 controls in all, are the actual engineering requirements for PHI systems — and they're where BAA-covered vendors most often fall short, because a contract can't retroactively add a control that was never built.
Direct protocol boundaries over vendor SDKs
The single most common way ePHI leaves a controlled boundary unintentionally is a third-party SDK embedded for a secondary purpose — analytics, crash reporting, a support-chat widget — that transmits more than anyone reviewed. A Bare Metal approach prefers a documented, first-party API boundary (an endpoint your own team owns and can inspect every field crossing it) over a vendor SDK whose outbound payload is a black box. If you can't `curl` the exact request an SDK sends, you can't attest to what it does with ePHI.
Audit control means append-only, not "we have logs"
Under the HIPAA Security Rule, §164.312(b) requires audit
controls — mechanisms that record and allow examination of
activity, which for PHI systems means an append-only audit trail. A log table with an `UPDATE`/`DELETE` code
path is not an audit control; it's a document someone can quietly edit
after the fact. This repository's own telemetry_observed_events
table is a concrete, running example: no code path issues `UPDATE` or
`DELETE` against it, and CRM state transitions
(crm.opportunity_state_changed) and redirect hits
(discovery.redirect_hit) are both written as append-only rows
with a server-assigned timestamp — the same pattern a HIPAA audit-control
implementation needs, just applied here to a different domain.
Sovereign data control
Every ePHI-adjacent system boundary should be one your own team can name: which database, which region, which process reads it. A third-party analytics or logging SaaS that receives a copy of request data is a second, unaudited system of record for data your BAA says you're responsible for — sovereignty means minimizing how many boundaries like that exist, not just signing an agreement with each one.
Technical safeguards checklist
Mapped directly to §164.312's five subsections. Download the full version below.
(a) Access Control -- unique IDs, emergency access, auto-logoff, encryption at rest
(b) Audit Controls -- append-only records, regular review, no edit path
(c) Integrity -- tamper-evidence, unauthorized-alteration detection
(d) Authentication -- verify identity, no shared service credentials
(e) Transmission Security -- encryption in transit, integrity controls on transmissionEngineering reference only. Not formal legal or regulatory counsel. Consult your own privacy/security officer and legal counsel for a specific HIPAA compliance determination.
Artifact: hipaa-technical-safeguards-checklist.md
Generated client-side; no server round-trip, no account required.
# HIPAA Security Rule — Technical Safeguards Checklist (v1.0.0)
Engineering reference checklist mapped to 45 CFR §164.312. A signed BAA is a
legal contract; this checklist is the engineering work the BAA presumes
already exists. Not formal legal counsel.
## §164.312(a) Access Control
- [ ] Unique user identification for every account touching ePHI (no shared logins)
- [ ] Emergency access procedure documented and tested
- [ ] Automatic logoff after a defined idle period
- [ ] Encryption of ePHI at rest, keyed per the org's key-management policy
## §164.312(b) Audit Controls
- [ ] Hardware/software/procedural mechanisms record and examine activity in
systems containing ePHI
- [ ] Audit records are append-only (no UPDATE/DELETE path against them)
- [ ] Audit records are reviewed on a defined cadence, not only after an incident
## §164.312(c) Integrity
- [ ] Mechanism to authenticate that ePHI has not been altered or destroyed
in an unauthorized manner
- [ ] Tamper-evidence (e.g. a hash chain) on records where integrity is
safety- or compliance-relevant
## §164.312(d) Person or Entity Authentication
- [ ] Verify a person/entity seeking access to ePHI is who they claim to be
- [ ] No shared service-account credentials without individual attribution
## §164.312(e) Transmission Security
- [ ] Encryption of ePHI in transit
- [ ] Integrity controls on transmitted ePHI (detect improper modification)
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- HIPAA Security Rule, 45 CFR §164.312 — U.S. Department of Health and Human Services
- ISO 27001:2022 — International Organization for Standardization
- Ingested from
-