Healthcare Cybersecurity

HIPAA Penetration Testing Requirements 2026: A Practical Guide

The HIPAA Security Rule is being updated. The proposed rule would require annual penetration testing. This guide explains what the proposed changes include, what is required today, and how to prepare your organization regardless of the final timeline.

Proposed rule status: The proposed HIPAA Security Rule update would require penetration testing every 12 months and vulnerability scans every 6 months. As of mid-2026, HHS has delayed the final rule's projected publication until at least July 2027. No mandatory compliance deadline has been officially set. Organizations should prepare now regardless of the final timeline.

Why it matters

Healthcare organizations are high-value targets

Medical records, billing information, insurance data, Social Security numbers, prescription history, diagnoses, lab results, and patient portal access — healthcare organizations store some of the most sensitive information a person has.

A cyberattack against a healthcare organization is not just an IT problem. It can interrupt patient care, shut down scheduling, delay billing, expose private records, damage trust, and create serious compliance exposure.

The HIPAA Security Rule already requires covered entities and business associates to protect ePHI with appropriate administrative, physical, and technical safeguards. Penetration testing helps prove whether those safeguards actually work.

A policy says what should happen.

Policies document intent and expectations. They define the rules — but they do not prove the rules are followed or effective.

A vulnerability scan shows what may be weak.

Automated scanners identify known weaknesses, outdated software, and missing patches. They flag possible problems — but they usually cannot prove exploitability.

A penetration test shows what an attacker can actually do.

A skilled tester simulates real attack behavior to determine whether vulnerabilities can be exploited, chained, and used to reach ePHI. That is real-world evidence.

Enforcement context

Recent Enforcement Shows the Risk

Documentation may satisfy a checklist. Independent validation helps prove whether the controls actually work.

$250,000
ASC Ransomware Penalty

An ambulatory surgery center was penalized after a ransomware incident exposed gaps in risk analysis and security validation.

$1.5M
Healthcare Cybersecurity Penalty

OCR enforcement has escalated around cybersecurity failures, incomplete risk analysis, and insufficient protection of ePHI.

$200,000
Right-of-Access Penalty

HIPAA exposure is not limited to cyberattacks. Process failures, documentation gaps, and patient access issues also create financial risk.

$2.1M+
Maximum Penalty Exposure

HIPAA penalties can reach seven figures, making security validation a finance-level and leadership-level concern — not just an IT task.

Penalty figures are based on publicly reported enforcement examples. They are provided for general context only and do not represent guarantees, predictions, or legal advice.

The proposed rule

What the proposed HIPAA Security Rule update would require

The proposed HIPAA Security Rule update would require regulated entities to perform penetration testing of relevant electronic information systems by a qualified person — someone with appropriate knowledge and experience in generally accepted cybersecurity principles and methods for protecting ePHI.

The proposed rule would require vulnerability scanning at least every six months and penetration testing at least once every 12 months. As of mid-2026, HHS has delayed the final rule's projected publication until at least July 2027, and no mandatory compliance deadline has been officially set.

Proposed requirements
Every 6 mo.
Vulnerability scanning
Every 12 mo.
Penetration testing
TBD
Final rule delayed to at least July 2027
Required today
  • Risk analysis identifying ePHI risks
  • Evaluate risks and vulnerabilities to ePHI
  • Implement reasonable safeguards
  • Review and update security measures
  • Document policies and compliance activity
  • Manage risks through corrective action
Proposed under updated rule
  • Asset inventories and network maps
  • Vulnerability scanning every 6 months
  • Penetration testing every 12 months
  • MFA requirements
  • Network segmentation controls
  • Stronger backup and recovery controls

The practical takeaway

Risk analysis is already required. Protecting ePHI is already required. The proposed rule would make penetration testing explicitly required on an annual basis. While the final rule and compliance deadline remain pending, organizations that build this capability now will be better positioned when the rule is finalized — and better protected against real-world attacks in the meantime.

Key distinction

Vulnerability scanning vs. penetration testing

Many healthcare organizations confuse these two activities. They are related but fundamentally different. Healthcare organizations need both.

Vulnerability scanning

Identifies possible weak spots

Usually automated. A scanner looks for known weaknesses, outdated software, exposed services, missing patches, weak configurations, and known vulnerabilities.

A scan helps answer:
  • • What systems are missing patches?
  • • What devices are exposed to the internet?
  • • What software is outdated?
  • • What known vulnerabilities exist?
  • • What issues should be fixed first?

Limitation: Scanning may tell you a weakness exists, but it usually does not prove whether an attacker can actually exploit it, chain it with other weaknesses, steal credentials, access ePHI, or move through your network.

Penetration testing

Validates whether weak spots can actually be used

A qualified tester simulates real-world attack behavior within an approved scope. Goes deeper than scanning by actively attempting exploitation.

A penetration test helps answer:
  • • Can an attacker get into the environment?
  • • Can one patient access another patient's records?
  • • Can a stolen password lead to broader access?
  • • Can a compromised workstation reach ePHI?
  • • Can weak segmentation allow lateral movement?
  • • Can a remote access system be bypassed?
Scope considerations

What systems should be included in scope?

The right scope depends on the organization. Before testing, you need to understand where ePHI lives — you cannot protect what you have not identified, and you cannot test what you have not scoped.

Internet-Facing Systems
  • ·Public websites
  • ·Patient portals
  • ·Telehealth platforms
  • ·VPN gateways
  • ·Remote access portals
  • ·Cloud login portals
  • ·Email systems
  • ·APIs
  • ·Vendor-managed portals

Could an attacker outside the organization discover, attack, exploit, bypass, or abuse these systems?

Internal Network
  • ·Network segmentation
  • ·Active Directory security
  • ·Privilege escalation paths
  • ·Shared folders
  • ·Local admin rights
  • ·Weak passwords
  • ·Unpatched internal systems
  • ·Database access
  • ·Access to ePHI from unauthorized systems

If one account or one device is compromised, can the attacker reach ePHI?

Patient Portals
  • ·Cross-patient record access
  • ·Authentication bypass
  • ·Password reset abuse
  • ·Staff-level function access
  • ·Document exposure
  • ·API authentication
  • ·Session token protection

Can one patient access another patient's records? Can authentication be bypassed?

Telehealth Platforms
  • ·Login security
  • ·Session controls
  • ·Meeting access
  • ·Recording settings
  • ·Chat and file sharing
  • ·Identity verification
  • ·API security
  • ·Data retention settings

Is the platform configured, monitored, and tested to protect patient interactions?

Web Applications & APIs
  • ·Authentication and authorization
  • ·Session management
  • ·SQL injection
  • ·Cross-site scripting
  • ·File upload flaws
  • ·Access control failures
  • ·Business logic flaws
  • ·Sensitive data exposure

Do applications that connect to sensitive systems have exploitable weaknesses?

Cloud Systems
  • ·Identity and access management
  • ·MFA enforcement
  • ·Administrative roles
  • ·Over-permissioned users
  • ·Public storage exposure
  • ·Logging and alerting
  • ·Data export controls
  • ·Third-party integrations

Is the organization's configuration secure even though the cloud platform is?

Special considerations

Different organizations, different approaches

The proposed rule does not mean every organization needs the same exact test. Scope should be based on risk, systems, ePHI exposure, and organizational context.

Small Practices

Fewer systems does not mean lower risk. Small practices often handle highly sensitive ePHI and rely heavily on cloud systems, outsourced IT, remote access, and billing vendors. Start with an asset inventory, confirm MFA, review EHR and portal access, run vulnerability scanning, and perform focused external testing.

Rural Hospitals

Limited IT staff, older systems, medical devices, budget pressure, and critical patient care operations create unique challenges. Coordinate testing windows with clinical leadership, avoid disruptive testing on clinical systems, use safe validation methods for medical devices, and evaluate segmentation between clinical, administrative, and device networks.

FQHCs

Tight financial and staffing constraints while serving vulnerable populations. Focus on practical, high-impact actions: identify ePHI systems, document vendors, prioritize EHR access, patient portals, email, remote access, and billing systems. Use risk-based scoping and remediation plans that reflect budget realities.

Medical Devices

Imaging, infusion, monitoring, diagnostic, and lab systems require special care. Some are difficult to patch, vendor-managed, or tied directly to patient care. Use safer approaches: network segmentation review, passive discovery, configuration review, known vulnerability review, and vendor documentation review. Patient safety is always the priority.

Business Associates

Vendors that create, receive, maintain, or transmit ePHI can create serious risk. Ask for BAAs, security program summaries, penetration test attestations, MFA status, encryption status, incident response procedures, and SOC 2 reports where available. You may not receive a full report, but vendors should provide reasonable assurance.

Choosing a vendor

How to evaluate a penetration testing vendor

Not every vendor that sells "security testing" is performing a real penetration test. The proposed rule refers to testing by a qualified person with appropriate knowledge and experience.

Questions to ask
  • ?Have you tested healthcare organizations before?
  • ?Do you understand HIPAA and ePHI risk?
  • ?What methodology do you use (NIST, OWASP, PTES)?
  • ?Will the test include manual testing or only automated tools?
  • ?How do you avoid disrupting clinical operations?
  • ?Will you test web apps, cloud systems, APIs, internal, and remote access?
  • ?Will you provide a clear report with business risk, evidence, and remediation?
  • ?Will you retest after remediation?
  • ?Do you carry professional liability or cyber liability insurance?
  • ?Will you sign an NDA and BAA if needed?
  • ?How quickly will you notify us of a critical finding?
  • ?Who exactly will perform the work?
Red flags
  • Promises guaranteed HIPAA compliance
  • Calls an automated scan a penetration test
  • Cannot explain its methodology
  • Cannot provide a sample report
  • Has no healthcare experience
  • Will not define scope
  • Does not provide remediation guidance
  • Does not offer retesting
  • Offers a price that seems too low for the scope

A real penetration test should produce evidence, context, risk ranking, and a path to remediation. A generic scanner report is not enough.

Annual cycle

Practical 12-month penetration testing cycle

Build a repeatable yearly cycle to prepare for the proposed annual testing requirement and strengthen your security posture continuously.

Month 1
Inventory & Scope
  • Update asset inventory
  • Update ePHI data flow map
  • Identify critical systems
  • Identify business associates
  • Review prior findings
  • Define testing goals
Month 2
Pre-Test Cleanup
  • Patch obvious issues
  • Disable unused services
  • Review MFA
  • Review remote access
  • Review exposed systems
  • Clean up stale accounts
Month 3
Vulnerability Scanning
  • Run automated scans
  • Prioritize findings
  • Remediate critical/high findings
  • Document exceptions
Month 4
Test Planning
  • Select qualified vendor
  • Finalize scope
  • Approve rules of engagement
  • Confirm testing windows
  • Notify stakeholders
  • Prepare emergency contacts
Month 5
Penetration Testing
  • Conduct external testing
  • Conduct internal testing
  • Test applications and portals
  • Escalate critical findings immediately
Month 6
Report Review
  • Review findings with vendor
  • Validate severity
  • Assign owners
  • Set remediation deadlines
  • Brief leadership
Months 7–9
Remediation
  • Fix critical and high findings
  • Track medium findings
  • Document compensating controls
  • Update policies
  • Update risk analysis
Month 10
Retesting
  • Retest remediated findings
  • Document closure
  • Address failed fixes
Month 11
Program Improvement
  • Update training
  • Improve monitoring
  • Improve segmentation
  • Improve vendor oversight
  • Adjust incident response
Month 12
Executive Review
  • Review annual results
  • Approve next year plan
  • Budget for improvements
  • Update risk management docs
  • Prepare for next cycle
Common mistakes

10 penetration testing mistakes healthcare organizations make

01
Calling a vulnerability scan a penetration test

A scanner report is not the same as a penetration test. Scanning identifies possible weaknesses. Penetration testing validates real-world exploitability.

02
Testing without an asset inventory

If you do not know where ePHI lives, your scope may be incomplete and the test may create a false sense of security.

03
Ignoring internal risk

External testing is important, but many real attacks involve stolen credentials, compromised workstations, or lateral movement inside the network.

04
Excluding patient portals

Patient portals are high-risk because they are internet-accessible and connected to sensitive patient information.

05
Not retesting after remediation

If a critical vulnerability is fixed but never retested, you do not know whether the fix actually worked.

06
Letting reports sit unused

A penetration test report is not protection. Remediation is protection. The value comes from fixing what was found.

07
Buying the cheapest test

Cheap testing often means narrow scope, automated tools, weak reporting, and little remediation value.

08
Forgetting business associates

Vendor systems can affect ePHI even when they are outside your direct network.

09
Disrupting clinical operations

Healthcare testing must be planned around clinical operations and patient safety — never at the expense of care.

10
Treating HIPAA as paperwork

Documentation matters, but documentation without real security controls is not enough to protect patients or ePHI.

Do not wait for the final rule

The safest approach is to build the capability now

Start by identifying where ePHI lives. Know what systems matter. Scan regularly. Test realistically. Fix what is found. Retest the fixes. Document the process. Make penetration testing part of your organization's normal security rhythm.

The organizations that do this well will not only be better prepared for HIPAA changes — they will be better prepared to protect patients, preserve operations, and reduce the damage of real-world cyberattacks.

Zero Assumption Security provides consultation, scoping, and engagement coordination. Technical testing is performed by a vetted offensive-security partner disclosed during the scoping process.