Building compliant software in healthcare / Start here
What HIPAA actually requires from your software
The technical safeguards in the Security Rule are five standards and a few implementation specifications. That is a short list, and it is short enough to work through properly. This page does that, in the rule's own terms, and names what each one means for a build.
Published August 22, 2026. Editorial.
Key takeaways
- There are five technical safeguard standards: access control, audit controls, integrity, person or entity authentication, and transmission security.
- Unique user identification and emergency access procedure are Required. Automatic logoff and encryption are Addressable.
- Shared accounts break unique user identification and make every other control unenforceable, because nothing else can attribute an action.
- The Security Rule governs electronic PHI specifically, so the scope question is which of your data is PHI, and that is answered before any of this applies.
The technical safeguards are in 45 CFR 164.312, and the whole section is shorter than most vendor questionnaires written about it. Working through the actual text is a better use of an afternoon than any summary, including this one, but here is what each provision means for a codebase.
Access control, and the specification everything else depends on
The standard requires technical policies and procedures for electronic information systems that maintain electronic PHI, to allow access only to those persons or software programs that have been granted access rights [1].
Four implementation specifications belong to it.
Unique user identification (Required). Assign a unique name or number for identifying and tracking user identity [1]. This is the one everything else depends on, and it is Required rather than Addressable for a reason: nothing else in the Security Rule works without it. Audit controls cannot attribute an action to a person if several people share an account. Minimum necessary cannot be enforced against a role that five people log into. Every control that depends on it assumes it is in place.
It is also the one that fails without anyone noticing in real deployments. Shared clinical workstations with a common login. A break room terminal everyone uses. An integration account that three staff know the password to. A test account in production that turned out to be convenient. Each of those turns every audit entry produced through it into a record of a shared secret rather than a person.
Emergency access procedure (Required). Establish and implement as needed procedures for obtaining necessary PHI during an emergency [1]. This is the provision that makes healthcare access models different from every other industry: the rule requires a way to get in when normal access fails, because the alternative is patient harm.
For a build, that means the emergency access path is not an unfortunate exception you tolerate. It is a required feature, which means it should be designed, tested, and logged like one rather than improvised. And because it bypasses the ordinary model, it needs the strongest audit treatment in the system.
Automatic logoff (Addressable). Electronic procedures that terminate a session after a predetermined time of inactivity [1]. Addressable, so the obligation is to assess it and either implement or document a reasonable alternative. Note the practical tension: aggressive timeouts on a clinical workstation cause staff to work around them, and a documented decision to use a longer timeout with a different compensating control is a legitimate outcome. An undocumented decision is not.
Encryption and decryption (Addressable). A mechanism to encrypt and decrypt electronic PHI [1]. Covered in depth on encryption and the proposed Security Rule update, because the status of this one may be changing.
Audit controls
The standard is one sentence: implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI [1].
Two words in it are important. "Activity" is broader than "changes," and a system that logs writes has recorded a subset of activity. "Examine" implies the records are not merely produced but reviewed, which means a log nobody reads is a partial implementation at best.
This gets its own page at audit controls under the Security Rule, because it is the standard with the widest gap between what teams build and what the rule describes.
Integrity
The standard requires policies and procedures to protect PHI from improper alteration or destruction, with an Addressable specification for electronic mechanisms to corroborate that PHI has not been altered or destroyed in an unauthorised manner [1].
In practice this is about being able to detect tampering, not just prevent it. The engineering answers are familiar: append-only structures for clinical records, checksums or signatures on stored documents, and separation between the credentials that write data and the credentials that could alter history. A system where the application's ordinary database role can rewrite past clinical records has no mechanism to corroborate anything.
Person or entity authentication
Implement procedures to verify that a person or entity seeking access to PHI is the one claimed [1].
The rule does not currently mandate multi-factor authentication here, which surprises people. What it requires is verification, and whether your verification is reasonable is judged against your risk analysis. In practice, password-only authentication on a system holding clinical data is difficult to defend as reasonable in the current threat environment, and the proposed rule update would make MFA explicit. Treat single-factor as a decision you would need to justify, not a default.
Transmission security
Technical security measures to guard against unauthorised access to PHI transmitted over an electronic communications network, with Addressable specifications for integrity controls and encryption [1].
The scope mistake here is the word "transmitted." Teams check the browser-to-server connection, which is nearly always fine, and overlook the internal transmissions: service to service inside a cluster, application to database, application to third-party integrations, batch exports moving to storage, and messages passed through a queue. PHI in transit between two of your own services is still PHI in transit.
The question that comes before all of it
None of this applies until somebody has determined what your PHI actually is, and that determination is where scope errors do the most damage.
PHI is individually identifiable health information, and the identifiability half is what teams underestimate. A record with the name removed is not automatically de-identified. A dataset with dates of service, a postal code, and a rare condition can identify a person without containing a single obvious identifier. Analytics events carrying a user identifier that can be linked back to a patient are PHI in a place nobody labelled as clinical.
Getting this wrong in the permissive direction means controls are applied to a subset of the data that actually needs them, and every control that depends on it has the same error. This is a determination to make with counsel and to write down explicitly, because every check you build afterwards will be scoped by it.
Once it is written down, the method for turning each safeguard into a testable assertion is the same one we use across regulated work, and it is covered on the financial services hub at how to translate a regulation into engineering requirements. The regulation differs; the translation method does not.
If you want help doing that for a healthcare product, get in touch.
Best for
- Teams building a first healthcare product who need to know which obligations reach the code
- Existing products where the risk assessment exists but nobody has mapped safeguards to mechanisms
Avoid if
- What counts as PHI in your system has not been determined, since every control is scoped by that answer
Check before you decide
- Check for shared accounts, shared workstations, and integration credentials known to several people
- Ask whether the emergency access path was designed and tested, or improvised
- List internal service-to-service transmissions carrying PHI, not just the browser connection
- Ask whether anyone reads the audit records, since the standard says record and examine
Common questions
What are the technical safeguards in the HIPAA Security Rule?
Five standards: access control, audit controls, integrity, person or entity authentication, and transmission security. Under access control sit four implementation specifications, of which unique user identification and emergency access procedure are Required while automatic logoff and encryption are Addressable.
Why is unique user identification the most important specification?
Because every other control depends on it. Audit records cannot attribute an action to a person when several people share an account, and minimum necessary cannot be enforced against a role five people log into, so shared workstations and shared integration credentials undermine the entire Security Rule rather than one provision of it.
Is an emergency access path a compliance risk?
It is a Required feature, not a tolerated exception, because emergency access procedure is a Required implementation specification and the alternative is patient harm. What it needs is to be designed, tested, and logged like a real feature, with the strongest audit treatment in the system, precisely because it bypasses the ordinary access model.
Does HIPAA require multi-factor authentication?
The current rule requires procedures to verify that a person seeking access is the one claimed, without mandating a specific method, so MFA is not explicitly required today. In the current threat environment password-only access to clinical data is hard to defend as reasonable, and the proposed Security Rule update would make MFA explicit.
What counts as PHI for scoping purposes?
Individually identifiable health information, where identifiability is the part teams underestimate. Removing a name does not de-identify a record, and a dataset combining service dates, a postal code, and a rare condition can identify someone without containing any obvious identifier, which means analytics events carrying a resolvable user identifier are often PHI stored somewhere nobody labelled clinical.
What does the audit controls standard require from an application?
Section 164.312(b) requires mechanisms that record and examine activity in systems containing electronic PHI, and activity is broader than the changes most applications log. A system that only records writes misses reads entirely, and inappropriate access by an authorised user, the pattern the standard exists to catch, produces no write at all.
What does the integrity standard require under the Security Rule?
Policies and procedures to protect PHI from improper alteration or destruction, with an Addressable specification for a mechanism that corroborates PHI has not been altered or destroyed without authorisation. In practice this means detecting tampering, not only preventing it, through append-only structures for clinical records and separation between credentials that write data and credentials that could rewrite history.
Does transmission security only cover the browser connection?
No. The standard covers PHI transmitted over an electronic communications network, and teams routinely check the browser-to-server connection while overlooking internal transmissions: service to service inside a cluster, application to database, batch exports moving to storage, and messages passed through a queue. PHI moving between two of an organisation's own services is still PHI in transit.
Related reading
A practical pre-launch security review for a small team
You do not need perfect security to launch. You need to check the few basics that find most real problems, and to know when the risk is big enough to bring in a specialist.
What a good technical spec looks like when a model writes the code
The old advice was to keep specs short and stop where writing the code is faster. That advice assumed a person was reading it. When a model writes the code, the cost of an unanswered question changes, and so does the right length of a spec.