HIPAA's technical safeguards at 45 CFR 164.312 cover five standards: access control, audit controls, integrity, authentication and transmission security. A VP of engineering can turn them into a short spec with named owners, then keep evidence that each control runs in production.
What does 164.312 say?
The text says a covered entity or business associate must implement technical policies and procedures so that only authorised people or software reach electronic PHI. It then lists:
- Access control: unique user identification and emergency access procedures are required; automatic logoff and encryption and decryption are addressable.
- Audit controls: mechanisms that record and examine activity in systems that use ePHI.
- Integrity: protection against improper alteration or destruction, with a mechanism to authenticate ePHI as addressable.
- Person or entity authentication: verify that whoever seeks access is who they claim to be.
- Transmission security: guard against unauthorised access in transit, with integrity controls and encryption addressable.
Required or addressable: what changes?
Required means do it. Addressable means assess whether it is reasonable and appropriate; if so, implement it, and if not, document why and adopt an equivalent alternative. Treating addressable as optional is a common reading error. For modern cloud systems, encryption in transit and at rest is nearly always reasonable, so expect to implement it.
How do the standards map to a system?
A constructed mapping for a clinical messaging service:
- Unique IDs: no shared service accounts for human access. Engineers reach production through individual, SSO-backed identities.
- Emergency access: a break-glass role with approval, time limit and alerting, tested twice a year.
- Automatic logoff: session lifetime set in the identity provider and enforced in the app.
- Audit controls: every read and write of a PHI record emits an event with actor, object and time, shipped to storage that engineers cannot edit.
- Integrity: checksums or database constraints, immutable object versions for uploaded documents.
- Authentication: MFA for staff, strong authentication for customer admins.
- Transmission security: TLS everywhere including internal hops, with certificate expiry monitoring.
Where do teams slip?
The gaps usually sit around the edges: logs holding PHI, a debug endpoint left open, a staging database loaded with real records, a support tool with broad read access, a third party library with a known flaw reaching the PHI service. Audit logging often records writes but not reads, which defeats the point for investigation.
How do you show it works?
Auditors and customers ask for evidence, not intent. Keep screenshots or exports from configuration, access review records, a sample audit trail for one record, restore test results and a list of dependencies with vulnerability status. Automate collection so it runs on a schedule. Safeguard's compliance automation and dependency scanning can feed some of that evidence, but the control design stays with your team.
What to do
- Write the 164.312 mapping above for your own services, with an owner for each row.
- Remove shared accounts and add a tested break-glass path.
- Log reads as well as writes for PHI objects, and protect log storage.
- Enforce TLS and encryption at rest, and monitor certificate and key expiry.
- Keep PHI out of staging and logs, or mask it.
- Scan dependencies in PHI services and set fix targets by severity.
- Schedule a quarterly review that collects evidence.
Quick check
Does HIPAA require encryption?
Encryption and decryption of ePHI, and encryption in transit, are addressable specifications. You implement them when reasonable and appropriate, or document an equivalent measure. For most cloud workloads that means encrypting.
Do audit controls need to log reads?
The standard asks for mechanisms that record and examine activity in systems using ePHI. Logging access, not only changes, is the usual way to make that examination possible.
Sources
Last reviewed: 18 October 2026.
