164.308(a)(5)(ii)(B) malware protection requirements

What HIPAA requires for malicious software protection

If you must show malware protection under 164.308(a)(5)(ii)(B), the specification asks for procedures that guard against, detect and report malicious software. It sits under the security awareness and training standard, so an assessor will look at both the technical controls on your systems and what your workforce is taught to recognize and report. The rule defines malicious software, in 45 CFR 164.304, as software such as a virus designed to damage or disrupt a system. The specification is addressable, not optional: you must assess whether each part is reasonable and appropriate for your environment, implement it if so, and if not, document why and put an equivalent alternative in place.

The risk this specification targets is ransomware and endpoint compromise that reaches ePHI on laptops, workstations, servers and shared file stores. Two things usually make it hard. First, endpoints are scattered across offices, home workers, clinics and vendor-managed devices, so no one has a complete inventory. Second, ownership is unclear: IT assumes end users will avoid risky downloads, staff assume IT's tools will catch everything, and nobody owns the reporting path when a suspicious email is opened. Your risk analysis should name the endpoints and systems that hold ePHI and the person accountable for each.

Before you finalize your position, confirm three things in writing: which anti-malware and detection tools cover each ePHI system, who reviews their alerts and on what schedule, and how a workforce member reports a suspected infection. If you decide a control is not reasonable and appropriate, the documentation should explain the reasoning and the alternative you chose. HHS also lists a ransomware fact sheet among its Security Rule guidance, which is a useful reference when you write these procedures. Independent assessors will test whether the procedures exist, are followed and produce records, so keep those records.

Which systems, staff and vendors fall under malware procedures

The malware procedures in 164.308(a)(5)(ii)(B) apply to every system, person and third party that touches electronic protected health information, not just the core network. Scoping is the first decision, because it sets the endpoint inventory, the training audience and the vendor terms that everything else depends on.

Workstations and servers holding ePHI

Desktops, shared clinic workstations and servers that store, process or transmit ePHI are the baseline scope. Each one needs malware detection and a reporting path, so the first task is an accurate asset inventory tied to the systems in the risk analysis. Ask whether the inventory includes systems that were never formally onboarded, such as older servers or devices used for imaging or lab interfaces.

Laptops that leave the building

Laptops and removable devices that travel with clinicians or staff move outside the controls of the network perimeter. They need the same detection and update expectations as on-site machines, and they should report to your monitoring stack when they reconnect. Confirm how offline devices are handled, because a laptop that stays disconnected for weeks can miss signature and policy updates.

Mobile devices accessing ePHI

Phones and tablets that open email, EHR sessions or messaging with ePHI are in scope even when they are personally owned. Scoping decides whether these devices are enrolled in management, whether they can store ePHI locally and how their malware exposure is evaluated. Document the decision in the risk analysis so the choice is traceable.

Cloud workloads and hosted applications

Virtual machines, containers and managed services that hold ePHI extend the scope into your cloud accounts. Endpoint agents may not fit ephemeral workloads, so the effort shifts toward image hardening, log collection and telemetry from the hosting platform. Confirm which controls are yours and which sit with the cloud provider under its business associate terms.

Clinical, billing and IT administrator training

Malware training must reach clinical staff who open attachments and links, billing staff who handle payment files and remittance documents, and IT administrators who hold elevated rights. Each group needs a different scenario, such as a fake invoice, a document macro or a privileged tool misused. The training audience should follow the workforce roles identified in access management, so it stays current as roles change.

Managed IT providers and their endpoints

A managed IT provider whose administrative endpoints can reach ePHI systems is part of the malware scope, even though the practice does not own those devices. Your business associate agreement should require that provider to maintain malware protection and report incidents, and you should ask for evidence of both. Confirm whether the provider's management tooling has administrative reach into your environment.

Why the addressable label still requires a documented decision

Addressable does not mean optional. Under 45 CFR 164.306(d)(3), a covered entity or business associate must first assess whether a malicious software protection procedure is reasonable and appropriate for its environment. If it is, the entity implements it. If it is not, the entity must document why not and implement an equivalent alternative measure, provided that alternative is itself reasonable and appropriate. Skipping the assessment, or leaving it undocumented, fails the rule even when the entity runs some endpoint tooling. An assessor will ask for the reasoning, not only the product list.

A defensible decision record for malware protection names the systems in scope, the threats the risk analysis identified for them, the control chosen, and the reason for that choice. For example, an illustrative clinic might record that its workstations and file servers that hold ePHI need anti-malware with signature and behavioral detection, plus a documented reason why an email gateway control was chosen over a web filter for a specific workflow. The record should also show who approved the decision, the date, and when it will be revisited after an incident or a change in environment. Confirm the current wording of the rule and the HHS ransomware fact sheet before you write the record, so that the terms you use match the source.

An assessor will expect the risk analysis, not a generic statement, to drive the choice of endpoint controls. A line such as "we run antivirus on all devices" tells the assessor nothing about why that control fits the ePHI in your environment. Ask which assets the risk analysis rated highest, whether medical devices or unmanaged endpoints were considered, and how detection findings feed back into the risk management plan. If the answer is that the risk analysis was never updated after a new system went live, expect that gap to appear in the finding. An independent assessor can test this chain of reasoning, but it is the organization that must own it.

How an assessor tests malware protection

This table compares six areas an assessor typically examines for 164.308(a)(5)(ii)(B), listing the test approach, the evidence requested and the findings that most often come up. Read each row as a question the assessor will ask, then check whether your records answer it without a conversation.

Test area	Test approach and evidence requested	Common findings
Written malware procedures and risk analysis link	Assessor reads the malware procedures and traces them back to the risk analysis entries for malicious software. Ask for the document, its version history and the approval record.	Procedures exist but do not name the systems or threats in the risk analysis, or they were never updated after the environment changed.
Addressable decision record	Assessor checks whether the entity documented that the specification was assessed as reasonable and appropriate, implemented, or replaced with an equivalent measure with reasons. Ask for the signed decision memo.	No written decision, or a blanket statement that malware protection is covered without describing the measures used.
Endpoint protection coverage across the asset inventory	Assessor compares the asset inventory against endpoint agent or antivirus console records to find devices with no protection, out-of-date signatures or unmanaged systems. Ask for the inventory, console export and exceptions list.	Servers, laptops, medical devices or contractor machines missing from the console, and exceptions without an owner or expiry.
Detection and alert handling	Assessor samples recent detections and follows each one to triage, containment and closure. Ask for alert logs, ticket records and any tuning or suppression rules.	Alerts generated but not reviewed, quarantine events closed without a root cause, or suppression rules that hide recurring detections.
Reporting paths for suspected malware	Assessor tests whether a staff member can tell who to contact and how, then checks that reports reach the security official or incident process. Ask for the reporting instructions and sample tickets.	Reporting path lives only in one person's head, or reports are logged by IT but never escalated to the incident procedures.
Workforce training on recognizing and reporting malicious software	Assessor reviews training content and attendance, then interviews a sample of staff about phishing, suspicious attachments and unexpected pop-ups. Ask for the course material, completion records and phishing exercise results.	Training covers general cybersecurity but not malicious software, or staff can describe the rule but cannot say how to report a suspected infection.

Sequence to put malware procedures in place

This sequence turns the addressable malicious software specification into working procedures: detection, query and triage tooling, a documented decision, trained staff and tested evidence. Each step names the artifact it produces so an assessor or auditor can trace the control from policy to proof.

Confirm the risk analysis inputs
Start from the risk analysis under 164.308(a)(1)(ii)(A), which should already list where ePHI lives, the endpoints and servers that touch it, and the malware threats that apply to them. The security official or the team that owns the analysis confirms that the entries for ransomware, malicious email attachments and removable media are current. The output is a short list of malware risks mapped to affected systems, which every later step refers back to. Confirm that the list matches the scope you intend to defend before moving on.
Record the addressable decision
Under 45 CFR 164.306(d)(3), the organization must decide whether malware protection procedures are reasonable and appropriate for its environment. Most organizations with ePHI on general-purpose computers will find they are, but the decision must be written down either way. The security official records the rationale, the systems in scope and, if any alternative measure is chosen instead, why it is equivalent. The output is a signed decision record that links to the risk analysis. Ask counsel or your compliance lead to review the wording if the environment is unusual.
Inventory endpoints and servers
Build a current inventory of every host that stores, processes or transmits ePHI, including workstations, servers, virtual machines, laptops and any medical or imaging devices that run general-purpose operating systems. Record the operating system, owner, network segment and whether the device is managed. Compare the inventory against directory records and network discovery to catch unmanaged hosts. The output is a reconciled asset list. Unmanaged devices found here become a remediation item in the risk management plan.
Select and deploy detection and query tooling
Choose the tools that will detect and investigate malware on the inventoried hosts. Open-source options include osquery for SQL-based queries of running processes, kernel modules, network connections and file hashes across a fleet, Velociraptor for collecting forensic artifacts and running hunts across groups of systems, and Wazuh for comparing collected events with a ruleset and mapping alerts to MITRE ATT&CK. Confirm each tool's license terms and support model with its vendor or project before adoption. Deploy agents to the pilot group first, then the full inventory. The output is a deployment record showing which hosts report, and a configuration baseline stored under change control.
Define alert triage and reporting paths
Write the procedures that say what happens when a detection fires: who reviews it, how a suspected infection is classified, when it is escalated to the security incident procedure under 164.308(a)(6), and who decides whether a breach assessment is needed. Route alerts through a log and alerting layer such as OpenSearch Security Analytics, which can run Sigma-based detectors and send findings to Slack or email, or through Wazuh's alert outputs. Assign severity levels and named owners. The output is a written triage runbook, an escalation matrix and a configured alert route that has been checked end to end.
Train the workforce to spot and report
Under the training standard in 164.308(a)(5), teach staff to recognize malware indicators such as unexpected pop-ups, slow systems, suspicious attachments, unusual sign-in prompts and encrypted-file messages, and to report them immediately through a defined channel. Cover how to avoid unapproved software and removable media. Use security reminders between formal sessions to refresh the material. Record attendance and quiz results per person. The output is training materials, attendance records and a reporting instruction that matches the triage runbook exactly.
Run a test event
Test the whole chain with a controlled exercise. A common approach is to place a harmless test file or a benign simulated malware sample on one pilot host, confirm that the detection fires, that the alert reaches the right person and that staff follow the reporting path. Include a tabletop review of what would happen during a real ransomware event, and reference the HHS ransomware fact sheet in the Security Rule guidance material when writing the scenario. Record each step's time and result, and note any gaps. The output is a test report with findings and assigned fixes.
Retain the output as evidence
Store the artifacts from every prior step in a controlled repository: the risk analysis link, the signed addressable decision, the reconciled inventory, deployment and configuration records, alert logs, triage runbook, training records and the test report. Keep documentation under the six-year retention and availability expectations in 164.316(b). Schedule periodic reviews and updates, and rerun the test event after significant changes to the environment. The output is an evidence index that lets an assessor trace each malware procedure to proof of operation. Confirm the retention period and format with your legal and compliance team.

Which self-hosted tools can produce malware evidence

Malware protection under 164.308(a)(5)(ii)(B) is only as credible as the records behind it. The tools below cover endpoint inventory, forensic collection, detection and alert records, so an assessor can trace a detection back to the host and the rule that caught it. None of them makes an organization compliant on its own.

osquery for endpoint state

osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. Its osqueryd daemon schedules these queries across a fleet, which produces repeatable snapshots of what was running on each host. Check that query schedules, retention and the hosts covered are documented, since an unscheduled query leaves no record of a check. Confirm the license terms, which are Apache-2.0 OR GPL-2.0-only, with your counsel before distribution.

Velociraptor for forensic hunts

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts across groups of systems. Machines that are offline when a hunt starts are scheduled to collect when they reconnect, which helps show that a suspected infection was checked on every host, not only the ones online that day. Each hunt gets a notebook for analyzing combined results, so keep those notebooks as part of the incident record. Note that Velociraptor is licensed AGPL-3.0-only, so review the obligations that apply if you modify and offer it to users over a network.

OpenSearch Security Analytics detections

OpenSearch Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with the rule, log type and severity, and alerts can go to channels such as Slack or email. Its correlation engine links findings across log types in a correlation graph, which helps show how a malware event moved between systems. Confirm which Sigma rules are enabled and who reviews the findings, because an unreviewed finding is not evidence of response. This component is Apache-2.0.

Wazuh rules and alert records

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you add. Matching alerts are written to alerts.log and alerts.json and mapped to MITRE ATT&CK, which gives assessors a consistent technique reference. Confirm which rule groups are active on each host type, since a disabled ruleset produces silence rather than assurance. Wazuh is licensed GPL-2.0-only, so confirm how its distribution and any modifications affect your deployment.

What malware protection costs in money and effort

This table breaks the cost of meeting 164.308(a)(5)(ii)(B) into components, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. Use it to compare a commercial endpoint product against a self-hosted open-source stack, because open-source removes license spend but not the staff time to run it. No figures are given here, so request an itemized written scope before comparing quotes.

Cost component	One-time or recurring	What drives it	How to keep it down
Endpoint protection or detection licenses	Recurring	Number of endpoints, server count, and whether vendor features such as managed detection are included. Open-source agents such as osquery and Wazuh remove license fees but not operating effort.	Confirm which endpoints truly need an agent, and ask the vendor for per-endpoint pricing in writing.
Engineering time for deployment and tuning	One-time, then recurring for changes	Operating system mix, legacy systems that cannot run agents, and the number of custom detection rules written.	Stage rollout by system criticality from the risk analysis, and reuse vetted rule sets before writing custom ones.
Alert triage staffing	Recurring	Alert volume, false positive rate, and whether alerts run around the clock or only during business hours.	Tune detection rules to reduce noise, and document triage steps so less experienced staff can handle routine alerts.
Workforce training time	Recurring	Workforce size, role-specific content for clinicians and front-desk staff, and how often reminders are sent.	Combine malware reporting instructions with existing annual training and short periodic reminders instead of separate sessions.
Evidence upkeep	Recurring	Retention of scan logs, alert records, deployment inventories, and records of how staff reported suspicious files.	Automate exports of agent coverage and alert history, and set one owner for each evidence item.
External testing or review	Recurring or per engagement	Scope of systems tested, whether testing covers phishing and endpoint attack paths, and whether results are retested.	Agree the scope in writing, focus on high-risk systems first, and retest only the findings that were fixed.
Auditor or assessor sampling effort	Recurring at each assessment	Number of endpoints and workstations sampled, and whether the organization can produce complete records quickly.	Keep a current asset inventory and agent coverage report so samples can be pulled without manual reconstruction.

Evidence that passes and how to keep it current

Evidence for 164.308(a)(5)(ii)(B) is a set of dated records that show a malware procedure exists, is applied to real endpoints, and produces reports that someone acts on. Each artifact below needs a named owner and a refresh trigger, so the set is still accurate when an OCR audit or a customer questionnaire arrives.

Written malware procedures

The written procedure sets out how the organization guards against, detects and reports malicious software, including which tools run, who reviews their output and how staff escalate a suspected infection. Keep a version history with approval dates and the name of the security official who signed off. Review it after any change to endpoint tooling, after a material incident and at least once a year, and confirm that the version in circulation matches the one on file. Bold the approval date and owner on the cover page.

Addressable decision record

Because malicious software protection is addressable, the file must show the assessment: whether the measure is reasonable and appropriate, and, if not, why and which equivalent alternative was adopted. Tie the decision to the risk analysis entry that drove it, and date it. Revisit the record when the risk analysis changes, when a new endpoint class is added or when a control is removed, so the reasoning does not drift from the systems actually in use.

Endpoint coverage reports

A coverage report compares the asset inventory with the hosts where detection and query agents actually report. Gaps usually sit in laptops that rarely reconnect, servers added outside change control and cloud workloads. Export the report on a fixed schedule, reconcile unreported hosts against the inventory owner, and record each exception with a closure date. The owner signs off on the export, so an auditor can see who checked coverage and when.

Detection rule and configuration exports

Export the active query packs, detection rules and decoder settings from the monitoring platform, with their version tags and the change ticket that introduced each one. Tools such as osquery and Wazuh keep rules in files that can be versioned in source control, which makes diffs easy to show. Re-export after every rule change and at a fixed interval, and confirm that the exported set matches what is running.

Alert and finding samples with triage notes

Keep a representative sample of malware-related alerts and findings, each with the analyst's triage note, the disposition (false positive, contained, escalated) and the time to triage. Samples show that detection produces work that someone completes. Pull them from the alert store on a regular cadence, not only after an incident, and name the analyst responsible for each triage decision so the trail is traceable.

Reporting and incident tickets

Each suspected infection should have a ticket that records the detection source, containment steps, eradication, recovery and any reporting decision. Link tickets to the detection record and the affected asset. Review open tickets monthly under the security official, and reconcile them against the incident log required by the security incident procedures standard. Closed tickets without a root cause or lessons-learned entry are a common gap to check.

Training materials with acknowledgment records

Keep the current malware awareness content, such as phishing examples, macro warnings and the reporting path, with its version date and the audience it was delivered to. Attendance logs and signed acknowledgments show that the workforce received it. Update the material after an incident or a new threat notice, and record which staff completed the refresher and which were chased. Assign training content to a named owner, usually the security official or a delegate.

Who owns malware protection and who can help

The covered entity or business associate owns the malware protection procedures under 164.308(a)(5)(ii)(B) and every decision behind them. The security official, working with IT leadership, decides which protections are reasonable and appropriate based on the risk analysis, records why any addressable measure is set aside, and identifies the equivalent measure that replaces it. Staff remain accountable for how they handle email, downloads and removable media.

Decisions and documentation: Choosing which malware protections apply, recording the reasoning, and keeping it current when systems or threats change.
Workforce training: Teaching staff to recognize phishing, suspicious attachments and unexpected prompts, to report them quickly, and to keep records of who was trained and when.
Daily operations: Reviewing endpoint alerts, applying patches and handling triage. This work is often the first part that managed providers take on, but the organization should still be able to explain how alerts are reviewed.
Vendor oversight: Holding business associate agreements with any managed provider that can reach systems holding ePHI, and reviewing the reports that provider delivers.

Check that a named owner can explain each protection, its alert path, and the date of its last test without relying on the vendor's explanation.

Questions buyers ask about malware protection under HIPAA

How much effort does malware protection under HIPAA take for a small practice compared with a hospital?

For a small practice, effort is mostly about choosing a sensible endpoint protection setup, keeping it updated, and writing short procedures that staff can follow. For a hospital, effort grows with the number of endpoints, clinical devices that cannot run standard agents, network segments, and third-party connections. The main drivers are the size and variety of the environment, how much ePHI moves across systems, and what the risk analysis identifies. Nothing in the rule sets a dollar figure or hour count, so ask any provider to base its estimate on a written scope of your actual assets.

Can an organization meet the malware protection specification without outside help?

Yes, the rule does not require an outside firm. A covered entity or business associate can write the procedures, deploy its own tools, and document its decisions with internal staff. Outside help is most useful where internal teams lack time or skills for technical configuration, log review, or evidence collection. Whichever route you choose, the security official remains accountable for the program, and the decisions on whether each measure is reasonable and appropriate must be documented by your organization.

How long does it take to put malware protection procedures in place?

The timeline depends on how much of the environment is already covered by managed endpoint protection, how many systems need new agents, and how quickly exceptions for legacy or clinical devices can be resolved. Procedures and staff guidance can often be drafted quickly, while technical rollout across a large fleet takes longer. Ask any implementation partner for a timeline tied to a written scope, with milestones for discovery, deployment, testing and documentation. No duration is set by the rule itself.

What does the work need from our internal team?

Expect to need named owners from IT or security operations, someone who can approve changes to endpoints and servers, and a staff member who can deliver awareness content and track participation. Clinical engineering or biomedical teams are needed for devices that cannot run standard agents. Legal or compliance staff should review the written procedures. Your team also needs access to the risk analysis, asset inventory and current backup and patching records so that the procedures reflect real conditions.

Does an open-source security stack count as HIPAA compliance?

No tool counts as compliance by itself. The Security Rule asks for procedures for guarding against, detecting and reporting malicious software, so an open-source stack such as Wazuh, osquery, Velociraptor or OpenSearch Security Analytics can provide technical detection, telemetry and alerting that supports those procedures. Your organization still needs written procedures, documented decisions, alert handling records, and evidence that staff act on findings. Confirm each tool's licensing and support terms with its vendor before you rely on it in production.

Does security awareness training alone satisfy the malware protection specification?

No. Training is one half of the specification. The rule covers both the technical measures that guard against and detect malicious software and the procedures that teach workforce members to spot and report it. Training without technical controls leaves detection gaps, and technical controls without staff reporting paths leave incidents unnoticed. Your documentation should show the training content, who completed it, how reporting works, and how reports feed into incident response.

Can a partner certify that we are HIPAA compliant?

No. HHS states that no Security Rule standard requires certification, and HHS does not endorse or recognize private certifications. A partner such as DeployOpen can plan, implement and document the safeguards and prepare evidence for assessment, but only your organization owns its compliance posture. Any third-party assessment reflects the scope and date it covers, and it does not prevent OCR from later finding a violation. Ask any provider to state clearly what its work does and does not demonstrate.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source tooling that supports malware protection procedures for 164.308(a)(5)(ii)(B) in your own infrastructure. We prepare the systems and evidence; your organization owns the procedures, the risk analysis decision and the Security Rule program, and any formal assessment comes from an independent assessor.

How we scope

Start with your risk analysis and a written decision on whether malware protection procedures are reasonable and appropriate for your ePHI systems.
Define which endpoints, servers and cloud workloads are in scope, and which are excluded with documented reasons.
Agree deliverables, responsibilities and timelines in writing before work begins, since engagements are fixed-scope.

How we build

Deploy detection and query tooling such as osquery and Wazuh inside your environment, with configuration you can review and version.
Write detection rules and alert routing so malicious software events reach a named person who can act on them.
Test the procedures in your environment, including a simulated detection and reporting exercise, and record the results.

How we hand over

Deliver written procedures for guarding against, detecting and reporting malicious software, aligned to your staff training content.
Provide configuration records, alert logs, test results and an inventory of covered systems as evidence for an assessor.
Document any equivalent alternative measure and the reasoning behind it, so the addressable decision is traceable.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review rule and tool updates on a schedule you agree, and record changes to the procedures and evidence.
Confirm with your assessor and legal counsel which evidence they will accept before the engagement closes.