At a Glance
The HIPAA Security Rule update that HHS proposed in January 2025 is not final. Its headline change would make many safeguards that are “addressable” today, such as encryption, required, and add mandates such as multi-factor authentication. Until a final rule is published, covered entities and business associates owe compliance with the existing Security Rule.
- Status: proposed rule only; the public comment period closed in March 2025.
- Timing: the federal regulatory agenda reportedly targets July 2027, a moving target, not a deadline.
- Today: the current rule still requires risk analysis, audit controls and activity review.
- Effort: an asset inventory and reviewable logs serve both the current and the proposed rule.
Search for the HIPAA Security Rule update and you will find articles telling you MFA, network segmentation and annual audits are now mandatory. They are not. According to compliance summaries citing the Federal Register docket, the notice of proposed rulemaking was published on 6 January 2025 and its comment period closed on 7 March 2025. At the time of writing, no final rule has been issued.
The timeline has also slipped. HIPAA Journal reports that the government’s Unified Agenda now lists July 2027 for final action, later than the earlier target of spring 2026. Treat that date as a planning signal. Regulatory agenda dates move, and a final rule can differ from the proposal.
That leaves health systems, payers, digital health companies and their vendors with two jobs. Meet the rule that is enforced now, and avoid building a compliance program around requirements that may change before they ever bind anyone.
What Would the Proposed Rule Change?
The proposal is a substantial rewrite. As summarised by HIPAA Journal, the main changes would include the items below. None of them is a legal requirement today.
| Proposed change | Status today under the current rule | Data work it implies |
|---|---|---|
| Remove the “addressable” category so nearly all specifications become required | Specifications are split into required and addressable; addressable ones need a documented decision | Evidence for every control, not just the required ones |
| Encryption of ePHI at rest and in transit, with limited exceptions | Encryption is an addressable specification | A map of where ePHI sits and moves, with encryption state per store |
| Multi-factor authentication for ePHI access, with limited exceptions | Person or entity authentication is required, with no specific method mandated | Sign-in logs that show method per access |
| Technology asset inventory and network map, reviewed at least every 12 months | No explicit inventory standard; risk analysis must still be accurate and thorough | A maintained inventory table tied to lineage |
| Network segmentation based on risk analysis | Not specifically mandated | Access paths documented per system |
| Compliance audits every 12 months, vulnerability scans every 6 months, penetration tests every 12 months | Periodic evaluation is required; intervals are not fixed | Scan and test results retained and queryable |
| Written procedures to restore data within 72 hours | Contingency planning is required; no fixed restore time | Tested restore records |
| Annual verification of business associates’ security measures | Business associate contracts require satisfactory assurances | A vendor register with verification dates |
The current-rule column comes from the regulation text. Under 45 CFR 164.312, encryption and decryption of stored data and encryption in transmission are both addressable implementation specifications. Addressable does not mean optional: an entity must assess whether the safeguard is reasonable and appropriate and document what it does instead if it does not implement it.
What Do Covered Entities Owe Under the Current Rule Today?
Compliance summaries report that the Office for Civil Rights continues to enforce the existing Security Rule and does not cite the proposal in its resolution agreements. The existing rule already asks for most of the evidence the proposal would formalise. Five provisions matter most to a data team.
- Risk analysis (required). 45 CFR 164.308 requires “an accurate and thorough assessment of the potential risks and vulnerabilities” to ePHI. You cannot do that without knowing where ePHI lives.
- Information system activity review (required). The same section requires procedures “to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”
- Audit controls. 164.312(b) requires mechanisms that “record and examine activity in information systems that contain or use electronic protected health information.”
- Access control. Unique user identification and an emergency access procedure are required specifications; automatic logoff and encryption are addressable.
- Documentation retention. 45 CFR 164.316 requires documentation to be retained “for 6 years from the date of its creation or the date when it last was in effect, whichever is later.”
Read together, the current rule already expects you to record activity, review it regularly and keep the policies and procedures behind it. The proposal mostly sets intervals and removes the room to document an alternative.
Where Does HIPAA Security Work Break Down in Practice?
Nobody can say where ePHI actually lives
The EHR is the obvious store. The problems are the copies: extracts for analytics, files on shared drives, a claims feed into a reporting database, a data science sandbox, the CSV a vendor sent back. A risk analysis that lists only the systems of record understates the risk, and an asset inventory built from interviews goes stale the week after it is written.
Logs exist, but nobody reviews them
Activity review is a required specification, yet logs typically sit in each application, in different formats, with different retention. Reviewing them means logging into five consoles. In practice it happens after an incident, which is the opposite of “regularly.”
Access grew faster than the review
Analysts, contractors and service accounts accumulate access to tables that hold ePHI. Without a single place where grants are defined, the quarterly access review becomes a spreadsheet exercise that nobody trusts.
Evidence is assembled by hand for each audit
Screenshots, exported reports and email threads get stitched together under deadline. The same work repeats for the next audit, and the proposal’s annual compliance audit would make that cadence permanent.
How Does a Governed Lakehouse Produce the Evidence?
A lakehouse will not make you compliant, and no platform can. What it can do is produce the records the current rule already asks for, in one place, and make the proposed rule’s inventory and audit cadence cheaper if it is finalised.
Inventory from lineage. In a lakehouse, tag tables that hold ePHI with a governed tag in Unity Catalog and let lineage show every downstream table, view and dashboard built from them. The inventory becomes a query that updates itself, rather than a document.
Centralised activity logs. Land EHR access logs, identity provider sign-ins and database audit events in bronze, normalise them in silver and publish a gold activity table that a reviewer reads on a schedule. On Databricks, the audit log system table records platform activity; it is in Public Preview, so copy what you need into your own retained table rather than relying on default retention.
Access defined once. Column masks and row filters driven by governed tags restrict ePHI fields by role, and the grant history is itself auditable. Access reviews read from the policy, not from a spreadsheet.
Retention set to the rule. Keep policy documentation and the review records for the six-year period the current rule sets, and confirm log retention with counsel. Our guide to audit log retention covers the retention design, and the same review pattern we describe for PCI DSS log review applies to ePHI activity.
This is general information, not legal advice; counsel or a qualified HIPAA assessor makes the compliance call for your organisation.
What Should Your Team Do Now, Based on Where You Are?
The right move depends on how much of the current rule you can already evidence. Find the profile closest to yours.
- If your risk analysis is more than a year old and lists only core systems, start with the ePHI inventory. Tag the stores you know, trace lineage to the copies you do not, and update the risk analysis from that list. It is required today and it is the first thing the proposal would formalise.
- If you have logs in every application but no regular review, centralise three sources first: EHR access, identity sign-ins and your data platform’s audit events. Publish one gold activity table and put a dated review on the calendar. That closes a current required specification.
- If you are a business associate or digital health vendor, expect customers to ask for evidence sooner than any final rule. Build the access policy, activity log and retention record once in your lakehouse, and answer each security questionnaire from the same tables.
- If your controls are mature and documented, run a gap check against the proposal’s intervals, such as six-monthly scans and twelve-monthly tests, and price the difference. Do not rebuild anything until a final rule confirms what changes.
Healthcare data teams carrying this alongside analytics and AI work can see how we approach it on our healthcare industry page.
Frequently Asked Questions (FAQs)
Is the HIPAA Security Rule update final?
No. The proposed rule was published in January 2025 and its comment period closed in March 2025, but at the time of writing no final rule has been issued. The existing Security Rule remains the one that applies.
Is multi-factor authentication required under HIPAA now?
Not as a specific mandate. The current rule requires procedures to verify that a person seeking access to ePHI is who they claim to be, without prescribing a method. The proposal would require MFA with limited exceptions, but it is not final.
When will the new HIPAA Security Rule take effect?
There is no effective date because there is no final rule. HIPAA Journal reports the government’s agenda targets July 2027 for final action, and any final rule would carry its own compliance period. Treat both as subject to change.
Should we start preparing for the proposed requirements anyway?
Prepare where the work also satisfies the current rule: an accurate ePHI inventory, centralised activity logs with regular review and documented access policies. Hold off on spending that only makes sense if specific proposed intervals survive into a final rule.