apointoo.
Request access
HIPAA

Current HIPAA Security Rule vs Proposed Changes in 2026

cmsapointoo··9 min read

Short answer: The current HIPAA Security Rule remains the enforceable baseline as of August 15, 2026. Proposed changes are planning signals, not current obligations, until a final rule is issued and becomes effective. Build controls that satisfy the current rule, label every proposal separately, and ask qualified counsel to confirm which contractual or regulatory changes should influence the roadmap.

Start with the version that is effective today. HHS publishes the current Security Rule laws and regulations, and the eCFR contains the operative safeguard provisions. Those provisions require documented administrative, physical, and technical safeguards, risk analysis and risk management activities, and documentation of decisions. The current rule does not become optional because a proposed update is under discussion.

HHS may publish a notice of proposed rulemaking that would change the Security Rule. A proposal is not enforceable law. It can be withdrawn, revised, delayed, or finalized with different language and dates. As of August 15, 2026, label proposal text, agency statements, and planning assumptions as proposed or expected. Never write that a proposal requires an annual control, a specific technology, or a specific test unless the current effective rule says so.

The safest approach is a two-column register. The first column holds current obligations and their evidence. The second holds proposed changes, contract requests, and voluntary improvements. A third column can record whether the organisation chooses to prepare early, with an owner and budget estimate. That prevents planning work from becoming a false legal claim.

Compare current and proposed requirements

Review area Current-rule treatment Proposed or planning treatment
Risk analysis Perform and document an environment-specific analysis and risk management. Track any proposed detail as a future requirement until effective.
Safeguards Implement reasonable and appropriate administrative, physical, and technical measures. Use stronger controls as a risk or contract decision, not as proof that a proposal is law.
Documentation Maintain required policies, procedures, actions, assessments, and decisions. Keep proposal-readiness notes separately with source and review date.
Testing Test controls that the current risk analysis and contracts call for. Plan additional testing if a final rule or customer agreement requires it.
Incident response Maintain a response path that fits current safeguards and breach duties. Model proposed timelines only as exercises until legally effective.

The current rule gives flexibility of approach, but flexibility is not a reason to skip evidence. Document why a control is reasonable for the environment, what alternative was rejected, and what residual risk remains. A proposal can make a future gap visible without changing the current conclusion.

Roles, duties, and evidence

Assign an owner for each row. Legal or privacy owners track effective status and contracts. Security owners maintain the risk analysis, controls, tests, and incident process. Product and engineering owners map the actual data path, access roles, regions, logs, backups, and support tools. Procurement owners track BAAs and subcontractor terms. No provider label can replace that division of responsibility.

Keep a dated source record:

  • source publisher, title, URL, retrieval date, and version or publication date;
  • current rule text or agency guidance that supports the active requirement;
  • proposal text, status, and exact language that is being monitored;
  • internal decision, owner, target date, estimate, and approval;
  • test or implementation evidence linked to the control.

Use the risk-analysis guide, the breach-notification timeline, and the role-mapping guide to connect the rule register with real workflows.

When evaluating a booking system, keep the booking source of truth, minimum necessary fields, tenant authorization, regional controls, and outbound conversion gate separate. If Google Ads is considered, use generic conversion data only after tenant-specific legal approval. Do not send patient names, email addresses, phone numbers, hashed identifiers, service or treatment details, or clinical text. Keep the integration off while the policy and legal analysis are open.

Documentation and escalation boundary

The common failure is a blog post or sales deck that turns proposal language into a current compliance checklist. Replace it with a status ledger. Every item should have one status: current and required, current and risk-based, contractual, proposed, voluntary, or not applicable with documented reason.

Status Example evidence Escalate when
Current and required Rule citation, policy, implementation, test, approval The control owner cannot show evidence.
Current and risk-based Risk analysis, decision, compensating control, review date The residual risk has no approver.
Contractual BAA, customer addendum, service commitment, deadline Contract is stricter or broader than the current rule.
Proposed Proposal, agency status, impact note, monitoring owner Team presents it as already enforceable.
Voluntary Budget, test plan, business reason, target date Marketing wants to call it a certification.

Escalate any conflict between a proposed requirement and the current rule to counsel. Escalate any implementation gap involving tenant isolation, support access, backups, logging, or cross-border transfer to the security owner. If a proposed final date is uncertain, record the uncertainty instead of inventing one.

Reader decision checklist

  1. Confirm the current effective Security Rule and retrieval date.
  2. Inventory current safeguards, risk analysis, policies, tests, incidents, and documentation.
  3. Build a separate proposal monitor with status and exact source language.
  4. Mark each roadmap item as current, contractual, proposed, voluntary, or not applicable.
  5. Assign owner, target date, estimate, residual risk, and approval authority.
  6. Reopen the register after final publication, effective-date notice, contract change, or material incident.

Stop a public compliance or legal claim when the item is only proposed or when current evidence is missing. Use precise wording: “we are preparing for a possible change” is different from “the rule requires this today.”

Build a proposal monitor without rewriting current policy

Assign one owner to monitor HHS and eCFR status, but keep the monitor separate from the control register. Record proposal title, publication date, current status, affected control, possible implementation effort, and the next review date. If wording changes, preserve the old note and explain why the roadmap changed. Do not rely on a vendor blog as the primary status source.

When a proposal suggests a stronger practice, translate it into a reversible preparation task. For example, improve asset inventory, test restoration, document workforce access, or add a review trigger. Mark the task voluntary or risk-based. If the proposal is withdrawn or revised, the work can still stand as a risk treatment, but the legal label should not change retroactively.

Current controls that should not wait

Proposal uncertainty is not a reason to postpone current duties. A small business associate should already know where protected data flows, who can access it, how tenant boundaries work, how logs and backups are handled, how incidents are escalated, and how required documentation is retained. The current risk analysis should identify missing evidence and assign owners.

  • Review every production and support identity, including service roles.
  • Test wrong-tenant reads, writes, exports, and background jobs.
  • Redact request bodies and free text before logs or error tools.
  • Exercise backup restore and deletion in an approved region.
  • Keep outbound conversion data generic, gated, and disabled by default.

These steps are not presented as a complete legal checklist. They are engineering controls that should be mapped to current requirements, risk decisions, and contracts.

A simple status legend prevents accidental overstatement: “current rule,” “effective contract,” “risk-based control,” “proposed,” “planned,” and “open question.” Put the legend next to the roadmap. In review meetings, require every claim to carry a status, source, owner, and date. If the status cannot be stated, the claim is not ready for marketing, procurement, or production.

For advertising, the status gate is stricter. Only generic conversion data may be considered, and tenant-specific legal approval must name the exact destination and fields. Never send patient names, email addresses, phone numbers, hashed identifiers, service or treatment details, or clinical text. Keep the worker off until the approval reference exists. A future Security Rule proposal does not authorize the disclosure.

Keep a final-rule watch separate from the current policy review. When a proposal changes, update the monitoring note, not the current obligation, until its legal status and effective date are confirmed.

FAQ

What is the first verification step for proposed HIPAA Security Rule changes in 2026?

Confirm the current effective rule, then read the latest HHS status and proposal source separately. Record the retrieval date and keep proposal language out of the current-obligation column.

Which source or configuration detail could change this answer?

A final rule, effective date, agency delay, contract addendum, state law, material incident, or architecture change can alter the roadmap.

Can a team prepare for a proposal before it is final?

Yes, as a voluntary risk or contract decision. Label the work as preparation and do not present it as proof that the proposed requirement is enforceable.

What must be approved before a production claim or outbound action?

Approve the current legal status, control evidence, contract boundary, and exact data payload. For Google Ads, require tenant-specific legal approval and keep the generic event off by default.

References

Related articles