How to document an addressable HIPAA specification decision

What is the difference between addressable and required HIPAA specifications?

A required specification must be implemented. An addressable one requires a documented decision, so addressable does not mean optional. Under 45 CFR 164.306(d)(3), a covered entity or business associate must assess whether each addressable specification is a reasonable and appropriate safeguard in its environment. If it is, you implement it. If it is not, you must document why and implement an equivalent alternative measure if that alternative is reasonable and appropriate. HHS states in its guidance on addressable specifications that these decisions "must be documented in writing."

That applies to business associates as fully as to providers. A law firm handling medical records for a healthcare client, an accounting firm billing for a medical practice, or a nonprofit running a health program can all carry these obligations. A reasonable choice that was never recorded looks the same as no choice when a covered entity client, an auditor or the HHS Office for Civil Rights asks to see it.

Which HIPAA specifications are addressable?

Addressable specifications are marked "(Addressable)" in the regulation text. Several that come up often for a professional services firm are:

• Encryption and decryption of ePHI at rest, 45 CFR 164.312(a)(2)(iv)
• Encryption of ePHI in transit, 45 CFR 164.312(e)(2)(ii)
• Automatic logoff, 45 CFR 164.312(a)(2)(iii)
• Security reminders for workforce members, 45 CFR 164.308(a)(5)(ii)(A)

Required specifications, such as the risk analysis under 164.308(a)(1)(ii)(A), do not allow this choice. They must be implemented.

What must a written decision contain?

A defensible decision record answers four questions: what you assessed, what you decided, why, and what you did instead if you did not implement the specification. The rule does not prescribe a format. A one-page record per specification works well and is easy to update.

Build each record with these elements:

• The specification, cited by section number and name.
• The link to your risk analysis. The decision should rest on the risks your analysis identified for the systems that hold ePHI, as required by 164.308(a)(1)(ii)(A).
• The factors you weighed. Section 164.306(b)(2) lists them: your size, complexity and capabilities; your technical infrastructure, hardware and software security capabilities; the costs of security measures; and the probability and criticality of potential risks to ePHI.
• The decision: implement as written, implement an equivalent alternative, or neither, with the reason stated plainly.
• The alternative measure, if any, and how it addresses the same risk.
• The systems and data the decision covers, so a reader can tell where it applies.
• Who made the decision, who approved it, and the date.
• When it will be reviewed, and what change would trigger an earlier review, such as a new system or a change in how ePHI flows.

Cost can be a factor, but it is one of four. A record that cites only cost, with no reference to risk, is hard to defend. For encryption in particular, the bar for "not reasonable and appropriate" is high when standard business laptops and cloud services already include it.

How long must you keep the documentation?

Six years. Under 45 CFR 164.316(b), Security Rule documentation must be retained for 6 years from the date of its creation or the date when it last was in effect, whichever is later. It must also be available to the people responsible for implementing the procedures and reviewed periodically, then updated in response to environmental or operational changes.

Section 164.306(e) adds a parallel duty to review and modify security measures as needed. A decision written in 2021 for an office file server does not describe a firm that has since moved to cloud storage. When the environment changes, the decision record should change with it, and the old version should be kept for the retention period.

What happens if the decision is weak or missing?

A missing decision record leaves the firm without evidence that it addressed the specification at all. Recent OCR enforcement actions point the same way. In April 2026, OCR settled four ransomware investigations that cited risk analysis failures, and in September 2026 it settled with Ambry Genetics for $700,000 in a matter where OCR cited a risk analysis failure. Addressable decisions depend on that same risk analysis, so a weak analysis undermines every decision built on it. Our article on why OCR keeps enforcing the risk analysis explains what a defensible analysis includes.

For business associates there is a second audience. Covered entity clients may send security questionnaires, and "we decided encryption was not reasonable" with no record behind it is a hard answer to give.

Will the proposed HIPAA Security Rule remove "addressable"?

It would if finalized as proposed. HHS published a proposed rule on January 6, 2025. The HHS fact sheet says it would "remove the distinction between 'required' and 'addressable' implementation specifications" and "make all implementation specifications required with specific, limited exceptions."

Timing is uncertain. The federal regulatory agenda lists final action for July 2027 as a long-term action. Until a final rule is published, the current rule applies, and so does the duty to document addressable decisions. For the latest, see where the HIPAA Security Rule update stands.

Good decision records hold their value either way. If the distinction disappears, the records show which safeguards you already have and where the gaps are. If the final rule keeps limited exceptions, the same documentation habits will support them.

What should you do this quarter?

Work through the addressable specifications one at a time:

• List every addressable specification in the Security Rule and note whether a written decision exists for each.
• For each one without a record, confirm whether the safeguard is already in place. Built-in device encryption or screen lock settings may already cover a specification without any written record.
• Write the decision record using the elements above, tied to the current risk analysis.
• For any decision not to implement, check whether an equivalent alternative is in place and record it.
• Have the person responsible for the security program approve and date each record.
• Store the records with your other Security Rule documentation and set a review date.
• Recheck any record older than your last major system change.

How does s90 help?

s90 keeps a risk register for each client and records security decisions alongside the evidence that supports them. Our Technology Posture Report shows which safeguards are in place across your systems, which makes addressable decision records faster to write and easier to keep current. If you would like help reviewing your existing decisions, we are glad to start there.