Is the HIPAA Security Rule changing, and when?
HHS proposed a major revision to the Security Rule on January 6, 2025 (90 FR 898, RIN 0945-AA22), but as of October 2026 no final rule has been published. The latest Unified Agenda entry places final action in July 2027, and that date is an agency estimate, not a deadline you can plan a compliance program around. For budget owners and compliance leads, the practical question is not whether the revision will arrive, but how far your current safeguards, systems and contracts sit from what the proposal describes. The current Security Rule still applies today, and it is the standard OCR will test in any investigation before a final rule exists. The proposal is written to change obligations in ways that matter for planning. It would remove the distinction between required and addressable implementation specifications and make most of them mandatory, with limited exceptions. It would require encryption of ePHI at rest and in transit, multi-factor authentication on technology assets in relevant systems, a written technology asset inventory and network map reviewed at least every 12 months, and restoration of critical systems within 72 hours. Business associates would owe annual written verification of their technical safeguards. Start by reading the proposal's preamble and regulatory text in the Federal Register and comparing each item against your current risk analysis, asset records and vendor agreements. Where an addressable decision was documented as "alternative measure" or "not reasonable," flag it for review now. HHS estimated first-year costs of about $9 billion and about $6 billion a year in years two through five (90 FR 898). Those figures are the agency's own estimate for the whole regulated population, so they will not translate directly into your budget. Ask your implementation partner or internal team to separate one-time work, such as asset inventory and network mapping, from recurring work, such as annual audits, six-month vulnerability scans and annual penetration tests. Track the Federal Register and the Unified Agenda entry for changes to the date, and confirm any compliance date with counsel once a final rule is published, since the proposal set a standard compliance date of 180 days after the final rule's effective date.
What the proposal would change for your controls
The January 2025 proposal would tighten several Security Rule controls at once, from how implementation specifications are chosen to how fast critical systems come back after a loss. Each change below is a proposal in 90 FR 898 and could change before any final rule is published, so treat the list as a planning input rather than a current obligation.
Removing the addressable option
Today, an addressable implementation specification can be declined if the entity documents why it is unreasonable and adopts an equivalent measure. The proposal would make nearly all specifications required, with narrow exceptions. Check which of your current addressable decisions rely on documented alternatives, because those decisions would need to be rebuilt as required controls.
Mandatory encryption of ePHI
The proposal would require encryption of all electronic protected health information at rest and in transit, subject to limited exceptions. Many organizations already encrypt most ePHI, so the work is usually in the exceptions: legacy systems, backups, endpoints, and interfaces that send data unencrypted. Inventory where ePHI is stored and moved before estimating the gap.
MFA on relevant technology assets
The proposal would require multi-factor authentication on all technology assets in relevant electronic information systems. Administrative consoles, remote access paths, and service accounts often fall outside existing MFA coverage. Confirm which identity provider, VPN, and admin tools are in scope, and document exceptions the proposal would still allow.
Written asset inventory and network map
The proposal would require a written technology asset inventory and network map, reviewed at least every 12 months. Without an accurate map, the risk analysis and the encryption and MFA scope cannot be verified. Ask whether your asset inventory covers cloud accounts, endpoints, and vendor-hosted systems that touch ePHI.
Restoring critical systems within 72 hours
The proposal would require written procedures to restore critical systems and data within 72 hours of a loss. Restoration time depends on tested backups, documented recovery sequences, and vendor support for hosted systems. Test restores on a schedule and record the results, since a plan that has never been exercised is hard to defend against this requirement.
Scanning and penetration testing cadence
The proposal would require vulnerability scans at least every six months and penetration testing at least every 12 months. These are scheduled activities with their own evidence trail, separate from the risk analysis. Confirm the testing scope with your assessor, and ask whether findings and remediation dates will be retained in a form OCR can review.
Where the rule stands and the projected timeline
The proposed rule has not been finalized. HHS published *HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information* in the Federal Register on January 6, 2025 at 90 FR 898, and comments closed on March 7, 2025. As of October 2026, no final rule has appeared in the Federal Register, and the eCFR source notes for Subpart C still cite no amendment later than 2013. That means the current requirements, including the required and addressable distinction, remain the law you must meet today. Treat the proposal as a signal of direction, not as a deadline you can defer to. The latest Unified Agenda entry for RIN 0945-AA22 classifies the rule as economically significant and places it under Long-Term Actions, with final action projected for July 2027. Agenda dates are estimates, not commitments, and they have moved before. Check the reginfo.gov entry for RIN 0945-AA22 at each agenda publication, and set a Federal Register alert for the rule number so you learn of a final rule the day it is published. Ask your compliance counsel to confirm the status before you make any budget or contract commitment that assumes a particular date. The compliance clock matters more than the agenda date. HHS proposed a standard compliance date of 180 days after a final rule's effective date (90 FR 898; 45 CFR 160.104(c)(1)). The effective date itself would follow publication, so the period between a final rule and your deadline could be shorter than a full implementation cycle for controls like encryption, multi-factor authentication and asset inventories. Build a readiness plan now: inventory ePHI systems, confirm which safeguards you already run, and ask your business associates and hosting providers when they expect to support the proposed requirements, so that a final rule starts a sprint rather than a first assessment.
What HHS estimated the proposal would cost
This table breaks down HHS's published cost estimate for the proposed Security Rule revision by who bears each cost and whether it is one-time or recurring. HHS's figures are sector-wide averages, so your own cost depends on how far your current controls already sit below the proposed requirements. Use the table to scope internal and outside work, then request written quotes tied to your specific gaps.
| Cost component | Who bears it | One-time or recurring |
|---|---|---|
| Headline first-year estimate (about $9 billion, 90 FR 898) | Covered entities and business associates, sector-wide | One-time in year one, as HHS modeled it |
| Ongoing estimate for years two through five (about $6 billion a year, 90 FR 898) | Covered entities and business associates, sector-wide | Recurring each year after the first |
| Encryption of ePHI at rest and in transit, and MFA on relevant systems | Covered entities and business associates, including vendors with legacy systems | Mostly one-time rollout, with recurring key, certificate and MFA administration |
| Written technology asset inventory and network map, reviewed every 12 months | Covered entities and business associates | Initial build is one-time; annual review recurs |
| Annual compliance audit and penetration testing at least every 12 months | Organization pays the auditor or tester; testers and auditors are independent of the implementation partner | Recurring every year |
| Vulnerability scans at least every six months and 72-hour restoration procedures | Organization, often with managed service providers and backup tooling vendors | Tooling and scans recur; restoration testing recurs |
| Business associate annual written verification and 24-hour contingency notice | Business associates, with cost passed to covered entities through contracts | Annual recurring; contract updates are one-time |
| Implementation partner work to design, build and document controls | Organization pays the partner under a written scope | Mostly one-time; ongoing support is a retainer |
What makes the change larger or smaller for your organization
The January 2025 proposal would turn several flexible choices into fixed requirements and add dated testing and recovery tests. How much work that means depends on where your organization already stands on the same six points, so start with an honest read of each one before estimating effort.
Current encryption and MFA coverage
The proposal would require encryption of all ePHI at rest and in transit, with limited exceptions, and multi-factor authentication on all technology assets in relevant electronic information systems. Check every system that stores or transmits ePHI, including backups, laptops, removable media, and legacy applications that use shared accounts. Gaps in older systems usually drive the largest share of the work, so list each exception and the reason it exists today.
Completeness of the asset inventory
A written technology asset inventory and network map, reviewed at least once every 12 months, would be required. Organizations that already track servers and applications in a configuration database but not medical devices, SaaS tenants, or shadow tools will need to close those gaps first. Ask who owns each asset, whether it touches ePHI, and when someone last verified the record against the network.
Age and count of ePHI systems
The more systems that hold ePHI, and the older they are, the more configuration work each new requirement creates. A single hosted electronic health record is different from fifteen departmental databases on unpatched servers. Count the systems, note which vendors no longer ship security updates, and identify which ones can be retired, consolidated, or moved to a supported platform.
Reliance on business associates
Business associates would have to give covered entities annual written verification of their technical safeguards and notify them within 24 hours of activating a contingency plan. Each vendor that hosts, processes, or supports ePHI adds a verification and notification duty to your program. Inventory every business associate, confirm whether its current agreement supports these requests, and rank vendors by the volume of ePHI they handle.
Backup and restore times against 72 hours
The proposal would require procedures to restore critical systems and data within 72 hours of a loss. Restore time depends on how backups are stored, how large the data sets are, and whether restores have ever been tested end to end. Run a timed restore of your most important system, record the result, and compare it with the 72-hour target. A backup that has never been restored is not evidence that the target can be met.
Existing penetration testing and scanning
The proposal would require vulnerability scans at least every six months and penetration testing at least every 12 months. Organizations with recent, documented tests against ePHI systems will mostly need to tighten the schedule and the scope. Organizations without any testing will need to scope, procure, and remediate from the start. Pull your last two test reports and check whether they covered the systems that hold ePHI and whether findings were tracked to closure.
How to prepare before a final rule
This sequence lets an organization measure its current exposure against the Security Rule as written today and against the proposed requirements, so that gaps are documented and owned before any final rule sets a compliance date. Each step closes with a named artifact that can be shown to an assessor or customer.
Confirm current requirements under the existing rule
Start with the Security Rule as it stands in 45 CFR Part 164 Subpart C, because that is the standard OCR enforces today. The compliance officer or security official maps each standard and implementation specification to an owner, and marks which specifications are required and which are addressable. The output is a baseline requirements register with a named owner for every line, signed off by leadership. It is done when every standard in the existing rule has an owner and a current status.
Build or refresh the risk analysis
Run or update the risk analysis that the existing rule already requires, covering where electronic protected health information is created, received, maintained and transmitted. Security, privacy and operations staff review threats and vulnerabilities, rate likelihood and impact, and record the current measures. The output is a dated risk analysis report and a risk management plan that lists the treatment decision for each finding. It is done when leadership has approved the plan and the findings feed the remaining steps.
Build the technology asset inventory and network map
Because the proposal would require a written asset inventory and network map reviewed at least once every 12 months, build that record now. Engineering teams list every system, device, application and cloud service that touches ePHI, then draw how data and network paths connect them. The output is a versioned inventory and network diagram with an owner for each asset and a review date. It is done when someone outside the team that built it can trace an ePHI record from intake to storage and deletion.
Measure encryption and MFA gaps
Using the inventory, test each system for encryption of ePHI at rest and in transit, and for multi-factor authentication on the technology assets that access ePHI. Record which systems pass, which fail, and whether any documented exception applies. The output is a gap register with configuration evidence, such as screenshots, configuration exports or vendor settings, and a remediation plan for each gap. It is done when every in-scope system has an evidenced status rather than an assumed one.
Test restoration against a 72-hour target
The proposal would require procedures to restore critical systems and data within 72 hours of a loss. Run a restore test for each critical system from the most recent backup, timing the process and recording who performed each step. Where a restore exceeds 72 hours or cannot be completed from the documented backup, record the gap and the fix. The output is a restoration test report with timings, failures and corrective actions. It is done when the team has a repeatable, timed result for each critical system.
Schedule vulnerability scanning and penetration testing
The proposal would require vulnerability scans at least every six months and penetration testing at least every 12 months. Set up a calendar for both, assign an internal owner, and select an independent tester if external testing is needed. Confirm scope against the asset inventory so that every ePHI system is covered. The output is an approved testing schedule, scan and test scope documents, and the first results with tracked remediation. It is done when scans and tests are on a calendar with owners and the first findings are assigned.
Update business associate agreements
The proposal would require business associates to give covered entities annual written verification of their technical safeguards and to notify them within 24 hours of activating a contingency plan. Review each business associate agreement and subcontractor flow-down against the current rule and the proposed terms, then identify gaps with legal counsel. Send amendment requests or updated terms to each vendor and track responses. The output is a register of agreements with their status, the verification requests sent and the signed amendments received. It is done when every ePHI vendor has a current agreement and an owner tracking its status.
Who owns what during the transition
Your organization remains the covered entity or business associate, so it owns every safeguard, every risk decision and every policy. Under the current rule, the Security Rule expects a designated security official and written policies, and the 2025 proposal would keep that accountability while adding specific technical requirements. No vendor can accept those obligations on your behalf.
- Risk decisions: Your team decides which risks to accept, mitigate or transfer, and records the reasoning in the risk analysis and risk management plan.
- Security official role: A named individual must hold the security official responsibility. This can be an internal employee or a contracted person, but the accountability stays with your organization.
- Policies and workforce: Your team writes, approves and enforces policies, training and sanctions.
- Asset inventory and network map: Under the proposal, your team would own a written technology asset inventory and network map reviewed at least every 12 months.
- Business associate oversight: Your team keeps the vendor contracts current and checks vendor safeguards.
Confirm internally who holds each of these roles before any partner scope is written.
An implementation partner such as DeployOpen prepares the systems, configuration, inventory, test environments and evidence that your team and an assessor will later review. Work is typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The partner builds and documents controls, but it does not decide your risks and does not issue audit reports, attestations or certifications. No partner can guarantee a regulatory outcome.
- Systems and configuration: Hardening, encryption setup, multi-factor authentication integration and logging on self-hosted platforms in your own environment.
- Inventory and mapping: Drafting the asset inventory and network map from discovery data, for your team to validate.
- Test environments: Building staging environments for scanning and penetration testing that your testers can use.
- Evidence preparation: Collecting configuration exports, logs and change records in a form an assessor can review.
- Written boundaries: Each deliverable, exclusion and handover point stated in the scope document.
Ask any partner to name, in writing, which outputs it will hand over and which decisions remain with your team.
An independent auditor or assessor tests your controls against the rule and issues any report. Because the assessor must be independent of the work it reviews, it should not be the same firm that built the controls. HHS does not endorse or recognize private certifications, so the value of a third-party result depends on the scope and method the assessor actually used. The OCR audit program is a separate matter: OCR, not a private firm, decides enforcement outcomes.
- Testing: The assessor samples controls, reviews evidence and tests whether safeguards operate as documented.
- Reporting: Only the assessor issues the findings or report, and it states the scope and limits of its work.
- Independence: The assessor should not design or operate the controls it tests.
- Scope agreement: Confirm in advance which standards, systems and periods the assessment covers.
- Limits: A third-party report does not prevent OCR from later finding a violation.
Before engaging an assessor, confirm its methodology, its independence policy and exactly what its report will and will not state.
What usually delays or inflates the work
Teams preparing for the proposed Security Rule changes tend to lose time in the same few places. Each pitfall below comes from treating a proposal as settled, skipping the foundation the controls depend on, or buying before measuring. The avoidance steps are ordered so that the cheapest checks come first.
Planning to the proposal as if it were law
The January 2025 proposal at 90 FR 898 is not in force, and no final rule has been published as of October 2026. Building a program around the proposed text can lock in spending on requirements that change during rulemaking, and it can also leave gaps in the current rule, which still makes some specifications addressable. Check the Federal Register and the Unified Agenda entry before each budget decision, and separate work that satisfies today's rule from work that only anticipates the proposal. Ask vendors and advisers which requirement each line item maps to.
Building controls without an asset inventory
The proposal would require a written technology asset inventory and network map, reviewed at least once every 12 months. Controls such as encryption, multi-factor authentication and vulnerability scanning are hard to scope and evidence when the team cannot list which systems hold ePHI. Teams that start with tools often discover unmanaged servers, shadow SaaS accounts and backups late in the project. Begin by listing every system, device and service that creates, receives, stores or transmits ePHI, then record the owner and data flows for each. Treat this inventory as the input to the risk analysis.
Buying tools before measuring coverage
Security tooling bought before the gaps are known often duplicates capabilities already in place while leaving the ePHI systems uncovered. Licensing, integration and staff training then recur every year without showing improvement against the risk analysis. Before any purchase, measure current coverage for each safeguard against the inventory: which systems have logging, which accounts use strong authentication, and which backups have been restored in a test. Ask any open-source or commercial vendor to show how its output maps to a specific standard and to the evidence an assessor would request.
Leaving business associate contracts untouched
Business associates are directly subject to the Security Rule, and the proposal would add annual written verification of technical safeguards and notice within 24 hours of activating a contingency plan. Existing business associate agreements that predate those obligations may not give covered entities the information or timing they need. Subcontractors that hold ePHI also sit in the chain. Review each agreement for security responsibilities, incident notice periods and subcontractor flow-down, and identify which vendors would need amendments if the proposal is finalized. Agree on the evidence each vendor will provide, so the contract and the controls stay aligned.
Questions buyers ask about the proposed changes
Does the current HIPAA Security Rule still apply today?
Yes. The proposal is not law, and the Security Rule in 45 CFR Part 164 Subpart C remains the binding standard. The eCFR source notes for the current sections cite no amendment later than 2013, so every covered entity and business associate must still meet the standards and implementation specifications as written today. Required specifications must be implemented, and addressable specifications must be assessed, decided and documented. Treat the proposal as a signal of where OCR expectations are heading, not as a reason to pause current compliance work. Confirm the current text in the eCFR before you set scope, since any future final rule would change it.
Should we build to the proposed rule now or wait for the final text?
Building the controls the proposal emphasizes is usually low regret, but you should not treat the proposal as final text. The proposal would make all implementation specifications required, mandate encryption of ePHI at rest and in transit with limited exceptions, require multi-factor authentication on relevant systems, and add a technology asset inventory, network map, vulnerability scanning every six months and penetration testing every 12 months (90 FR 898). Those items overlap with sound security practice and with the current risk analysis duty. Where you build ahead, record the reason, keep the design flexible, and expect the final rule to change details. Ask counsel which current obligations you must meet now regardless of the outcome.
What does the proposal need from our internal team?
The proposal would shift work from documentation toward maintained, verifiable operations. Your internal team would need to own a current asset inventory and network map reviewed at least once every 12 months, a documented restoration procedure able to bring critical systems and data back within 72 hours, and evidence that scanning and penetration testing happen on schedule. Business associates would owe covered entities annual written verification of technical safeguards. Security, IT operations, and privacy staff must agree on owners for each control. Name a security official, assign accountable system owners, and budget time for quarterly evidence collection so the work does not depend on one engineer.
Can we prepare for the proposed changes in-house?
Many organizations can, provided they have people who understand both the Security Rule and the systems that hold ePHI. An internal team can run the risk analysis, maintain policies and build evidence. Specialist help is often useful for penetration testing by an independent tester, for hardening self-hosted platforms, and for an independent assessment before you rely on the result. Be clear about roles: your organization owns its controls, an implementation partner can prepare systems and evidence, and only an independent auditor or assessor issues reports. DeployOpen plans, implements and hardens self-hosted open-source platforms in your own environment and prepares evidence, but it does not issue audit reports or certifications.
What drives the cost of preparing for the proposed rule?
The main published figure is HHS's own estimate: about $9 billion in first-year costs and about $6 billion a year in years two through five (90 FR 898). That figure covers the whole regulated sector, so it does not tell your organization what it will spend. Your cost depends on the size and number of systems holding ePHI, how much of the asset inventory and encryption work already exists, how many business associates must provide verification, and how often independent testing is needed. One-time costs include inventory, network mapping, and migrating systems to encryption and MFA. Recurring costs include scanning, annual penetration tests, audits and staff time. Ask any vendor or partner for a written scope that separates these items.
How do we track the status of the HIPAA Security Rule proposal?
Watch the Federal Register and the Unified Agenda entry for RIN 0945-AA22. The proposal was published on January 6, 2025 at 90 FR 898, with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda places the rule under Long-Term Actions with final action projected for July 2027. Agenda dates are estimates, not deadlines. The proposal also sets a standard compliance date of 180 days after a final rule's effective date. Assign one person to check these sources quarterly, record each change in your compliance calendar, and brief leadership when the status moves.
Which proposed changes should we plan for first?
Start with the changes that depend on accurate knowledge of your environment. The asset inventory and network map come first, because encryption, MFA, scanning and restoration all depend on knowing which systems hold ePHI. Next, confirm encryption coverage at rest and in transit and identify systems that lack MFA. Then test your restoration procedure against the 72-hour target and schedule vulnerability scans and penetration tests. Finally, plan business associate verification and contract updates. Confirm each item against the final rule when it is published.
Primary sources to read yourself
Before you plan around any date or requirement in the proposed Security Rule changes, read the source documents yourself. The starting point is the proposed rule, *HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information*, published at 90 FR 898 on January 6, 2025 under RIN 0945-AA22. Read the preamble as well as the proposed regulatory text. The preamble explains HHS's reasoning, its cost estimates and the specific questions it asked commenters, and those explanations are often what an assessor or OCR investigator will later rely on. You can find it through the Federal Register entry for the proposed rule.
Next, check the status of the rulemaking in the Unified Agenda entry for RIN 0945-AA22 on reginfo.gov. The agenda is where HHS publishes its projected timeline, and it shows whether the rule has moved between stages. Confirm the stage, the listed action and the projected date, then treat the date as an estimate rather than a commitment. Also confirm in the Federal Register that no final rule has been published since your last review. A compliance plan that assumes a date should name the source and the date you checked it.
Finally, read the current regulatory text in the eCFR for 45 CFR Part 164 Subpart C, the Security Rule as it stands today. Compare it against the proposal so you can see exactly which provisions would change, such as the required and addressable distinction in the implementation specifications, and which would stay the same. Note the date on which you pulled the text, because eCFR updates reflect current law. Keep a dated record of these three checks in your compliance file. If your counsel or an outside consultant summarizes the proposal for you, use that summary as a guide to the source text, not a substitute for it.
How DeployOpen prepares your environment
This sequence turns the proposed Security Rule requirements into scoped work, configured systems and evidence that your organization can review, adopt or hand to an independent assessor. It prepares the environment, but the controls, decisions and any attestation remain with your organization and its auditor.
Agree the scope in writing
DeployOpen and your team define which systems, data stores, facilities and business associates fall inside the work, which of the proposed requirements the engagement addresses, and which remain your responsibility. The written scope lists deliverables and timelines, and a quote follows from that document. Your organization signs off on the scope before any work begins, so the boundary of what was prepared is clear to later reviewers.
Build the technology asset inventory
Working inside your cloud accounts, data centers or air-gapped networks, DeployOpen helps compile a written inventory of technology assets and a network map that show where ePHI is created, stored, processed and transmitted. The proposal would require this inventory and map to be reviewed at least once every 12 months, so the process for keeping them current is documented as part of the output. Your team confirms each entry against its own records before the inventory is accepted.
Implement and harden self-hosted platforms
DeployOpen plans, deploys, customizes and hardens the open-source platforms in scope within your infrastructure, including access settings, logging and configuration baselines. Your organization keeps administrative ownership and approves the configuration decisions that affect its risk. The output is a configuration record for each platform that names the settings, versions and owners, which your team can review and retain.
Configure encryption and multi-factor authentication
The proposal would require encryption of all ePHI at rest and in transit, with limited exceptions, and multi-factor authentication on all technology assets in relevant electronic information systems. DeployOpen configures encryption and MFA on the in-scope platforms and documents where each control applies and where an exception would need justification. Your team confirms the exceptions and the key management arrangements, and the resulting settings are recorded as evidence.
Test backup and restoration
The proposal would require procedures to restore critical systems and data within 72 hours of a loss. DeployOpen designs backup routines for the in-scope platforms and runs restore tests that record what was restored, how long it took and what failed. Your organization decides whether the measured results meet its own recovery objectives. The closing check is a dated restore test record that your team reviews and files.
Run vulnerability scans and penetration tests
The proposal would require vulnerability scans at least every six months and penetration testing at least every 12 months. As a separate security testing service, DeployOpen can run scans and penetration tests against applications, APIs, cloud and infrastructure in scope, then deliver findings with remediation priorities. Your team owns the remediation decisions and tracks closure. The output is a test report and a remediation log, which are testing evidence, not a compliance attestation.
Hand over documented evidence
DeployOpen compiles the configuration records, inventory, restore test results, testing reports and procedures into an evidence package indexed against the proposed requirements in scope. Your organization reviews the package, adopts it into its own compliance program and decides what to share with business associates or assessors. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and assessors are the only parties that can issue them, and the package is designed to support their testing.
