Which Update Proposes Making More Security Rule Specifications Fully Required? A Deep Explainer

The update in question is a proposed rule from the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR), published in the Federal Register in January 2025. It proposes to convert many of the HIPAA Security Rule's "addressable" implementation specifications into "required" specifications. That single change is the engine behind most of the proposal's other requirements.

The HIPAA Security Rule has always split its implementation specifications into two buckets: required and addressable. Required specifications must be implemented as written. Addressable specifications are not optional, but covered entities have had broad latitude to decide whether a given specification is "reasonable and appropriate" and to document why if not. The proposed update narrows that latitude sharply, removing the addressable category for a large set of specifications and folding their content into mandatory requirements. The practical effect: fewer defensible reasons to skip a control, and far more documentation that auditors can demand.

This matters beyond compliance theater. The Security Rule governs how protected health information (PHI) is safeguarded across electronic systems at covered entities and their business associates. For two decades, addressable specifications gave smaller organizations a legal escape hatch. The proposal treats that hatch as a security gap. Understanding the mechanism explains why the change is structural rather than cosmetic, and what actually changes on the ground.

The addressable-versus-required mechanism

The Security Rule is organized around standards, and standards contain implementation specifications. Required specifications are mandatory. Addressable specifications are conditional: a covered entity must assess whether each one is reasonable and appropriate for its environment, implement it if so, and if not, document the equivalent alternative measure and the rationale. This is sometimes misread as "optional." It is not. But the assessment-and-documentation pathway has real operative weight.

The proposed update collapses that distinction for most specifications. Rather than letting an organization decide that, say, encryption or automatic logoff is not reasonable for its size, the rule would make the underlying control required. The documented-alternative pathway narrows to a small residue. This changes the compliance question from "did you evaluate this and justify your choice?" to "did you implement this, and can you show it?"

The deeper why is about auditability. Addressable specifications produce case-by-case reasoning that is hard to verify at scale. A required specification produces a binary test: present or absent. Regulators and security assessors prefer binary tests because they can be automated, sampled, and scored. That is the mechanism behind the proposal's broader push toward inventories, asset registers, and periodic technical testing.

What the proposal quantifies

The driving evidence is the scale and concentration of health data breaches. OCR's breach reporting portal has logged thousands of breaches affecting 500 or more individuals since reporting began, and the largest incidents routinely affect millions of people each. Hacking and IT incidents have displaced lost devices as the dominant breach type over the past decade, which is precisely the attack surface the Security Rule's technical safeguards target.

The proposal also strengthens risk analysis, the foundational standard. Risk analysis has long been the most frequently cited deficiency in OCR enforcement settlements. OCR has repeatedly noted that a sound risk analysis is the backbone of a compliant program, and that failures there cascade into failures everywhere else.

The scale of the regulated population explains the caution. Covered entities and business associates number in the hundreds of thousands to millions depending on how you count, and most are small practices, clinics, and vendors without dedicated security staff. A rule that converts dozens of judgment calls into fixed requirements changes their workload materially. That is why the proposal pairs stricter requirements with extended compliance timelines rather than an immediate effective date.

Edge cases and who feels them most

Small practices are the sharpest edge case. A solo practitioner has the same required specifications as a hospital system but a fraction of the resources. The proposal acknowledges this through phased timelines and a tiered structure, but the underlying controls do not shrink to fit.

Business associates are the second edge case. The Security Rule's requirements flow down through contracts, and business associates must implement safeguards for the PHI they handle. When addressable specifications become required, downstream vendors inherit harder obligations, and covered entities inherit harder vendor-management duties. Contracts and business associate agreements will need rewriting to reflect the new baseline.

The third edge case is legacy systems. Some organizations kept old infrastructure because an addressable specification let them argue the control was not reasonable for that system. Once the specification is required, an unsupported system becomes a compliance liability that must be replaced, isolated, or formally retired.

A counterintuitive detail: making a specification required does not automatically make it achievable. A control can be mandatory and still technically infeasible for a given environment; the proposal's answer is documentation and compensating measures, not a free pass. The professional caveat is that "required" raises the burden of proof, not the ceiling of what an underfunded organization can actually do.

Red flag: treating addressable as "optional" and skipping the assessment entirely. Red flag: a risk analysis that lists threats but never connects them to safeguards. Red flag: vendor agreements that predate the new requirements and were never updated. Red flag: encryption decisions made once and never revisited as systems changed. Red flag: asset inventories that omit cloud services and mobile devices.

Common misconceptions

The most common error is belief that the proposal creates brand-new controls from nothing. Most of the specifications it makes required already existed; what changes is their legal status and the associated documentation burden. Organizations that were already implementing them diligently will see less change than they fear. Organizations that leaned on addressable flexibility will see more.

A second misconception is that "required" means "one specific product." It does not. Required specifications describe outcomes and capabilities, not vendors. Encryption remains a concept, not a purchase order, though in practice it usually means adopting a recognized standard.

A third misconception is that the proposal is already law. It is a proposed rule. It goes through a public comment period, and the final rule may differ in scope, timelines, and which specifications convert. Treating proposal text as final is a planning error in both directions: over-investing early or under-preparing because "it's not final yet."

Comparison of specification pathways

The table summarizes the shift in kind, not degree. The right column is easier to audit and harder to argue around.

Timeline of the rulemaking

The timeline matters because planning against a proposal is speculative. Use the proposal to anticipate direction, not to lock budgets. The compliance phases are the operative dates once a final rule lands.

Practical actions before the final rule

Start with the risk analysis. Map every system that touches PHI, including cloud services, mobile devices, and vendor portals. If your inventory is incomplete, that is the first gap to close. The proposal's required specifications all assume you know what you are protecting.

Second, convert addressable assessments into implementation plans. For each addressable specification, decide now whether you implement it or document an alternative, and record the reasoning. When the requirement flips, the plan is already drafted.

Third, reconcile the control thresholds across frameworks. The Security Rule's technical safeguards overlap with recognized security practices and with common control frameworks; align documentation so one artifact satisfies multiple obligations. This avoids duplicate work and inconsistent evidence.

Fourth, revisit encryption and access controls specifically. Encryption of PHI at rest and in transit, multi-factor authentication, automatic logoff, and audit logging are the specifications most likely to tighten. Confirm current state and set a remediation threshold: if a control is absent, schedule it rather than debating it.

Fifth, update business associate agreements. Add language that reflects the required baseline and requires notification of material changes. Vendor management is where most small entities will feel the rule first.

Sixth, budget for the long tail. Required specifications do not expire; they become permanent operating costs. Plan for periodic technical testing, logging review, and documentation refresh as recurring line items, not one-time projects.

The plain-language version: know your data, write down your controls, and prove they work.

Limitations and what cannot be concluded

The proposal's final scope is unknown. Comment periods routinely change timelines, definitions, and which specifications convert. Any statement about exact deadlines or exact counts of converted specifications is provisional until the final rule publishes. This article describes mechanism and direction, not binding text.

The evidence base also has limits. Breach statistics show correlation between incidents and safeguard gaps, but they do not prove that any single specification prevents a given breach. Security is layered, and required controls raise the floor rather than guarantee outcomes. Organizations should not treat compliance as equivalent to security, nor security as equivalent to compliance.

Finally, this is general educational information about a proposed federal rule, not legal advice or a compliance determination for any organization. Covered entities and business associates should consult qualified counsel and security professionals about their specific obligations.