The short version: I would treat this HHS proposal as a readiness check, not as a final rule. It is still proposed, but the pressure is already here: healthcare breach costs reached $7.42 million in 2025, and OCR fines topped $15 million across 2024 and 2025 under the current rule.
If I were leading this work, I’d focus on four things right away:
- Check current rule status before changing policy
- Compare the proposal to current controls like encryption, MFA, asset lists, network maps, and vendor reviews
- Build proof that shows what is in place, what is missing, who owns it, and what is being fixed
- Set a comment position for each item: support, clarify, modify, or defer
The main point is simple: a risk analysis alone is not enough. I need to show what I found, what I fixed, what is still open, and how any gap could affect patient care.
A few areas stand out fast:
- Encryption: the proposal points to AES-256 at rest and TLS 1.2+ in transit
- MFA: many teams use it for remote access, but not for privileged or service accounts
- Asset inventory: cloud systems, IoT, and medical devices are often missing
- Vendors: a BAA helps, but it does not prove day-to-day security work
- Legacy devices: if a device cannot support modern controls, I need written compensating controls and a migration plan
If I want a comment letter that holds up, I need input from security, compliance, legal, clinical, procurement, and leadership. That way, the response matches how the program actually works, not just how it reads on paper.
| Focus area | What I’d do now |
|---|---|
| Rule status | Verify the NPRM is still not final |
| Risk analysis | Update it and tie open risk to patient safety |
| Control review | Check MFA, encryption, inventories, maps, testing, backups, and IR |
| Proof | Assign owners for each document and test record |
| Comment plan | Mark each item as support, clarify, modify, or defer |
| Remediation | Rank work by patient-care impact and audit exposure |
Bottom line: I would use the proposal to tighten the program now, while keeping in mind that the rule is not final yet.
HHS Maintains Strict HIPAA Audit and Enforcement Focus in 2026
sbb-itb-535baee
What HHS Proposed and Where Current Programs Fall Short
HIPAA Current Rule vs. HHS Proposed Requirements: Key Control Areas
The Proposed Requirements That Would Raise the Bar for Healthcare Cybersecurity
The proposal takes several HIPAA safeguards that many teams treat as flexible and turns them into specific, documented requirements.
At the center of it are a few clear expectations: encryption of ePHI at rest using AES-256 and in transit using TLS 1.2 or higher, multi-factor authentication (MFA), written asset inventories, and annual network maps. Risk analyses would also need to go deeper, with a clearer connection between unresolved cyber risk and patient safety. [2]
That shift matters. It’s not enough to say a control is in place. The proposal expects proof that the control actually works. For your gap assessment, these requirements should be the starting point.
Why Existing HIPAA Documentation May Not Hold Up
A lot of current HIPAA programs look fine on paper, but that paper trail may not stand up under the proposed rule. The weak points are often hiding in places teams assume are already covered.
Asset inventories are a common example. The proposal calls for written inventories and annual network maps, yet many programs still don’t fully cover cloud-based systems and medical devices. And there’s a practical problem here: some legacy medical devices may not support AES-256. In those cases, documented compensating controls, such as segmentation, would be needed. [2]
Vendor oversight is another trouble spot. A BAA shows contractual intent, but it does not prove day-to-day security performance. Business associates are a frequent source of reportable healthcare breaches, and many organizations still leave them out of formal risk analyses. [3]
MFA often has the same issue. Many organizations use it for remote access, but stop there. That can leave privileged and service accounts exposed.
The table below highlights the control areas most likely to affect patient care and audit defense.
| Control Area | Current model | Proposal |
|---|---|---|
| Encryption | Flexible / addressable | AES-256 at rest; TLS 1.2+ in transit |
| Asset Management | General awareness of major systems | Written inventories and annual network maps |
| Vendor Oversight | Signed BAA as primary control | Evidence of actual security posture and ongoing diligence |
| MFA | Typically limited to remote access | Broader coverage including privileged and service accounts |
| Risk Analysis | Annual, high-level documentation | Deeper analysis of networks, devices, and patient safety impact |
| Medical Devices | Often managed separately from IT | Integrated into facility-wide risk and clinical safety |
Next, test these requirements against current controls and evidence.
Run a Structured Gap Assessment Before You Take a Position
Once you've mapped the proposal to your current controls, the next step is a gap assessment. The goal is simple: build evidence you can defend and get your program in shape before the comment period closes.
Review the Control Areas Most Likely to Affect Patient Care and Audit-Ready Evidence
Start with your HIPAA risk analysis. Between 2024 and 2025, OCR issued more than $15 million in fines, and failure to conduct an adequate risk analysis was the deficiency cited most often in those investigations.[1] If your analysis is out of date, or it doesn't clearly tie unresolved risks to patient safety, handle that first.
Then pull the evidence behind the controls that matter most:
- asset inventories and network maps
- MFA coverage
- vulnerability and penetration testing
- backup isolation and recovery testing
- policies and incident response
- third-party due diligence, including BAAs and security questionnaires
Once you have that material, map each requirement to your current state and any remediation work tied to it.
For unpatchable legacy devices, document a migration plan and compensating controls for each asset. If a device isn't in inventory, you can't defend the requirement.
Build a Readiness Matrix That Ties Each Proposal to Evidence and Remediation
That evidence should feed into a readiness matrix. Think of it as a working document, not just a checklist. It should map each proposed requirement to your current state and show what's missing.
| Column | Purpose |
|---|---|
| Proposed Requirement | The specific control from the HHS NPRM (for example, MFA, vulnerability scanning, or network segmentation) |
| Current Control | The technical or administrative safeguard already in place |
| Evidence Owner | The person or team responsible for producing validation |
| Gap | The difference between the proposed mandatory standard and your current state |
| Patient-Care Impact | How failure in this control would affect clinical continuity or patient safety |
| Remediation Priority | High/Medium/Low based on risk analysis and cost of implementation |
| Rulemaking Position | Whether your organization will Support, Clarify, Modify, or Defer the proposal in comments |
Use Patient-Care Impact to rank gaps by clinical risk, not only by regulatory exposure. That's what makes the matrix useful in a care setting. Then use Rulemaking Position to turn the matrix into comment-period decisions, so compliance, legal, security, and clinical teams can work from the same set of facts when drafting a response that matches current operations.
Align Stakeholders and Build a Defensible Rulemaking Position
Your readiness matrix is only as strong as the people who check it. A comment letter has to stand on verified operational facts, not legal reading alone. Use the matrix to assign each gap to the team that can confirm it and sign off on the response. Then route each gap to the team that owns the control and the team that will defend the comment.
Compile a Regulatory Evidence Package and Responsibility Table
Treat your comment letter as two things at the same time: a legal document and an evidence package. Legal writes and shapes the language. But the proof has to come from the people who run the controls every day.
Privacy and compliance should confirm that your enterprise risk analysis is correct and that BAAs are in place for all entities handling PHI. Security and IT should confirm technical controls and test evidence. Clinical operations and engineering should weigh in on how new requirements would affect clinical workflows. Procurement and vendor management should verify the third-party inventory, risk tiers, and continued diligence for business associates. Finance and executive leadership should approve any position tied to cost, staffing, or resource tradeoffs.
A BAA by itself is not enough. Regulators will want proof that vendor risk was actually reviewed. Include vendor facts in the evidence package because third-party risk sits inside the covered entity's risk surface.
That ownership map turns the matrix into input for the comment letter, not just an internal tracker. Each group needs to verify the facts that shape whether the organization should support, clarify, modify, or defer a requirement.
| Stakeholder Group | Validation Responsibility | Sign-Off Authority |
|---|---|---|
| Security / IT | Technical controls and test evidence | Technical feasibility and implementation timelines |
| Privacy / Compliance | HIPAA Security Rule alignment and BAA status | Regulatory defensibility and audit readiness |
| Legal | Contractual obligations and liability frameworks | Final language of the comment letter |
| Procurement | Vendor and business associate inventories | Vendor-side impact and supply chain constraints |
| Clinical Ops | Impact on clinical workflows | Patient safety and clinical workflow tradeoffs |
| Finance / Execs | Resource constraints and budget availability | Cost-benefit tradeoffs and positioning |
Sort Your Position Into Support, Clarify, Modify, and Defer
Turn the evidence package into a comment position only after each control owner has signed off on the facts. In most cases, four categories do the job.
- Support requirements that are already in place or closely match current practice. MFA and written asset inventories are good examples when the operational burden is manageable and the expected baseline is clear.
- Clarify requirements where the wording is vague enough to create audit risk. One example is how "dependent systems and downstream networks" are defined when responsibility stretches beyond device vendors to hospital networks.
- Modify requirements that make sense in theory but are hard to carry out as written. That often happens when full replacement is not feasible and network segmentation serves as a documented compensating control.
- Defer requirements where immediate implementation would create continuity risks, such as patching life-sustaining systems that cannot be easily taken offline.
Each position statement should tie back to a specific fact from your evidence package, not a broad concern. If a Modify position does not include an inventory of affected assets and a description of compensating controls already in place, it will not carry much weight. Leadership sign-off for each category keeps cost, staffing, and patient-safety tradeoffs out in the open before the comment letter goes out.
Once the positions are signed off, use them to rank remediation work and document the changes you can make before the comment period ends.
Use the Proposal to Drive Program Updates Now
Take the signed-off matrix and turn it into two things: a remediation backlog and a monitoring plan. In plain English, don't let the matrix sit in a folder. Use it as a living backlog that drives work. Even after the comment period ends, the gap analysis should keep moving your program forward under current enforcement pressure.
Start with the enterprise HIPAA risk analysis. That stays at the top of the list.
After that, rank work by patient-safety impact and audit exposure - not by what's easiest to knock out first. Easy wins feel good, but they don't always deal with the biggest risk.
| Work Item | Why It Can't Wait |
|---|---|
| Refresh enterprise risk analysis | Most common OCR deficiency; required under current rule [1] |
| Establish a continuously updated asset inventory | Foundation for all other controls [1] |
| Close MFA and encryption gaps | Proposed shift to mandatory MFA; expected encryption standards are AES-256 at rest and TLS 1.2+ in transit [1][2] |
| Document migration plans and compensating controls for legacy devices | Required for assets that cannot be fully patched or segmented [1][2] |
| Lock in scan and testing dates | Proposed cadence: scans every 6 months, pen testing annually [1] |
| Document where evidence is stored and who owns it | Needed for audit defensibility under current and proposed rule [1] |
It's also smart to assign one owner to track HHS and OCR finalization. No final rule has been published yet [1]. That matters. When the final rule shows up, your team should be ready to reassess fast, not scramble to rebuild the whole effort from zero.
Conclusion and Readiness Checklist
The proposed rule is not final. But the gap work, stakeholder alignment, and evidence documentation used to build a comment position are the same kinds of things a defensible compliance program needs under the rules already in force. So use that momentum to close gaps now.
Use this checklist to mark what's done and what's still open:
- [ ] Current rulemaking status verified and monitoring owner assigned
- [ ] Proposed requirements mapped to existing controls
- [ ] Enterprise HIPAA risk analysis refreshed
- [ ] Technology-asset inventory validated, including IoT and medical devices
- [ ] Legacy-device migration plans and compensating controls documented where needed
- [ ] Control and policy gaps documented with evidence owners assigned
- [ ] Clinical and patient-safety impacts assessed
- [ ] Legal, compliance, security, and executive positions aligned
- [ ] Remediation priorities approved with target dates for high-risk items
- [ ] Scan and penetration testing calendar confirmed
FAQs
What changes should we prioritize first?
Start with an enterprise-wide, documented risk analysis. Update it whenever there’s a major change, not months later when the trail has gone cold.
Then build a live inventory and data-flow map for every system, device, and vendor that touches ePHI. If ePHI moves through it, stores in it, or can be seen through it, it belongs on the map.
Next, create a risk register that leaders can actually use. Assign an owner to each item, set due dates, rank severity, and spell out the remediation path so executive governance has a clear view of what needs attention.
From there, tighten MFA, encryption at rest, encryption in transit, and testable restoration and incident resilience. The key word here is testable. Controls on paper don’t mean much if they fail when you need them.
Finally, check vendor exposure by confirming PHI access and collecting BAA evidence. That step often sounds simple, but it’s where gaps tend to show up fast.
How do we handle legacy devices that cannot meet the proposed controls?
Document the manufacturer limits that block patching or modern sign-in methods, especially when certified firmware can’t be changed without affecting FDA clearance. Then build a documented migration plan.
For devices still in use, put compensating controls in place and record them clearly. A common example is network segmentation. You should also get formal, leadership-signed risk acceptance. That gives regulators a clear paper trail showing you addressed the risk on purpose rather than letting it slide.
What should a strong comment letter include?
A strong comment letter should give practical, evidence-based feedback about how the proposed rules affect your organization’s ability to maintain security and patient care.
Be clear about the operational and financial burden. Back that up with documented data, such as risk analysis findings, asset inventory gaps, or technical issues tied to medical devices and third-party dependencies. It also helps to offer constructive alternatives or phased timelines based on your current security posture.
