HIPAA Vulnerability Scanning Requirements and What to Expect

All U.S. healthcare businesses and their associates handling Electronic Protected Health Information (ePHI) must ensure the confidentiality, integrity, and availability of sensitive medical information. An important part of ensuring they meet HIPAA compliance requirements is running regular vulnerability scans.

In this guide, we explore the HIPAA vulnerability scan requirements expected of these businesses, why scanning is important, and what the Office for Civil Rights (OCR) auditors look for.

The importance of vulnerability scanning to a HIPAA security program.

HIPAA vulnerability scanning is both an important ePHI safeguard and an audit defense. Scans identify potential weaknesses and risks to ePHI across systems that handle them, meaning businesses can remediate them before attackers take advantage. Proof of regular vulnerability scanning helps businesses to stay HIPAA compliant, protecting them against penalties.

What’s more, regular scans (and remedial action) protect firms against reputational damage and data breaches that can arise from mishandling ePHI. Data breaches can result in legal action, loss of revenue, and enforcement action, especially if HIPAA compliance is ignored.

Within HIPAA, covered entities and business associates are expected to manage administrative safeguards to protect ePHI. These help to evaluate how effective their security measures are in keeping ePHI safe and maintaining HIPAA compliance at all times.

Where vulnerability scanning sits within HIPAA requirements.

At the time of writing, the HIPAA Security Rule states that covered entities and associates must carefully assess their administrative, physical, and technical safeguards. This can include vulnerability scanning, though the current wording does not dictate it. Upcoming proposed HIPAA Security Rule changes, however, mandate regular scans.

The proposed update, issued as a Notice of Proposed Rulemaking (NPRM), marks an important shift from “recommended standards” toward mandated HIPAA vulnerability scan requirements.

“The NPRM proposes to strengthen the Security Rule’s standards and implementation specifications with new proposals and clarifications.”

HHS

Specifically, the proposed 2026 update requires covered entities and associates to run vulnerability scans at least once every six months. In addition, the update states they must perform penetration testing at least once a year and compile a thorough written risk analysis that defines reasonable threats to ePHI.

As of the date of publishing, these proposals (and all those linked above) remain under review, with a final rule expected July 2027.

Who is required to run scans for HIPAA?

All companies deemed “covered entities” and business associates (BAs) should run vulnerability scans. To uphold legal obligations, covered entities and associates must sign Business Associate Agreements (BAAs) to establish contractual security expectations.

Covered entities include health plans, healthcare providers, and clearinghouses. They have an obligation to safeguard, and therefore scan, every system and endpoint that creates, receives, maintains, and transmits ePHI.

Business associates are subject to the same obligations. These include IT vendors, billing processors, Electronic Health Record (EHR) partners, and cloud providers. Therefore, under the proposed changes to HIPAA cybersecurity requirements, BAs must follow the same stipulations as the entities they work with.

Subcontractors of business associates, too, have identical vulnerability scanning duties (should they need to handle ePHI while providing a service).

What assets and systems a scan must cover.

If a system, endpoint, device, or network asset “touches” ePHI, it must be scanned for vulnerabilities and accounted for under HIPAA safeguards. These assets may be on-premises, in the cloud, or otherwise off-site (depending on BAAs and how ePHI is agreed to be handled).

First, covered entities and business associates should consider on-premises ePHI handling points. These include:

• Firewalls
• Servers
• Routers
• Access gateways (e.g., VPNs)
• Switches
• Workstations
• Laptops, computers, storage devices, and mobile devices
• Wireless controllers
• Any assets that face externally

Cloud and virtual endpoints, too, fall under the same scanning program and expectations. These include:

• Cloud workloads (e.g., IaaS and PaaS)
• Virtual and virtualized environments
• Registries
• Web applications (e.g., patient portals and health record middleware)
• Virtual and external backups
• Container images
• APIs

Beyond infrastructure, vulnerability scanning must also account for medical devices that process ePHI. If a device cannot be scanned, entities must follow manufacturer guidance and use compensating controls.

How often scans must run and what triggers additional scans.

All entities covered by HIPAA should set a regular scan cadence as a baseline. For example, under the proposed update, covered entities and BAs must run vulnerability scans at least every six months. However, they should also be conducted in the event of any significant changes made to networks or technologies that touch ePHI.

Changes that should trigger vulnerability scans include:

• Alterations made to networks and endpoints
• Adoptions of new technologies
• Scanner updates that alter detection coverage

Vulnerability scans must also take place after security incidents or whenever weaknesses are disclosed. It’s also important to run full scans after critical weaknesses have been remediated.

How a HIPAA vulnerability scan actually works.

HIPAA positions vulnerability scanning as repeatable and continuous, not designed to run as one-off events. Scans run authenticated and unauthenticated checks within a predetermined environment and frequency schedule. They capture vulnerability findings and apply severity and risk ratings, followed by recommended remediation plans.

Crucially, it’s the entity’s scanning policy that determines the exact scope and coverage of future scans. There is, therefore, an extensive investigation and mapping process to determine what to scan across an infrastructure–i.e., all assets that interact with ePHI.

The frequency of rescanning should be determined by careful risk assessment and analysis, and how often hardware and software receive security patches.

For example, an endpoint determined to have a high risk of a data breach will require more frequent vulnerability scanning. An asset that receives frequent security patches must be scanned after each significant update.

Every scan report advises the end user of how severe vulnerabilities are, if present, and should use a CVSS, or Common Vulnerability Scoring System. This system helps entities to determine future scan frequency and remediation needs based on risk and scope.

After remediations, scans should run again to provide and verify closure, indicating that any problems discovered have been minimized. Vulnerability scanning schedules should be easy to repeat in the event of significant network changes or ad hoc disruptions.

Vulnerability scanning compared to penetration testing.

Vulnerability scanning and penetration testing are two complementary measures for supporting ePHI under HIPAA. External vulnerability scanning is an automated process, as is authenticated, internal scanning. Penetration testing, meanwhile, is a largely manual process.

Automated vulnerability scans run in the background while operations continue, and penetration tests are recommended at least once a year. It is an immersive, investigative process during which cybersecurity experts test and exploit vulnerabilities in controlled environments. The aim, therefore, is to determine the potential real-world impacts of a breach on ePHI.

Running six-month vulnerability scans, meanwhile, brings known weaknesses to the surface. Scanning determines the breadth of vulnerabilities, while penetration testing ascertains how deep they go.

Prioritizing findings and closing out remediation.

By following Common Vulnerability Scoring System (CVSS) scoring and building a risk-based Service Level Agreement (SLA) matrix, entities determine how scanning findings can be prioritized for remediation. The reporting stage of the process, during which vulnerabilities are discovered, allows teams to verify the impact of threats posed and which require the most attention.

Within a matrix, entities can build remediation timelines around three key factors:

• How severe a vulnerability appears to be
• What the likely impacts are to the business
• The extent to which ePHI may be exposed

For example, a system misconfiguration, while simple, may require priority remediation if there is a possible risk of ePHI exposure and if the business faces significant detriment as a result.

Any vulnerabilities that entities cannot patch right away will require clear documentation that justifies delaying remediation. A memo that accepts risk, for example, should clearly identify what compensating controls are in place, and confirm that leadership has signed off on the delay.

Final verification rescans confirm that vulnerability findings are closed and that suitable, immediate remediation has been completed. However, entities must continue tracking remediation through risk management workflows and service management systems.

Documentation and reporting standards auditors look for.

Carrying out vulnerability scans and applying safeguards alone are not enough to pass HIPAA compliance. OCR auditors need to see specific written records showing how entities safeguard ePHI, and that there is clear evidence of continuous risk analysis, scanning, and remediation planning.

Records required by OCR include:

• Data protection policies, procedures, and protocols
• BAAs
• Full asset inventories
• Risk assessments
• Training records
• Detailed scan reports
• Signed disclosure authorizations
• Remediation plans
• Security and privacy officer designations
• Executive summaries
• Security incident reports

All entities covered by HIPAA must retain documents for at least six years, as per 45 CFR § 164.316(b)(2), applicable to all documentation falling under the Security Rule. This scope includes time-stamped scan reports and remediation plans:

“(2) Implementation specifications:

• (i) Time limit (Required).  Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.
• (ii) Availability (Required).  Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.
• (iii) Updates (Required).  Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information."

ECFR (2026)

Documentation that establishes findings must also clearly link to any affected assets, responsible owners, deadlines set for remediation, and any outcomes reached through verification.

Connecting scanning to risk management and continuous monitoring.

All entities covered by HIPAA should keep a central risk register, where scan outputs are delivered to and tracked. Continuous monitoring, built around the register’s data and a risk-based schedule, can help boost threat visibility and ensure ePHI environments remain HIPAA compliant.

Scan outputs should include vulnerabilities clearly mapped to the assets, data flows, and compensating controls they impact. Feeding into a risk register, entities are better prepared to continuously monitor for threats and manage risks, instead of treating scanning and security checks as one-off events.

Through continuous monitoring, scheduled scans can extend through vulnerability management workflow tools and integrate with Security Information and Event Management (SIEM) setups. The result is that security steering committees always have access to unresolved (but critical) findings as standard report items.

Tools, competencies, and service models across organization sizes.

Applicable vulnerability scanning tools and models vary depending on organizational size, individual obligations, environmental complexities, available funds and resources, and scale of risk.

For example:

• Small companies may use managed services and authenticated platforms to handle scanning, therefore saving money and resources. This helps them to meet baseline semiannual scanning requirements.
• Mid-sized organizations, meanwhile, typically have larger budgets and more resources to choose between qualitative and quantitative risk analyses. However, as many rely on older, legacy systems, they must do so while considering hardware limitations. This can mean scheduling and fine-tuning scanning around systems' impact.
• Larger healthcare systems handle millions of sensitive records and therefore need enterprise-grade, professional vulnerability management support. Given the scale of records handled and potential for reputational damage, larger businesses adopt automated scanning services aligned with frameworks such as NIST SP 800-66. Beyond this, they engage with credentialed scanning and penetration testers on a risk-based schedule.

Importantly, these are only illustrative examples. In practice, covered entities and BAs have very specific needs tied to budgeting, obligations, and physical capabilities.‍

FAQs

Q1. How often are vulnerability scans required under HIPAA?

Vulnerability scanning is advised every time a significant change is made to a network, entity, relationship, or process that impacts ePHI.

Current HIPAA Security Rule does not specify exact timeframes for conducting vulnerability scans. Organizations have flexibility in determining how often to perform these assessments.

Under the proposed HIPAA Security Rule updates, covered entities and business associates would be required to run vulnerability scans at least every six months.

Q2. Do internal and external scans both need to cover unpatched workstations?

Yes, internal and external scanning must cover unpatched workstations if they handle, store, manage, or otherwise transmit ePHI. Covered entities and business associates must run vulnerability scans every time an asset receives a significant patch and adhere to a regular update schedule.

Q3. How do credentialed scans differ from annual penetration tests?

Credentialed scans are automated and continuous vulnerability checks that require user credentials to investigate internal controls. Annual penetration tests are controlled, manual attacks that explore vulnerability impacts. The former brings threats to the surface, while the latter explores their potential damage.

Q4. What should BAAs say about vulnerability management?

Business Associate Agreements must clearly identify responsibilities for identifying, managing, remediating, and reporting on any weaknesses found in ePHI environments. They should mandate scanning schedules, establish breach notification protocols, outline compensating measures, and offer clear patching timelines.

Q5. How are CVE numbers tracked for continuous assessment?

Common Vulnerability and Exposure (CVE) numbers are unique identifiers for vulnerability flaws, which are mapped to national databases and Common Vulnerability Severity Score (CVSS). Vulnerability scanners continuously update their definitions so that new weaknesses can be identified, mapped, and flagged for remediation as soon as they arise.

Conclusion

To keep ePHI protected and to stay compliant with HIPAA’s standards, healthcare businesses must use vulnerability scanning as a continuous discipline, not a periodic exercise.

Establishing a risk and change-based approach to vulnerability scanning helps covered entities and their associates remain compliant for auditing and robust in the face of data threats.

Compliance doesn’t need to be complex. Learn more about VikingCloud’s HIPAA compliance, vulnerability scanning, and penetration testing services and start protecting your ePHI for the better.

‍