HIPAA technical safeguards, translated for engineering teams

The Security Rule's technical safeguards are five short paragraphs of regulation that generate a large amount of confused engineering. Part of the confusion is structural: the rule deliberately does not prescribe technology, because it has to apply to a two-person clinic and a national insurer alike.

This is that section translated into the decisions a team actually has to make. It is not legal advice, and your risk analysis governs the specifics.

The vocabulary that trips people up

Each safeguard is marked required or addressable. Addressable does not mean optional. It means: implement it, or document why it is not reasonable and appropriate for your environment and implement an equivalent alternative.

A decision not to encrypt with no written rationale is not an addressable decision. It is a finding.

The five safeguards as engineering work

Safeguard	Status	What satisfies it in practice
Access control	Required	Unique user IDs, emergency access procedure, automatic logoff, encryption/decryption
Audit controls	Required	Records of activity in systems containing PHI, retained and reviewable
Integrity	Addressable	Mechanisms to detect improper alteration or destruction of PHI
Person or entity authentication	Required	Verify that whoever seeks access is who they claim to be
Transmission security	Addressable	Integrity controls and encryption for PHI in transit

Access control

Unique user IDs is the one that catches teams. A shared service account used by three engineers to query production defeats every downstream control, because the audit log can no longer attribute anything to a person.

Automatic logoff is not just a session timeout in the web app. It applies to any interface reaching PHI, including database clients and admin tools.

The emergency access procedure is the requirement teams forget entirely: a documented way to reach PHI when normal authentication is unavailable, which is auditable rather than a shared password in a drawer.

Audit controls

The rule says record activity. It does not say what activity, which means your risk analysis decides. In practice, a defensible baseline records who accessed which record, when, from where, and what changed.

Two failures are common. The first is logging writes but not reads: for PHI, an inappropriate look is the more likely incident. The second is logs nobody can query, which satisfies the letter and fails the purpose.

Integrity

This is about detecting improper alteration, and it is where checksums, database constraints, and immutable audit trails do the work. Append-only history for clinical records is the usual pattern: corrections create a new version rather than overwriting, and both remain retrievable.

Authentication

Multi-factor for anything reaching production is the practical baseline, whatever the rule's minimum. The gap here is usually not the application; it is the surrounding access: the VPN, the cloud console, the database, and the CI/CD system that can deploy code that reads PHI.

Transmission security

TLS everywhere is the easy part and mostly solved. The parts that get missed:

• Backups and exports. Encrypted at rest, and encrypted wherever they are shipped.
• Third-party telemetry. Error trackers and session replay tools transmit whatever is on screen.
• Email and file drops. Still the most common way PHI leaves an organization unencrypted.

What the checklist does not cover

The technical safeguards are one of three sets. Administrative safeguards (risk analysis, workforce training, incident response) and physical safeguards (facility access, device and media controls) carry equal weight, and the administrative ones are where audits most often focus, because a documented risk analysis is the foundation everything else rests on.

Encryption also carries a specific incentive worth knowing: PHI encrypted to the standard in the Breach Notification Rule guidance is not considered breached if it is lost, which converts a reportable event into a non-event.

Where this meets the contract

If you are a vendor rather than a covered entity, these obligations reach you through a Business Associate Agreement, and that agreement determines which of them you are directly liable for. What that document does and does not commit you to is covered in what a BAA actually obligates.

If a language model is anywhere in the path, the logging and review requirements interact directly with how you design around it: see putting an LLM in production.

How we implement these on engagements is written up in our security practices, and what we do and do not do with client data is in our privacy policy.