Organizations often assume that HIPAA Security Rule “addressable” implementation specifications are optional. In our experience helping healthcare organizations assess security risks, develop compliance programs, and respond to regulatory requirements, that misunderstanding can create significant compliance exposure. The Office for Civil Rights (OCR) has repeatedly demonstrated that covered entities must carefully evaluate, document, and implement addressable specifications when appropriate, or face substantial consequences.
Executive Summary – Key Takeaways
- HIPAA “addressable” requirements are not optional.
- Covered entities must evaluate and document addressable safeguards.
- OCR enforcement actions show that failures can result in substantial penalties.
- Risk analysis and documentation remain common compliance weaknesses.
- Organizations should address security gaps before proposed rule changes take effect.
Table of contents
- Are HIPAA Security Rule Addressable Implementation Specifications Optional?
- How Addressable Specifications Fit Within the HIPAA Security Rule
- Are There Penalties for Ignoring HIPAA Addressable Specifications?
- Resolution Agreements Involving Addressable Specifications
- What Should You Do Now?
- Focus on Security Rule Compliance, Not Required vs. Addressable Distinctions
- Frequently Asked Questions About HIPAA Security Rule Addressable Requirements
Are HIPAA Security Rule Addressable Implementation Specifications Optional?
The answer is a resounding “No”. Covered entities (CEs), AKA “regulated entities,” must have policies and procedures specifying how they will implement all required specifications. They must also actually implement those policies and procedures.
HIPAA regulations require covered entities to also assess each “addressable” specification. CEs must implement these specifications if it is reasonable and appropriate. If they decide implementation is not reasonable and appropriate, they must document the rationale for their decision.
Furthermore, a covered entity must implement an alternative equivalent measure. If no alternative is reasonable or appropriate, a covered entity can consider its risks of unauthorized disclosures and the cost of implementation.
How Addressable Specifications Fit Within the HIPAA Security Rule
The HIPAA Security Rule is one of the lengthier Rules issued by the Federal Government. It was, and still is, a valiant attempt to help all kinds of HIPAA-covered entities maintain the privacy of Protected Health Information (PHI). The HIPAA Security Rule is composed of three distinct Parts: Technical Safeguards, Administrative Safeguards, and Physical Safeguards.
These Safeguards are distributed into implementation specifications. And the implementation specifications are further divided between required specifications and “addressable” implementation specifications. And naturally, for some people, “addressable” has sounded a lot like “optional“.
Are There Penalties for Ignoring HIPAA Addressable Specifications?
You betcha! Each year, the Office for Civil Rights (OCR) of the Health and Human Services (HHS) Department receives hundreds of reports of breaches. These breaches involve unauthorized disclosures of PHI and/or electronic protected health information (ePHI). The OCR publishes what is colloquially known as the Wall of Shame. This is a list of data breaches involving 500 or more records containing PHI. So far in 2026, OCR has received 168 such reports, 91% of which involve disclosures via hacking into information systems, networks, or email. Many of these incidents will be actively investigated by the OCR – eventually.
The wheels grind slowly at OCR, so incidents reported years ago may only reach the resolution stage after several years. Indeed, there were no Resolution Agreements posted for release between August 2025 and March 2026. But the resolution agreements are a source of meaningful information on how the OCR considers breaches that implicated both required and addressable implementation specifications.
Resolution Agreements Involving Addressable Specifications
Many resolution agreements involve both required implementation specifications and addressable implementation specifications. Here is a sample of penalties assessed for addressable implementation specifications:
- Concentra Health Services:
- Alternative to an addressable specification for data encryption, not documented or implemented.
- An unencrypted laptop containing PHI was stolen. Concentra had identified a lack of encryption as an issue, but did not remediate it or document why it was not reasonable to comply. Nor did Concentra document why an equivalent alternative to the specification was not considered and/or why it was not implemented.
- Resolution payment: $1,725,220 (!).
- University of Rochester Medical Center (URMC):
- Alternative to an addressable specification for data encryption not documented or implemented.
- An unencrypted laptop containing PHI of 43 patients was stolen. URMC failed to comply with several required specifications, such as an adequate risk analysis. And it also failed to implement an alternative measure to the encryption/decryption addressable specification.
- Resolution payment: $3,000,000 (!).
- Gulf Coast Pain Consultants (GCPC):
- Alternative to addressable specifications for workforce termination and access modification not documented or implemented.
- A former contractor impermissibly accessed the company’s electronic health record system on three separate occasions. The compromised PHI included patient names, addresses, phone numbers, email addresses, dates of birth, Social Security numbers, chart numbers, insurance information, and primary care information.
- Resolution payment: $1,190,000. (!)
What Should You Do Now?
In almost all cases, the OCR finds fault with the Risk Analysis performed by a healthcare organization. In some cases, the organization never completed a risk analysis at all. So the first thing to do is to review your last HIPAA Risk Analysis. Make sure it is up to date with current systems, a technology asset inventory, and new anticipated threats. Also document any addressable measures you are using as a substitute for the applicable Security Rule standards.
Review this table to see if it is time to revisit an addressable HIPAA implementation specification at your organization:
| Trigger | Why It Matters | What to Review |
|---|---|---|
| System changes, new technology or policies that impact User Training | Policies change, as do systems, capabilities, and vulnerabilities. | Online or locally-produced user training and security awareness measures. |
| More Remote Access or Cloud systems in use | More remote access can create more opportunities for penetration using off-site access methods available to authorized users. | Policies regarding Log-in Monitoring, Password Management, and automatic logoff. |
| Cost of Encryption Methods | Lack of encryption of ePHI available on devices has resulted in large penalties. | Policies regarding downloading of ePHI to devices such as portable memory or laptops/tablets |
| Testing and Revision Procedures/Data Criticality Analysis | Many Covered Entities, both providers and business associates, have endured lengthy system outages that affected their own operations and operations at other entities. | Data backup plans, disaster recovery plans, and Emergency Mode Operations Plans. Such plans need to be tested periodically. And an inventory of applications and data will be sorely needed to prioritize recovery efforts and prevent lost data. |
| Device and Media Controls: Accountability and Data Backup and Storage. | Inadequate device and media controls have been the source of several breaches of ePHI. | Covered entities must keep track of devices with ePHI and maintain accountability for those devices. Disaster recovery and even routine hardware updates are more complicated if an exact copy of ePHI data is not available. |
Focus on Security Rule Compliance, Not Required vs. Addressable Distinctions
In our role as consultants, we have helped dozens of covered entities that have never completed a HIPAA Security Rule Risk Assessment. We have also helped covered entities that have never completed a set of policies and procedures to comply with the Rule. We always advised clients to ignore the difference between addressable and required implementation, and implement policies that comply with the Security Rule standards. That avoids trying to get creative with a solution you hope the OCR will accept when they come to investigate your breach.
As the entries in the HIPAA Breach Portal continue to show, networks with ePHI continue to be targets of hackers and vulnerable to employee mistakes or actual mischief. So, to paraphrase another great saying, “the price of security is eternal vigilance”. And if that is not enough motivation, the proposed rulemaking to the HIPAA Security Rule will make all of the previously addressable implementation specifications required. So maybe it’s time to get a jump on that project now!
Frequently Asked Questions About HIPAA Security Rule Addressable Requirements
No, HIPAA Security Rule addressable specifications are not optional, even though they allow some implementation flexibility.
Covered entities must evaluate each addressable specification and determine whether it is reasonable and appropriate for their organization. If it is, the organization must implement it.
If it is not reasonable and appropriate, the organization must document that decision and implement an equivalent alternative measure when appropriate. The key obligation is not optional compliance, but documented, risk-based decision-making.
Covered entities should document how each addressable specification was evaluated, implemented, substituted, or rejected.
This documentation should explain whether the safeguard was reasonable and appropriate, what risks were considered, and whether an equivalent alternative measure was used. The rationale should be specific to the organization’s systems, workflows, threats, and ePHI environment.
Unsupported conclusions, informal decisions, or undocumented assumptions may create compliance exposure during an OCR investigation.
Ignoring an addressable safeguard can lead to regulatory scrutiny, corrective action, and significant financial penalties.
OCR resolution agreements have shown that addressable specifications matter, especially when they involve encryption, access controls, workforce termination procedures, device accountability, or other safeguards tied to ePHI exposure.
The risk is often compounded when an organization also lacks a current risk analysis, updated policies, or documentation showing how addressable specifications were considered.
A HIPAA risk analysis should identify whether addressable safeguards are reasonable and appropriate based on actual organizational risks.
That review should account for current systems, technology assets, remote access, cloud services, portable devices, user access, backup processes, and emerging threats. It should also identify gaps between existing controls and Security Rule expectations.
The analysis should lead to documented decisions, updated policies, remediation steps, or equivalent alternative measures where needed.
Healthcare organizations should revisit addressable specifications whenever systems, technology, workflows, or risks materially change.
Common triggers include new cloud platforms, expanded remote access, changes in workforce roles, new devices, updated EHR systems, cybersecurity incidents, or gaps found during audits. Cost changes, such as more affordable encryption tools, may also affect what is reasonable and appropriate.
Addressable safeguards should not be treated as one-time decisions. They should be reviewed as part of ongoing Security Rule compliance.
Focusing too heavily on the distinction can distract organizations from the larger obligation to protect ePHI.
OCR generally looks at whether the organization performed a sufficient risk analysis, implemented appropriate safeguards, maintained policies and procedures, and documented its decisions. A narrow focus on whether a safeguard was labeled “required” or “addressable” may miss the practical compliance risk.
For many organizations, the safer approach is to build a complete Security Rule compliance program rather than rely on technical distinctions.