HIPAA's Proposed Pentest Mandate: What Healthcare Organizations Need to Know

#HIPAA finally grew teeth

If you work at a covered entity or a business associate, you already know the HIPAA Security Rule had a compliance reputation problem. The framework required "appropriate" safeguards. It required "reasonable" protections. Covered entities interpreted that loosely for a decade and OCR wasn't audit-staffed to catch them. A lot of organizations treated HIPAA as a paper exercise.

That ended in January 2025.

HHS dropped a Notice of Proposed Rulemaking rewriting the Security Rule. First substantial update since the 2013 Omnibus Rule. Biggest healthcare cybersecurity shift in over a decade. The language is specific where it used to be vague. Mandatory instead of advisory. And the controls it mandates are the exact ones we were already recommending to our healthcare clients anyway. Penetration testing. Vulnerability scans. Segmentation. Documented playbooks. The works.

The proposed rule adds, clarifies, or significantly strengthens requirements across the entire HIPAA Security Rule framework. Key changes most relevant for healthcare organizations:

• Annual mandatory penetration testing of all systems containing ePHI
• Bi-annual vulnerability scanning with remediation timelines
• Formal network segmentation requirements separating ePHI systems from general corporate networks
• Encryption strengthening with specified algorithms and key management
• Technology asset inventory with explicit documentation requirements
• Written documentation of security policies, procedures, and risk analyses. Far more rigorous than current practice
• Specific incident response requirements including testing and documented playbooks
• Enhanced workforce security requirements including detailed access reviews
• Expanded compliance obligations for business associates

The rule is in the comment-and-review phase as of April 2026. Industry comments are being reviewed. Final rule issuance is expected in late 2026 or early 2027, with a compliance grace period typically 18-24 months after final issuance.

For healthcare organizations, this means the preparation window is closing. Organizations that start now have time to build sustainable programs. Organizations that wait will scramble.

This post walks through the specific proposed requirements, what they mean operationally. And the realistic path for healthcare organizations to be ready.

#What's in the proposed rule

#Technology asset inventory (§164.308(a)(1)(ii)(A))

The proposed rule requires covered entities to maintain a documented inventory of:

• All information systems (servers, workstations, network devices, cloud services)
• All software running on those systems
• All users with access
• All third parties with access

Must be current (annual minimum review), documented in writing, and available for OCR inspection.

Reality check: few healthcare organizations have a comprehensive asset inventory today. Most have incomplete lists scattered across spreadsheets, IT ticketing systems, and network discovery tools. Building a single authoritative inventory is a real operational lift.

Practical approach: integrate asset discovery tools (Armis, Claroty for medical devices, Tanium, Nmap-based discovery for network) with an IT asset management (ITAM) system. The output is living documentation, not a one-time document.

#Risk analysis (§164.308(a)(1)(ii)(B))

The proposed rule significantly tightens existing risk analysis requirements:

• Comprehensive risk analysis (not specific incidents)
• Specific methodology requirements (NIST-aligned is acceptable)
• Documentation requirements (risk register, prioritization, treatment plans)
• Annual review and update
• Integration with the covered entity's broader risk management program

Reality check: existing HIPAA Security Rule already technically requires risk analysis. OCR cites inadequate risk analysis in nearly every enforcement action. The proposed rule makes the deficiencies explicit with specificity that's harder to ignore.

Practical approach: adopt a formal methodology (NIST SP 800-30 is the common reference), document the process, maintain a living risk register. And treat risk analysis as an ongoing program activity than annual checkbox.

#Risk management (§164.308(a)(1)(ii)(C))

Beyond identifying risks, the proposed rule requires:

• Documented treatment plans
• Prioritization rationale
• Remediation tracking
• Integration with change management

: risks must be managed, not noted.

#Sanction policy (§164.308(a)(1)(ii)(C))

Formal workforce sanctions for security violations. Must be documented, consistently applied, and integrated with HR.

#Information system activity review (§164.308(a)(1)(ii)(D))

Logs and monitoring data must be actively reviewed. Can't collect logs and file them. Specific review cadences proposed.

#Assigned security responsibility (§164.308(a)(2))

The covered entity must have a documented security official. Titled role, clearly assigned responsibilities, documented delegation for multi-entity organizations.

#Workforce security (§164.308(a)(3))

Tightened access controls:

• Documented access authorization for all ePHI systems
• Access reviews with specified cadences
• Documented termination procedures for workforce members
• Background checks integrated with access provisioning
• Specific role-based access control requirements

#Information access management (§164.308(a)(4))

Minimum necessary standard strengthened with documentation requirements. Role-based access control, documented access justifications, periodic review.

#Security awareness and training (§164.308(a)(5))

Expanded training requirements:

• Annual security awareness training for all workforce
• Role-specific training for technical roles
• Specific topics required: phishing, social engineering, incident reporting, physical security, device handling, acceptable use
• Testing and documentation of completion
• Remedial training for policy violators

#Security incident procedures (§164.308(a)(6))

The major incident response changes:

• Documented incident response plan
• Annual plan testing (tabletop or simulation)
• Specific roles and responsibilities defined
• Communication plans (internal, external, regulatory)
• Evidence preservation procedures
• Post-incident review and documentation

#Contingency plan (§164.308(a)(7))

Business continuity requirements:

• Data backup plan with tested restoration
• Disaster recovery plan with tested procedures
• Emergency mode operation plan
• Testing and revision procedures
• Applications and data criticality analysis

#Evaluation (§164.308(a)(8))

The big one: formal annual evaluation of the security program:

• Periodic technical and nontechnical evaluations
• Penetration testing at least annually by qualified third party or qualified internal resource
• Vulnerability scanning at least bi-annually
• Evaluations after significant changes
• Documented remediation of findings

#Business associate contracts (§164.308(b))

Business associates must:

• Meet the same security requirements as covered entities
• Implement safeguards to protect ePHI
• Provide evidence of compliance
• Cooperate with the covered entity's security oversight

#Facility access controls (§164.310(a)(1))

Physical security requirements tightened:

• Documented access controls
• Physical security incident procedures
• Facility security plan
• Workstation location policies

#Workstation use (§164.310(b))

Specific workstation security policies:

• Minimum requirements for workstation configuration
• Physical location requirements
• Acceptable use policies

#Device and media controls (§164.310(d))

Controls for:

• Disposal of ePHI-containing devices
• Media reuse
• Accountability for portable devices
• Data backup and storage

#Access control (§164.312(a))

Technical access controls:

• Unique user identification
• Emergency access procedures
• Automatic logoff
• Encryption and decryption (specified algorithms)
• MFA for all access (this is new. Currently not explicitly required)

#Audit controls (§164.312(b))

Logging and monitoring requirements:

• Specific events that must be logged
• Log retention requirements
• Active log review
• Audit trail integrity protections

#Integrity (§164.312(c))

Data integrity controls:

• Controls to prevent unauthorized modification
• Detection of unauthorized modification
• Recovery from integrity failures

#Transmission security (§164.312(e))

Encryption requirements:

• TLS 1.2 minimum, TLS 1.3 preferred
• Cipher suite restrictions
• Certificate management requirements
• Network segmentation requirements separating ePHI networks

#The specific pentest requirement

The most operationally significant new requirement for most organizations is the annual penetration testing mandate. Let me unpack what it likely means.

#Scope

The proposed rule requires penetration testing covering:

• All systems containing ePHI
• Network infrastructure supporting ePHI systems
• Web applications that process ePHI
• Remote access mechanisms
• Third-party integrations that transmit ePHI

Scope should cover the full "ePHI environment". Not a single web application, not external-facing systems. But the complete attack surface an adversary would use to compromise ePHI.

#Methodology

Penetration testing "by qualified personnel" using "industry-accepted methodology." Likely acceptable:

• PTES (Penetration Testing Execution Standard)
• OSSTMM (Open Source Security Testing Methodology Manual)
• NIST SP 800-115 (Technical Guide to Information Security Testing)
• OWASP Testing Guide (for web application-specific)

The specific methodology matters less than documentation of which methodology was followed and how.

#Tester qualifications

"Qualified personnel" in the context likely means:

• Industry certifications (OSCP, CREST, CEH, GPEN, etc.)
• Demonstrable experience with healthcare-scoped testing
• Independence from the IT operations team being tested
• Documented skills and references

Internal penetration testing is allowed if the internal team is genuinely qualified and independent. Most healthcare organizations don't have internal teams meeting that standard and should expect to use third parties.

#Frequency

At minimum annually. After "significant changes" (which should be defined in your organizational change management policy).

#Findings management

Discovered vulnerabilities must be:

• Classified by severity
• Tracked in a remediation register
• Remediated within documented timelines (typical: critical within 30 days, high within 90 days, medium within 180 days)
• Retested to verify remediation
• Documented as either closed or accepted-risk with business justification

#Deliverables

Expected deliverables:

• Technical findings report with evidence
• Executive summary
• Remediation roadmap with prioritization
• Methodology documentation
• Tester qualifications documentation
• Evidence of remediation after testing complete

OCR investigators following any breach will want to see these documents. Documentation quality matters as much as the testing itself.

#What counts as "substantial change" triggering off-cycle testing

Substantial changes that warrant additional penetration testing:

• Major infrastructure migrations (on-prem to cloud, data center consolidation)
• New significant third-party integration introducing ePHI exposure
• Acquisition of another entity
• Major application deployment or replacement
• Network architecture changes
• Significant organizational changes affecting security posture

Minor changes (patching, routine administrative updates) don't trigger additional testing.

#The vulnerability scanning requirement

Separate from penetration testing, the proposed rule requires bi-annual vulnerability scanning:

• External scanning of internet-facing systems
• Internal scanning of ePHI systems
• Authenticated scanning where feasible
• Documentation of findings and remediation

Commercial scanners commonly used:

• Tenable Nessus / Tenable.io
• Qualys Vulnerability Management
• Rapid7 InsightVM
• Microsoft Defender Vulnerability Management

Open-source alternatives:

• OpenVAS / Greenbone
• Nikto (web-specific)

Monthly or continuous scanning exceeds the bi-annual requirement and is the current industry standard for mature programs.

#The network segmentation requirement

The proposed rule requires logical separation between ePHI systems and general corporate networks. Practically:

• ePHI systems isolated in dedicated network segments (VLANs or separate networks)
• Firewalls or equivalent controls enforcing segmentation
• Restricted communication between segments (jump hosts, specific allowed ports)
• Monitoring at segment boundaries
• Documentation of segmentation architecture

A major architectural requirement for organizations with flat networks (still common in mid-size healthcare). Segmentation work is often a multi-month project.

#The MFA requirement

Currently, HIPAA Security Rule encourages but doesn't explicitly require MFA. The proposed rule makes MFA mandatory for:

• All remote access (VPN, RDP, cloud console)
• Administrative accounts
• Access to ePHI systems
• Access by business associates

Phishing-resistant MFA (FIDO2, WebAuthn hardware keys) is preferred. SMS-based 2FA is acceptable only as a fallback and deprecated over time.

Reality check: MFA deployment in healthcare is patchwork. Many community hospitals still have password-only access for privileged accounts. Building out MFA across the healthcare environment is a real operational lift. User training, hardware keys deployment, service account migration.

#What organizations should be doing right now

If you're responsible for compliance at a healthcare organization, the readiness plan:

#Today (immediate)

1. Read the proposed rule. HHS publication is public. Understand what's specifically required. Don't rely on summaries.

2. Inventory your current state. For each requirement, assess: are we currently compliant, partially compliant, or not compliant?

3. Get your risk analysis current. If you don't have one from the last 12 months, start there. Everything else builds on risk analysis.

4. Start asset inventory if you don't have one. This is foundational to everything else. Several months of work if starting from scratch.

#30-60 days out

5. Schedule an annual penetration test. Even before the rule is final, doing a pentest now lets you:

• Identify gaps
• Budget for remediation
• Build the documentation trail
• Have 12 months of "we were testing before it was required" history

6. Implement MFA on administrative accounts. Least-risk deployment: start with admin accounts, VPN, cloud admin consoles. Expand to workforce over 6-12 months.

7. Document what you've. Written policies, procedures, risk register, incident response plan. Put them in a formal documentation system, not scattered in email threads.

#90-180 days

8. Vulnerability scanning program. Deploy a commercial scanner. Start with external, expand to internal. Monthly scanning cadence.

9. Segmentation assessment. Map your current network. Identify where ePHI systems exist and where segmentation gaps are. Plan remediation.

10. Incident response plan + tabletop. Written plan, test it with your executive team, document the exercise.

#6-12 months

11. Full segmentation implementation. This is a big project. Start early.

12. MFA workforce rollout. Second phase beyond admin accounts.

13. Third-party penetration test of the full ePHI environment. Comprehensive, scoped to HIPAA Security Rule requirements.

14. Business associate compliance review. Every BA contract, every vendor with ePHI access.

#12-24 months (as final rule publishes)

15. Gap analysis against final rule. Final rule may have specific changes from the proposed. Re-verify your posture.

16. Evidence package for OCR. Everything you'd need to demonstrate compliance during an audit or investigation.

17. Continuous improvement. Security program maturation is ongoing, not a project.

#For small healthcare providers

Solo practitioners, small group practices, and small clinics frequently ask whether the proposed rule applies to them. Answer: yes. HIPAA Security Rule applies to every covered entity regardless of size.

Practical accommodations:

• Pentest for a small practice can be scoped narrowly (external-only, web-app only). $5K-$15K engagement
• MFA can be deployed via existing tools (Microsoft 365 MFA, Google Workspace 2FA) with minimal cost
• Asset inventory for a small practice is a spreadsheet, not a million-dollar ITAM deployment
• Risk analysis for small practice can be a structured workbook

What small practices can't accommodate:

• Ignoring the rule entirely
• Assuming "too small to be audited"
• Assuming the business associate (EHR vendor) handles everything

OCR's enforcement history includes significant fines against small practices. Being small doesn't confer exemption.

#For large healthcare systems

Large systems (multi-hospital networks, integrated delivery systems, national payers) face different challenges:

• Scale makes comprehensive testing expensive (multi-100K-endpoint environments)
• Complexity makes risk analysis lengthy
• Vendor sprawl (500+ BAs) makes compliance oversight intensive
• Subsidiary variation makes standardization hard

Typical large-system investments:

• Continuous security testing (not annual pentest. Ongoing adversarial simulation)
• Formal GRC platform (ServiceNow GRC, OneTrust, Archer, Hyperproof) for documentation
• Dedicated MFA + PAM platform for privileged access
• Continuous asset discovery (Armis, Claroty for medical devices, full ITAM)
• Vendor risk platform (OneTrust Vendorpedia, LogicGate)
• Managed detection and response (MDR) for 24/7 coverage
• Formal tabletop exercise program with external facilitation

Annual security spend at large healthcare systems typically runs 5-8% of IT budget. The proposed rule will push this higher.

#The OCR enforcement context

OCR has increased HIPAA enforcement substantially:

• Fines up. Recent enforcement actions in the $500K-$1M range are routine. Multi-million-dollar fines aren't uncommon.
• Corrective action plans mandated alongside fines. Organizations must implement specific remediations over 12-36 months.
• Public disclosure. OCR publishes enforcement actions. The reputational harm often exceeds the financial penalty.
• Focus on basic failures. Most enforcement actions cite failures in risk analysis, access controls, or workforce training. The basics.

Post-final-rule, OCR enforcement will likely focus on the new requirements. Organizations without annual penetration testing, formal risk analysis, and MFA will be at heightened enforcement risk.

#What Valtik does in this space

Valtik Studios provides HIPAA-scoped security services to healthcare providers across Connecticut, Massachusetts, Rhode Island. And the Dallas / Fort Worth region. Our healthcare engagements:

• HIPAA penetration testing scoped to OCR audit requirements
• HIPAA risk analysis. The foundational document
• Vulnerability scanning programs setup and managed
• Network segmentation architectural design and implementation support
• Incident response planning and tabletop exercises
• Business associate compliance reviews
• Post-incident support. If you're already mid-incident

For healthcare organizations that haven't had an independent outside-in security assessment in the last 12 months, the proposed rule makes the next 12-24 months a forced-upgrade period. Getting ahead of it's the right move.

Reach out via https://valtikstudios.com. We're sized for healthcare organizations from small specialty practices through regional hospital systems.

#Sources

1. HHS HIPAA Security Rule NPRM. Federal Register
2. HIPAA Security Rule. HHS
3. HIPAA Security Rule Risk Analysis Guidance. HHS
4. NIST SP 800-66 Rev 2: Implementing the HIPAA Security Rule
5. OCR Enforcement Actions
6. NIST SP 800-115: Technical Guide to Information Security Testing
7. OCR Audit Protocol
8. HHS Cybersecurity Performance Goals for Healthcare
9. 405(d) Healthcare Cybersecurity Program
10. HITRUST CSF