Commentary Addressing Risks and Opportunities Through the Life Cycle of Data, Technology, Advertising and Innovation

Data Counsel

Home | Data Counsel

core/heading

“The code is more what you’d call guidelines than actual rules,” Captain Barbossa famously quipped in Pirates of the Caribbean. Some healthcare organizations may be tempted to view the Health Insurance Portability and Accountability Act (HIPAA) Security Rule’s (Rule) “addressable” implementation specifications the same way. The Office for Civil Rights (OCR); however, has made clear that addressable does not mean optional.

core/paragraph

Security Rule “Addressable” Specifications are not optional: Covered entities and business associates must implement the specification, adopt a reasonable equivalent alternative, or thoroughly document why the specification is not reasonable or appropriate for the organization.

core/list-item

A decision not to implement the specification as written requires a  comprehensive risk analysis of size, resources, existing safeguards, costs, technical capabilities, and the organization’s specific environment—and that analysis must be documented.

Failure to document the assessment and rationale can itself result in a finding of noncompliance, even if the underlying conclusion was reasonable.

core/list

Required and Addressable: What the Rule Actually Says

The HIPAA Security Rule sets forth a number of general requirements for technical safeguards. For example, covered entities and business associates must implement procedures to record and examine activity in systems that contain electronic protected health information (ePHI) and procedures to verify the identity of someone seeking access to ePHI, among other requirements. The Rule also includes two categories of technical implementation specifications: required and addressable.

If an implementation specification is required, a healthcare organization must implement it as written. There is no discretion to substitute an alternative safeguard or forgo implementation based on any assessment. By contrast, addressable implementation specifications provide flexibility and permit HIPAA covered entities and business associates to evaluate whether the specification is reasonable and appropriate for a particular organization.

This flexibility is intentional, and the “addressable” category was created to provide organizations the opportunity to consider their size, resources, security framework, risk analysis and security measures already in place when determining the applicability of an addressable specification. OCR understands that a large urban health system and a small rural physician’s office face different operational realities and that certain Rule requirements are not necessarily a one-size fits-all solution to data security.

Therefore, if a covered entity or business associate determines an addressable specification is not appropriate and reasonable for its organization, it has two options: The organization may: (1) adopt an appropriate and reasonable alternative measure that achieves the same objective; or (2) decide not to implement the specification as written, or any reasonable alternative, at all.

In either scenario, the organization must reach this conclusion through a thoughtful, comprehensive risk-based analysis and thoroughly document its rationale. Failure to document the analysis may result in a finding of noncompliance – even where the ultimate decision not to implement the specification was reasonable.

The Specifications That Create the Most Problems

In our experience, a handful of addressable specifications attract disproportionate OCR scrutiny, and they illustrate why documentation matters.

Encryption of ePHI in transit: Under 45 C.F.R. § 164.312(e), covered entities and business associates must protect ePHI transmitted over electronic communications networks, with encryption identified as an addressable implementation specification. Given the increasing accessibility and relative cost-effectiveness of solutions for encrypting ePHI in transit, organizations that determine this obligation is not reasonable or appropriate, or rely on an alternative, should thoughtfully evaluate and document their conclusion. Given the widespread availability and relatively low cost of encryption technologies, organizations that fail to implement encryption – or an attempt to duplicate its effectiveness via an alternative method –invites heavy scrutiny from OCR and state attorneys general.

Encryption of stored ePHI: The requirement to encrypt ePHI at rest on devices and systems is also addressable (45 C.F.R. § 164.312(a)(2)(iv)). Healthcare companies that store ePHI on unencrypted laptops, drives or servers without a documented rationale face meaningful regulatory exposure. However, encrypting ePHI at rest within a health system’s internal network, for example, can encumbering provider and workforce member access and potentially interfere with patient care. Thus, organizations must carefully analyze the propriety of encryption at rest for various ePHI repositories, depending on their use and function.  That said, there is rarely a scenario where ePHI should not be encrypted at rest on a portable device, like a laptop, which pose a greater risk of exposure through loss or left.  The <a href="https://bh.bakerlaw.com/49/1329/landing-pages/dsir.asp" target="_blank" rel="noreferrer noopener">2026 BakerHostetler Data Security Incident Response Report</a> further confirms that device loss and theft are ongoing challenges for covered entities and business associates

Automatic logoff: 45 C.F.R. § 164.312(a)(2) requires covered entities and business associates to ensure access to ePHI is limited to only authorized people or programs, with automated logoff after a predetermined time of inactivity as an addressable implementation specification. Because automatic logoff functionality is commonly available – and even the default - in modern clinical and business applications, any decision to forego automatic logoff for systems containing ePHI is likely to receive substantial scrutiny.  However, organizations that require rapid access to certain devices for patient care might reasonably conclude that automated logoff functions should be adjusted or limited.  Factors relevant to this conclusion may include the physical security and general accessibility of the location where the device is used, the likelihood of unauthorized access, the proximity of the user when the device is not actively in use, and why automated logoffs would interfere with patient care.

OCR makes clear that a decision to implement an alternative specification, or not to implement a specification at all, depends on a variety of factors, including the covered entity’s or business associate’s security risk analysis and risk mitigation strategy, what security measures are already in place, and the cost of implementation. Other relevant factors include the size of the organization, its resources relative to the cost of the implementation specification, the complexity and technical capabilities of the organization, and any other unique factor related to the reasonableness or appropriateness of the particular specification. The relevance of each factor may vary depending on the specification and the organization.

For each addressable specification, healthcare companies should be able to answer the following:

Did we assess this specification, and when?

What factors, including our size, environment and existing controls, did we consider?

If we implemented an equivalent alternative, how does it provide the same type of protection?

When did we last revisit our assessment, and does it reflect our current environment?

The answers do not have to be verbose, but they should be thoughtful, current and documented. A healthcare company that can answer those questions for each addressable specification is in a fundamentally better position in an OCR investigation than one that cannot.

BakerHostetler can help healthcare organizations evaluate addressable specifications, develop defensible documentation and assess areas that have historically attracted OCR scrutiny. The objective is not to identify a universally “correct” answer but to ensure the organization can demonstrate a thoughtful, risk-based decision-making process.

Captain Barbossa’s approach to the pirate code worked well enough on the high seas. In an OCR investigation, it will not.

Healthcare organizations that treat addressable specifications as optional are not enjoying flexibility. They are creating exposure. In many OCR investigations, the critical issue is not whether the organization reached a particular conclusion but whether it can demonstrate how and why that conclusion was reached. The difference between an organization that can produce a documented good faith assessment and one that cannot is often the difference between a manageable investigation and a resolution agreement, penalty or fine.

This post is part of a series on practical HIPAA Security Rule compliance. It draws on themes explored in “HIPAA at 21 Years of Compliance: Why the Security Rule May Be Entering a More Prescriptive Era,” published by BakerHostetler, and data from the 2026 DSIR.

‘Addressable’ Does Not Mean Optional: The Security Rule Is Not What You’d Call a Guideline