Building compliant software in healthcare / Start here
Required vs Addressable safeguards, and why it matters
The single most consequential misreading in healthcare software is that Addressable means optional. It does not. It means you owe a documented decision, and the decision is the deliverable. A team that implements an Addressable specification without recording why has done the engineering and missed the obligation.
Published August 22, 2026. Editorial.
Key takeaways
- Addressable obliges you to assess, then either implement, or document why it is not reasonable and implement an equivalent alternative.
- The failure is almost never a deliberate choice. It is that nobody made the decision explicitly, so no record exists to show.
- The decision record needs the assessment, the choice, the reasoning, and the alternative, and it needs a date and an owner.
- Keep the record next to the code it describes, because a decision stored only in a compliance folder is invisible to the people who will change the system.
Every implementation specification in the HIPAA Security Rule is labelled either Required or Addressable. Required means implement it. Addressable means something more subtle, and the subtlety is where a great deal of healthcare non-compliance originates.
What Addressable actually obliges
An Addressable specification obliges you to assess whether it is a reasonable and appropriate safeguard in your environment, given your size, complexity, capabilities, infrastructure, and the likelihood and severity of risks to PHI. Having assessed it, you either implement it, or you document why implementing it would not be reasonable and appropriate and implement an equivalent alternative measure where reasonable.
Read that as a sequence and the structure becomes clear. There are three legitimate end states: implemented, or replaced with a documented equivalent, or documented as not reasonable with the reasoning recorded. There is no fourth state where nothing happened.
That fourth state is nevertheless the most common one in practice, and it is worth being precise about why, because it is not laziness.
The failure is structural, not careless
Consider how automatic logoff works in a real clinical product.
Someone reads the specification. They notice it is Addressable. They know that aggressive session timeouts on a shared clinical workstation cause staff to keep sessions open on purpose, share credentials, and generally work around the control in ways that make security worse. That is a genuinely good analysis, and the conclusion, a longer timeout paired with a different compensating control, may well be correct.
Then the team moves to other work. The analysis happened in a conversation, or only in one person's memory. Nothing is written down. Two years later nobody in the organisation can say whether automatic logoff was considered and rejected for sound reasons or simply never implemented, and from the outside those two situations are indistinguishable. The organisation made a defensible decision and cannot demonstrate it, which for compliance purposes is close to not having made it.
The pattern generalises. Addressable specifications get thoughtful consideration and no artefact. The obligation is specifically to produce the artefact.
What a decision record contains
Five things, and it does not need to be long. Half a page per specification is plenty.
The specification, quoted. Not paraphrased, for the same reason obligations should always be quoted: the paraphrase is where the requirement loses its precision.
The assessment. What did you consider, and what is the risk this control addresses in your specific environment? This is where the clinical workstation reasoning belongs.
The decision. Implemented, implemented with an alternative, or not implemented.
The alternative and its reasoning, if applicable. What are you doing instead, and why is it reasonable given the risk you just described?
A date and a named owner. Because the assessment is supposed to be revisited when the environment changes, and an undated decision cannot be evaluated for staleness.
Keep the record next to the code
Here is the part most compliance guidance gets wrong, and it matters more than the format of the record.
Decision records are usually stored in a compliance folder: a shared drive, a policy management tool, a document nobody in engineering opens. The people who will change the system never see them. So when a developer eighteen months later shortens a session timeout, lengthens one, or removes the compensating control that the decision depended on, they do it without knowing a decision existed.
Put the record where the code is. A file in the repository, referenced from the code that implements the decision, and included in the review path when that code changes. This is not a novel idea; it is how architecture decision records work, and applying it to Addressable specifications solves the invisibility problem directly.
The stronger version pairs the record with an assertion. If you decided to implement encryption at rest, the record says so and a check fails when it is disabled. If you decided on a fifteen-minute timeout as your alternative to a shorter one, the check asserts the configured value. Now the decision is documented and enforced by the same artefact, and any change away from the decision is caught the day it happens rather than at the next assessment. That is the approach on using evals as compliance evidence, applied to the Addressable problem.
Which specifications this applies to
Within the technical safeguards, the Addressable ones are automatic logoff, encryption and decryption, the mechanism to authenticate electronic PHI under the integrity standard, and both integrity controls and encryption under transmission security [1]. Unique user identification and emergency access procedure are Required [1].
Addressable specifications also appear throughout the administrative and physical safeguards, and the same logic applies to all of them.
It is worth noticing which ones are Required, because the choice is informative. Unique user identification is Required because nothing else functions without it. Emergency access is Required because the harm from getting it wrong is immediate and clinical. The Addressable ones are the ones where a sensible organisation might reasonably do something different. That is the purpose of the distinction, and reading it as a list of optional items reverses the intent completely.
The proposed change
The December 2024 Notice of Proposed Rulemaking, published in the Federal Register in January 2025, would remove the Required and Addressable distinction for most specifications and make them mandatory, including encryption and multi-factor authentication [2].
Keep two things in mind. It is proposed, not final, and as of writing the regulatory agenda targets 2027 for final action, so describing it as current law would be wrong. And a proposal that would make your Addressable decisions Required is a good reason to make sure the decisions exist in written form now, because the ones documented with written reasoning are the easiest to revisit when the rules change.
If you want help building the decision records or the checks that enforce them, get in touch.
Best for
- Teams that have implemented sensible controls but cannot produce the reasoning behind them
- Organisations preparing for an audit, a certification, or an enterprise procurement review
Avoid if
- Nobody has done the risk analysis the assessment is supposed to be based on, since the decision record depends on it
Check before you decide
- For each Addressable specification, ask to see the written decision, its date, and its owner
- Check whether the record is stored where engineers will encounter it or in a compliance folder they never open
- Check whether a decision that depends on a configured value has a check asserting that value
Common questions
What does Addressable mean in the HIPAA Security Rule?
It means you must assess whether the specification is reasonable and appropriate for your environment, then either implement it, or document why it is not reasonable and implement an equivalent alternative where reasonable. There are three legitimate end states and none of them is doing nothing.
Why do teams get Addressable specifications wrong?
Not usually through carelessness but through the absence of an artefact. Someone does genuinely good analysis, reaches a defensible conclusion in a conversation, and writes nothing down, which leaves the organisation unable years later to distinguish a considered rejection from a control that was never implemented.
What should a decision record for an Addressable specification contain?
The specification quoted rather than paraphrased, the assessment of the risk in your specific environment, the decision, the alternative and its reasoning if applicable, and a date with a named owner. Half a page per specification is enough, and the date matters because assessments are meant to be revisited when the environment changes.
Where should HIPAA decision records be stored?
In the repository next to the code that implements them, referenced from that code and included in the review path when it changes. Records that are stored only in a compliance folder are invisible to the developers who will later alter a timeout or remove a compensating control without knowing a decision depended on it.
Will the Required and Addressable distinction remain?
A proposed rule published in the Federal Register in January 2025 would remove it for most specifications and make encryption and multi-factor authentication mandatory. It remains proposed rather than final, with the regulatory agenda targeting 2027, so it should not be described as current law, though it is a good reason to get existing decisions into written form now.
How is a Required specification different from an Addressable one?
A Required specification, such as unique user identification or emergency access procedure, must be implemented as written, with no assessment step. An Addressable specification requires an assessment of whether it is reasonable and appropriate for the organisation, followed by implementation or a documented equivalent alternative. Both create an obligation; only one leaves room for a defensible different approach.
How do you write a defensible decision record for an Addressable specification?
Quote the specification rather than paraphrasing it, describe the assessment of risk in your specific environment, state the decision made, explain the alternative and its reasoning if one was chosen instead of direct implementation, and add a date and a named owner. Keeping it to half a page per specification, stored next to the code it describes, is enough to make the decision defensible later.
What happens if an Addressable specification is never assessed at all?
Skipping the assessment leaves the organisation unable to show whether a control was considered and reasonably rejected or simply never built, and from outside those two situations look identical. Since Addressable creates an obligation to assess and document, an unassessed specification is a gap in the same way an unimplemented Required specification is, even though the underlying control might have been unnecessary.
Related reading
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.
Adding eval tests was the best decision we made
We generate every line of code we release. The single change that made that safe was writing the check before the code, and it turned out to change how we review, how we spec, and how fast we can work.