What does Addressable mean Under the HIPAA Security Rule?

Addressable in the context of the HIPAA Security Rule refers to an implementation specification that requires a documented decision grounded in risk, with one of three outcomes recorded: implement as written, implement an equivalent alternative, or do not implement because it is not reasonable and appropriate in that environment.

What does “Addressable” require?

Under the HIPAA Security Rule, an addressable implementation specification requires a documented determination grounded in the entity’s risk analysis rather than automatic adoption. The decision must state whether the specification will be implemented as written, implemented through an alternative control that provides equivalent protection, or not implemented because it is not reasonable and appropriate in the specific environment. The record should identify the safeguard, systems and workflows affected, the risk scenario being addressed, and the way the chosen approach reduces risk to a reasonable and appropriate level. Policies and procedures must reflect the determination, operational evidence must show that the choice was put in place, and the file must carry an effective date, responsible roles, and a defined review cadence tied to changes in technology, operations, or threats. Documentation must be retained for six years from creation or last effective date and kept accessible to personnel responsible for implementation and oversight.

How the “Addressable” HIPAA Decisions are Made?

Decisions are made using the HIPAA Security Rule’s flexibility of approach, which requires consideration of organizational size, complexity, and capabilities, the technical infrastructure in place, the costs of available options, and the probability and criticality of risks to electronic protected health information. The analysis is anchored in the Security Management Process, beginning with an accurate and thorough risk analysis and continuing through risk management activities that bring residual risk to a reasonable and appropriate level. The determination should weigh current and emerging threats, feasibility and operational impact, interaction with vendors and business associates, and any state or contractual obligations that bear on the safeguard. When an alternative control is selected, the record must explain how it achieves equivalent protection and how its effectiveness will be monitored. Approval by the designated authority, assignment of implementation ownership, and a schedule for periodic re-evaluation complete the decision trail an auditor can follow.

Documentation and Retention

Policies, procedures, analyses, and rationales for addressable decisions must be documented in writing, stored in a controlled repository, and retained for six years from the date of creation or the date last in effect. Documentation must remain accessible to personnel responsible for implementation and operation of the related safeguards. The record set should cover the full lifecycle of each decision: the risk scenario prompting the review, the analysis performed, the determination made (implement as written, implement an equivalent alternative, or not implement), and the operational evidence that the determination was carried out.

Common Addressable Items that need Determinations

Certain implementation specifications in the technical safeguards are designated as addressable and require explicit, documented determinations. Automatic logoff, encryption and decryption of ePHI at rest, mechanisms to authenticate ePHI integrity, and encryption of ePHI in transit are addressable implementation specifications that require written decisions tied to the risk analysis. For automatic logoff, define session timeouts by workstation type and clinical context, document any exceptions where clinical safety would be impaired, and record compensating measures such as workstation locking, proximity badges, or screen privacy filters. For encryption at rest, cover laptops, mobile devices, servers, databases, and backups, specify the cryptographic standard and key management, and document any narrow exceptions with compensating controls and a retirement plan. For integrity mechanisms, describe the method used to detect unauthorized alteration of ePHI, including checksums, digital signatures, application controls, or write once storage, and explain how alerts and audit trails are reviewed. For transmission security, state how ePHI is protected over networks, including TLS for client server traffic, secure messaging for internal communications, and encrypted email or patient portals. For each item, name responsible roles, provide implementation evidence, and set a review cadence that aligns with system or workflow changes.

Topic	Regulation
Security Rule general requirements, addressable process, flexibility factors	45 C.F.R. § 164.306 (eCFR; current to September 10, 2025)
Risk analysis and risk management	45 C.F.R. § 164.308(a)(1)(ii)(A)–(B) (eCFR)
Documentation and retention	45 C.F.R. § 164.316(b) (eCFR)
Technical safeguards identified as addressable	45 C.F.R. § 164.312 (eCFR)
Business associate obligations for delegated safeguards	45 C.F.R. § 164.314 (eCFR)
Proposed changes to required vs addressable, encryption, MFA	HHS OCR NPRM fact sheet (last reviewed Dec 27, 2024); Federal Register proposed rule 90 FR 898 (Jan 6, 2025)

Interaction with Vendors

When a safeguard or an approved alternative is performed by a service provider, the decision and its operation must appear in business associate terms and in documented due diligence. Contracts should allocate responsibility for each control, require implementation of the specified safeguard or an equivalent alternative, obligate flow down of duties to subcontractors, and set reporting timelines for security incidents and breaches. Provisions should require administrative, physical, and technical safeguards that are reasonable and appropriate, allow termination for material breach, require return or secure destruction of ePHI at contract end, and provide for access to relevant records by HHS. Due diligence should capture evidence that includes security architecture descriptions, configuration baselines, audit log availability, encryption and key management practices, authentication requirements, data location disclosures, backup and recovery procedures, and independent assurance reports where applicable. For cloud or managed services, a written shared responsibility matrix should identify which party implements each addressable specification, explain how effectiveness will be monitored, define metrics or attestations to be delivered, and describe how service or system changes will trigger review and update of the underlying determinations.

Practical Output of a Defensible Decision Record

A defensible decision record organizes the risk scenario, the determination with rationale, the implemented control or alternative, and the review plan in a form that can be independently verified.

• Risk scenario addressed and the systems or workflows involved
• Implementation choice: specification as written, equivalent alternative, or not implemented with rationale
• How the choice reduces identified risk to a reasonable and appropriate level
• Effective date, responsible role, and review cadence tied to environmental or operational change
• Cross-references to policies, procedures, and technical standards used for deployment and monitoring

Current Law and a Proposed Changes

Under the rule in effect today, the required–addressable framework remains in place. HHS has proposed to remove the distinction and make all implementation specifications required, with limited exceptions, along with new minimums such as required encryption and multi-factor authentication; the NPRM was published on January 6, 2025, and has not been finalized. Until a final rule is issued, current requirements continue to apply.