Wazuh for HIPAA audit controls

The audit controls standard in 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use ePHI, but it does not list the events to capture. That leaves scope to the covered entity or business associate. Start from your own risk analysis: identify every system where ePHI is created, received, maintained or transmitted, then decide which activity on each system would tell you whether someone accessed, changed or moved that data improperly. Write that decision down before you configure anything in Wazuh, because the event list is what the later review procedures will examine.

Four categories cover most of the decisions. The first is endpoints and servers that store or process ePHI, including application servers, database hosts, file shares, backup targets and clinician workstations. The second is authentication and privileged access activity: successful and failed logins, privilege elevation, account creation and role changes, and use of emergency access accounts. The third is changes to security configuration, such as audit policy changes, SSH or remote access settings, firewall rules on the host, and changes to the Wazuh agent configuration itself. The fourth is firewalls, VPN concentrators and other network devices that reach your environment, which usually send their records through syslog.

Wazuh collects this data in two ways. Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and they forward host records to the Wazuh server. Devices that cannot run an agent, such as many firewalls, can be monitored through syslog collection and periodic API probing. Coverage depends entirely on onboarding. A system that is not enrolled as an agent or sending syslog to the server produces no records, so the review procedure cannot examine its activity. Map each system in your ePHI inventory to a collection method and an owner, and treat any system without one as an open gap.

For each source, document the event types you expect to see, the reason you need them, and the decision that depends on them. Keep this as a table your assessors can read. Then confirm which log sources your Wazuh version decodes out of the box. The current release line is 4.14, and decoder coverage can differ between releases and between vendor products, so check the decoder and rule documentation for the exact version you deploy. Anything not decoded by default will need a custom decoder, a tested rule and a note in the event list, or it will not appear as a usable record.

The information system activity review specification requires procedures to regularly review records of system activity, such as audit logs, access reports and security incident tracking reports. It is a required implementation specification, so an entity with ePHI systems must have it in place whatever tools it uses. Wazuh produces the alerts, stored events and dashboard views that a reviewer works from, but it does not write the procedure. The written procedure is the entity's own document, and it is the first thing an assessor will ask to see. It should state who reviews, how often, which views and alerts are checked, how findings move to closure, and how each review is recorded.

Start with the reviewer and the frequency, because the rule leaves both to the entity. Name the role responsible for each review, and where your staff allow it, choose someone who does not administer the systems whose activity they are reviewing. Confirm that the reviewer's Wazuh dashboard permissions match that role, so they can see the relevant alerts without holding administrative rights. Set a review frequency based on your own risk analysis of the systems holding ePHI, then document the reason for that frequency. Assessors will compare the schedule you wrote with the reviews you actually performed, so choose a cadence your team can keep for the long term.

Define the views and alerts that each review covers. The Wazuh dashboard includes a prebuilt HIPAA view, which is a sound starting point, but it should be adapted to your environment rather than accepted unchanged. Typical review items for ePHI systems include authentication successes and failures, activity by privileged accounts, account creation and permission changes, agent disconnections from monitored hosts, and file integrity events on directories that hold ePHI, which also supports the integrity requirement in 164.312(c)(1). Confirm in your own version which rule groups are enabled and which alerts reach the dashboard, and write the list into the procedure with the query or view name for each item.

The procedure must also say what happens after a reviewer finds something. Define severity levels, the criteria for escalating an event to the security incident process, the people to notify at each level, and the system used to track each finding from detection through investigation to closure. Record any decision to tune or suppress a rule, along with who approved it and why, so that a closed alert does not disappear from the record. Each review should leave evidence: the date, the reviewer, the scope covered, the views checked, the findings, the actions taken and the sign-off. A review that is not performed is a gap even when Wazuh is collecting and alerting correctly, so keep a sample of completed review records ready for an assessor.

For an addressable implementation specification, HIPAA does not let an entity skip the control without a record. Under 45 CFR 164.306(d), the entity must assess whether the specification is reasonable and appropriate in its environment. If it is not, the entity documents the reason and implements an equivalent alternative measure, provided that alternative is reasonable and appropriate. Appendix A to Subpart C lists seven implementation specifications for the technical safeguards in 164.312. Unique user identification and emergency access procedure are required. Automatic logoff and both encryption specifications are addressable, so those are the places where a Wazuh deployment is most likely to need a documented decision. The audit controls standard in 164.312(b) has no implementation specifications of its own, so these decisions concern the surrounding safeguards that the audit trail depends on.

Illustrative example: a small clinic runs Wazuh agents on three workstations and one server that hold ePHI. Its assessment finds that a specific feature, such as automated alerting on every dashboard login from a new network, is not reasonable for a team of four staff who already review the dashboard each morning. The clinic documents the reason, the date and the approving officer. It then implements an equivalent alternative: a weekly review of the prebuilt HIPAA view in the Wazuh dashboard, with the reviewer recording findings and follow-up in a log that the compliance lead signs. The record names the specification, the alternative, the owner and the review schedule. Auditors test whether the reasoning holds up, so the document should show the facts used to reach the decision, not only the outcome.

For Wazuh, addressable decisions usually turn on where ePHI actually moves through the stack. Four components matter: the Wazuh indexer that stores alerts, the Wazuh server that decodes and analyzes agent data, the Wazuh dashboard, and the agents on endpoints. Automatic logoff applies to dashboard sessions and any analyst console in front of it, so the decision depends on the session timeout behavior of the release you deploy. Confirm that behavior in the 4.14 line documentation before writing the record. The encryption specifications apply to agent-to-server traffic and to data stored in the indexer, so the decision depends on the transport and storage settings you configure. Also assess whether alert content itself holds ePHI, for example file paths, usernames or record identifiers captured by agents. If it does, the alert store falls inside the same analysis and must be protected accordingly.

Keep these records tied to the rule in force. HHS proposed a major Security Rule revision on 6 January 2025 (90 FR 898, RIN 0945-AA22). As of October 2026 no final rule has been published, and the latest Unified Agenda projects final action for July 2027. Until a final rule takes effect, the 164.306(d) process governs your decisions. Build the records so they can be reassessed: date each entry, record the Wazuh release and configuration each decision depends on, and set a review point linked to the rule's status. The proposal is not final, so plan for possible change to the addressable framework without rewriting current decisions in advance. HIPAA also has no certification. Your documented decisions are evidence for OCR reviews and for any independent assessor, not a certificate.