HIPAA's 'Addressable' Specifications Are Not a Skip Button
The HIPAA Security Rule divided its implementation specifications into two categories: required and addressable. Required specifications are what they sound like. Addressable specifications are where the confusion starts, and where most organizations get into trouble.
The standard interpretation of "addressable" in most compliance teams is that it means optional, with paperwork. This is incorrect, and the Office for Civil Rights has made that clear through enforcement actions. "Addressable" means you must conduct an assessment, document your analysis, and either implement the specification or implement a reasonable alternative that achieves the same objective. Deciding that an addressable specification is too expensive or inconvenient and then leaving it out entirely is not a compliant implementation. It is a violation waiting for an investigation.
What "Addressable" Actually Means
The HIPAA Security Rule defines addressable specifications as ones where covered entities must: assess whether each implementation specification is a reasonable and appropriate safeguard for the entity, given the entity's specific security environment; document the assessment; and, if the specification is reasonable and appropriate, implement it. If it is not, the entity must document why and implement an equivalent alternative measure.
There are two paths in that structure, and neither of them is "document that we skipped it." The first path is implementation. The second path requires a documented alternative that actually addresses the same risk.
This matters most for encryption. The encryption of data at rest and the encryption of data in transit are both addressable specifications under the Security Rule. Organizations with a high rate of HIPAA-related enforcement actions have frequently cited inadequate encryption. OCR investigations consistently find the same pattern: the organization knew about the encryption specification, decided it was addressable, and concluded that addressable meant they could skip it. Their documentation of the decision, when it existed at all, said something like "encryption determined not required" with no alternative safeguard identified and no risk analysis supporting the conclusion.
The Risk Analysis Connection
Addressable specifications cannot be evaluated independently of the risk analysis. HIPAA requires covered entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information.
The determination about whether an addressable specification is "reasonable and appropriate" must be grounded in that risk analysis. An organization handling electronic protected health information across mobile devices, cloud storage, and third-party applications cannot reasonably conclude that encryption is not a reasonable and appropriate safeguard and have that position hold up in an investigation. The risk is not abstract. The threat of unencrypted ePHI in transit or at rest is well-documented and routinely exploited.
What gets organizations into trouble is conducting the risk analysis and the addressable specification review as separate exercises, or not connecting them at all. The risk analysis says high risk on unauthorized disclosure of ePHI. The compliance team reviews the encryption specification, marks it addressable, and moves on. Nobody asks whether the risk analysis finding changes the "reasonable and appropriate" calculus. It does, and OCR will make that connection during an investigation even if the compliance team did not.
What an OCR Investigation Actually Looks Like
The Office for Civil Rights investigates HIPAA compliance through complaint-driven investigations and audits. When a breach involving unencrypted ePHI occurs, the investigation typically requests a copy of the covered entity's risk analysis, their policies and procedures related to the specification at issue, documentation of any assessment of addressable specifications, and evidence of the safeguards actually in place.
The gap between what organizations say they do in their policies and what they actually do in practice is a recurring finding. A policy that says "encryption is required for all portable devices" does not help if half the devices in the field are unencrypted because nobody enforced the policy. An organization that had no way of knowing which devices held ePHI cannot demonstrate that it conducted a reasonable assessment of encryption requirements for portable media.
The fine is not the worst outcome. The Resolution Agreement that follows an investigation typically requires a corrective action plan, which means an ongoing OCR oversight relationship that lasts for years. The covered entity is required to report periodically on its compliance activities, and every subsequent incident occurs under a microscope. Organizations that treated HIPAA as a once-per-year compliance exercise find that the oversight relationship forces them to build actual program infrastructure, which is what they should have done at the start.
The Vendor Problem
Business Associate Agreements do not transfer compliance responsibility. A covered entity that stores ePHI with a cloud vendor under a BAA is still responsible for assessing whether the storage meets the encryption requirements. The BAA establishes that the vendor must protect the information appropriately, but it does not eliminate the covered entity's obligation to understand what safeguards are actually in place.
Covered entities that have never read the technical controls documentation for their cloud storage providers, whose IT teams do not know whether data is encrypted at rest in those environments, and whose BAAs have never been reviewed since signature are common. The BAA becomes an organizational permission slip that substitutes for actual technical due diligence. When ePHI is stored unencrypted in a cloud environment and the vendor eventually has a breach, the BAA does not insulate the covered entity from an investigation, and it does not explain why the covered entity never verified that encryption was implemented.
The Fix Is Not Complicated
The compliance gap here is not a technical problem. Encryption is widely available, inexpensive, and straightforward to implement for most use cases. The problem is that "addressable" became a misread permission to defer, and the deferral was never revisited.
The practical fix is to treat every addressable specification that covers a common threat vector, encryption and audit controls chief among them, as effectively required unless the risk analysis can produce a documented, specific rationale that would survive scrutiny. "We assessed that encryption is not required for our environment" needs to be supported by specific technical and operational context, not just checked off. If the risk analysis shows high likelihood of unauthorized ePHI disclosure, the rationale for skipping encryption does not exist.
There is also a review cycle question. Addressable specification assessments are not one-time decisions. When the organization's technology environment changes, when new systems are added, when ePHI flows to new locations, the assessment needs to be revisited. An organization that made a reasonable determination about a specific system in 2019 and never updated it as the environment grew around that system is not in continuous compliance. It is in historical compliance with a system that no longer matches its current state.
The word "addressable" was intended to give covered entities flexibility to implement safeguards in ways appropriate to their specific circumstances. It was not intended to create a category of requirements that organizations could simply choose not to meet. That distinction seems obvious from the regulatory text. It has not, in practice, been obvious to a significant number of covered entities, and the enforcement record shows it.