How an open source SIEM supports HIPAA audit controls
A covered entity or business associate whose systems create, receive, maintain or transmit ePHI must meet the audit controls standard in 45 CFR 164.312(b), which requires hardware, software or procedural mechanisms that record and examine activity in those systems. A self-hosted SIEM such as Wazuh, Graylog or a Security Onion deployment can supply the recording and examination mechanisms: it collects logs from ePHI systems, normalizes them, correlates events and stores them for search. The SIEM does not perform the compliance obligation on its own. The entity still owns the review procedures, the activity review policy, the standard operating procedures and the evidence that the review happened. The standard itself is required (R) in Appendix A to Subpart C, and so is the activity review specification in 45 CFR 164.308(a)(1)(ii)(D), which calls for regular review of audit logs, access reports and security incident tracking reports.
Start by deciding which systems fall within scope: EHR, identity provider, file shares holding ePHI, databases and the remote access path. For each, list the events to record, such as successful and failed log-ins, which 45 CFR 164.308(a)(5)(ii)(C) expects to be monitored and discrepancies reported. Then assign a named reviewer, a review frequency and a documented escalation path, and confirm that the SIEM retains the records long enough to support the review cycle your policy sets. Ask your SIEM partner to show how each review run is recorded, since that record is the artifact an auditor will sample.
HHS does not certify HIPAA compliance. Its 2003 FAQ states that no Security Rule standard requires certification and that HHS does not endorse or recognize private certifications, so no SIEM vendor or implementation partner can supply a HIPAA certificate for the deployment. The audit controls standard is also framed within the Security Rule's general approach, where addressable specifications require a documented assessment. Audit controls are required, so there is no alternative to document here, but the surrounding choices (sampling depth, review tooling and alert thresholds) should be recorded with their rationale. Confirm current status of the proposed Security Rule revision (90 FR 898) with counsel, because it could change expectations for activity review.
Mapping HIPAA audit and log-in requirements to SIEM functions
This table maps the HIPAA Security Rule audit controls standard, the activity review specification and the log-in monitoring specification to what a self-hosted SIEM must collect, correlate, alert on and retain, with Wazuh and Graylog configuration notes. Read each row as a requirement, then as the evidence an assessor will ask to see. The main takeaway is that the regulation sets the outcome, while the review process and its records are what usually decide whether an audit goes well.
| Requirement | What the SIEM must do | Configuration in Wazuh or Graylog | Evidence to keep |
|---|---|---|---|
| Audit controls (45 CFR 164.312(b)) | Record and examine activity in every system that creates, receives, stores or transmits ePHI | Deploy Wazuh agents on ePHI hosts and enable log collection for EHR, database and application logs; use syslog inputs in Graylog for network and appliance sources | Asset inventory of ePHI systems, log source list and agent coverage reports |
| Activity review (45 CFR 164.308(a)(1)(ii)(D)) | Regularly review audit logs, access reports and security incident tracking records, with a documented cadence | Build Wazuh dashboard views or Graylog saved searches and streams for ePHI access; schedule recurring review exports | Signed review logs showing date, reviewer, findings and follow-up tickets |
| Log-in monitoring (45 CFR 164.308(a)(5)(ii)(C)) | Monitor log-in attempts and report discrepancies such as repeated failures, off-hours access or unknown accounts | Use Wazuh authentication rules for failed and successful logins; in Graylog, create event definitions that alert on failure thresholds per account | Alert samples with triage notes and the discrepancy reports sent to the security official |
| Correlation and alerting | Link log-ins, record access and privilege changes to flag unusual patterns on ePHI systems | Wazuh rules and decoders for correlation; Graylog event definitions and streams routed to email, Slack or PagerDuty | Tuned rule list with change history and test results |
| Retention and protection of audit records | Keep audit records long enough to support investigations and enforcement reviews, and protect them from alteration | Set Wazuh indexer and Graylog index retention; restrict edit rights and forward copies to a separate store | Written retention schedule, access list for the SIEM and integrity checks |
| Log content and PHI exposure | Avoid writing patient identifiers into logs or limit who can search them | Use Wazuh decoders and Graylog pipeline rules to mask or drop fields; restrict search roles by stream | Field mapping document and role-based access reports |
| NIST SP 800-66 Rev. 2 tracking scope and tool selection | Decide which activities are tracked or audited and which tools perform the auditing and review | Write the tracked-event list per system before deployment; record why each Wazuh or Graylog feature was chosen | Tracked-activity matrix and tool selection memo |
| NIST SP 800-66 Rev. 2 policy and SOPs | Define the activity review policy, review procedures and the implementation steps for the process | Map each SOP step to a dashboard, alert or ticket in the SIEM so the process can be traced | Approved policy, SOPs and training records for reviewers |
| Addressable specifications | Document the reasoning for any addressable specification not implemented and any equivalent alternative | Record decisions for optional features, such as log forwarding or masking, in the risk file | Assessment memo for each addressable item |
Which systems that hold ePHI must feed the SIEM
The first decision is to define the inventory of systems that create, receive, store or transmit ePHI, because 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use ePHI. Start from data flows rather than from the list of applications the IT team already monitors. Walk each flow from the EHR and its interfaces, the identity provider that authenticates clinicians and staff, file shares holding scanned records or exports, database servers behind the EHR and reporting tools, VPN concentrators used for remote access, and the endpoints where staff open patient records. Each system on that map is a candidate log source, and the list should be signed off by the security officer and the system owners. Confirm with each owner which events the application writes (successful and failed logins, record views, exports and privilege changes) and whether those events are retained locally before anything leaves the host.
Next, decide how each source reaches the SIEM. Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so endpoints, Linux database hosts and Windows servers can report file integrity, login events and inventory directly. Devices that cannot run an agent, such as VPN appliances, network firewalls and some EHR or medical device components, can be covered through agentless monitoring, which Wazuh supports via syslog collection and periodic API probing. Agentless sources usually give you authentication and configuration events but less host-level detail, so record the gap per system. Confirm with the vendor whether the device can export audit logs at all, what format it uses, and whether the vendor's support terms allow an agent to be installed. Treat any system without a verified log path as an open audit finding, not a silent omission.
Which open source platforms fit HIPAA audit controls
The HIPAA audit controls standard requires mechanisms that record and examine activity in systems holding ePHI, so the platform you choose must collect, store and review those records under your control. The platforms below differ in license terms, log-in and network visibility, and the backend services you must run beside them.
Wazuh as the core SIEM
Wazuh combines agents on endpoints, a server that decodes and correlates events, an indexer that stores alerts and a dashboard. Its core repository is GPL-2.0, which keeps the source open for procurement review without a per-user fee. Its dashboard includes prebuilt views for HIPAA, which can help map alerts to the review you must document. Check that agents can run on every system holding ePHI, including any that cannot host an agent and need syslog collection instead.
Wazuh offline installation
Some clinical and records networks have no internet route, so the install and update path matters as much as the detection content. Wazuh documents an offline installation guide, and vulnerability detection can use an offline repository in place of its online threat intelligence platform. Confirm with your partner how rule updates, agent upgrades and vulnerability data reach the isolated network, and who records each transfer for your audit file.
Graylog Open for log retention
Graylog Open ingests logs over syslog, GELF and Beats, then routes them through streams and processing pipelines. Index rotation and retention control how long audit records stay searchable, which supports the review and retrieval your policy sets. Event definitions drive alerts for failed log-ins and other discrepancies. Graylog Open is licensed under SSPL-1.0, which is not OSI-approved, so have counsel review that license before procurement approves it.
Graylog backend dependencies
A Graylog deployment runs Graylog server nodes, MongoDB for configuration and metadata, and either Graylog Data Node or self-managed OpenSearch for log storage. Each component needs its own patching, backup and access controls, and each one that stores log content falls inside your HIPAA risk analysis. The compatibility matrix limits which MongoDB and OpenSearch versions work with each Graylog release, so confirm the pairing before you build.
Security Onion for network visibility
Security Onion bundles Suricata for intrusion detection, Zeek for network analysis, osquery and the Elastic stack. Network sensors show traffic to and from systems holding ePHI, which supplements host logs when an intrusion goes unlogged on the endpoint. Its Elastic License 2.0 limits how you may offer the product as a managed service, so have counsel confirm the terms fit your use. Plan sensor placement with your network team before the review.
Keycloak or authentik log-in feeds
Monitoring log-in attempts is easier when the identity provider sends authentication events to the SIEM. Keycloak (Apache-2.0) and authentik (MIT, with an enterprise directory under a separate license) both record sign-in events that you can forward for review. Confirm which events each product emits, how failed and successful log-ins are separated, and that the identity provider itself holds the unique user identification your access controls depend on.
How to monitor log-in attempts and report discrepancies
Directory and single sign-on services are usually the first place a credential attack shows up, because every application that delegates authentication sends its log-in decisions there. Collect failed and successful authentication events from the identity provider and its directory federation, including the client, source address, authentication method and any step-up or multi-factor result. Failures that cluster on one account, many accounts from one source, or a success shortly after a run of failures from an unfamiliar location deserve review. Set thresholds per account and per source, tune them against a baseline period, and record the tuning decision.
- Failed-attempt bursts: alert when one account exceeds a threshold of failures inside a short window, and separately when one source address fails against many accounts.
- Success after failure: flag a successful log-in that follows repeated failures, especially from a new device or geography.
- Lockout and reset events: route account lockouts and password resets to the security queue, since they often precede an access change.
- Service and disabled accounts: alert on any attempt against disabled, expired or service accounts.
- Discrepancy record: each review outcome should name the reviewer, the disposition and any user or system notified.
Confirm the exact event names, field names and any built-in brute-force detection with the vendor documentation for Keycloak and the Wazuh single sign-on documentation before writing rules.
Applications that hold ePHI often keep their own authentication logs, and some do not authenticate through the central directory at all. Clinical, scheduling, patient portal and reporting applications can each log failures differently, with different field names and levels of detail. Inventory every application that can reach ePHI, confirm whether it logs log-in attempts, and decide how each one reaches the SIEM. Where an application logs little, the gap itself is a finding to document and address.
- Log-in inventory: list each ePHI application, its log-in method, its log destination and its log format.
- Role and privilege changes: alert when an account gains clinical or export privileges shortly before unusual activity.
- Unusual access volume: flag large record views or exports by one user in a short period, measured against that role's normal pattern.
- Log-in from unexpected context: review log-ins outside scheduled shifts or from networks that the application does not normally see.
- Logging gaps: record applications that cannot send log-in events and the compensating control, such as proxy logging, that you have chosen.
Because the standard is addressable, document why any application is excluded and what equivalent measure applies. Ask the application owner which events they can export and how long the application keeps them locally.
Administrative accounts, vendor support sessions and remote access paths carry the highest impact when misused, so they warrant the strictest thresholds and the fastest review. Collect log-ins to servers, databases, network devices, VPN concentrators and remote support tools, and tie each event to a named person rather than a shared account. Where a privileged access tool records sessions, link its session records to the SIEM alerts so reviewers can move from an alert to the activity.
- Any privileged log-in: review every administrative authentication against a change or ticket record, not just failures.
- Off-hours and new-source access: alert on administrative or vendor log-ins outside approved windows or from unregistered addresses.
- Shared or generic accounts: alert on any use of an account that should not be shared, since it defeats unique user identification.
- VPN and remote session failures: track repeated failures and successful connections from new locations.
- Escalation path: define who receives each alert class, the response time expected by policy and who signs the discrepancy record.
Confirm with each platform owner which authentication events and session identifiers their systems emit before setting thresholds, since these sources vary widely in what they log.
The standard asks for procedures for monitoring log-in attempts and reporting discrepancies, so the reporting path matters as much as the detection. A discrepancy is any log-in event that your procedure says must be investigated and recorded, including alerts that were reviewed and closed as benign. Define what counts as a discrepancy, who triages it, how it is escalated to incident handling and how the outcome is recorded. Pair this with the regular review required under 164.308(a)(1)(ii)(D), so the same records serve both purposes.
- Written criteria: state which events and thresholds create a discrepancy record and who may close one.
- Triage and escalation: assign a first reviewer, an escalation contact and a route to the privacy or compliance lead where ePHI may be involved.
- Retained records: keep the alert, the analysis, the decision and any notification together and protected from change.
- Periodic summary: report trends by source to the security governance forum on a set cycle.
- Breach assessment link: where a log-in discrepancy may have exposed ePHI, route it into the breach assessment process rather than closing it at triage.
Ask your counsel and compliance lead to confirm the escalation and notification timelines that apply to your organization, since these depend on your agreements and state requirements.
Why keeping ePHI-bearing logs in-house avoids another business associate
Logs that contain ePHI are themselves regulated, so the place where they are stored and processed matters as much as the SIEM's detection logic. The HIPAA Security Rule applies to electronic protected health information wherever it is created, received, maintained or transmitted, and a log that records a patient identifier, a record number or a clinical user's session can carry ePHI. If a hosted SIEM or log service stores or processes those records on behalf of a covered entity, the vendor may be acting as a business associate. That relationship would normally require a business associate agreement before any log leaves your environment. Whether a given vendor's role triggers that obligation is a legal question, so confirm the classification with your privacy counsel rather than relying on a vendor's marketing claims.
A self-hosted deployment keeps the Wazuh indexer, the Wazuh server, the dashboard or Graylog nodes and their OpenSearch or Data Node storage inside your own cloud account, data center or network segment. That does not remove your obligations, but it removes one external party from the chain of custody for audit records. Before go-live, inventory the fields your agents, decoders and syslog inputs actually emit: usernames, source addresses, patient or account identifiers in URLs, query strings and application messages. Redact or hash fields that are not needed for activity review, restrict dashboard roles so that only staff with a need to see ePHI-adjacent events can search them, and document the decision. Ask counsel whether any remaining identifiers still make the logs ePHI and whether your own agreements with support partners cover administrative access to the platform.
Evidence auditors and OCR investigators ask for
This table lists the records an auditor or OCR investigator is likely to request for the audit controls standard and log-in monitoring, and the component that produces each one. Read it as a checklist to design retention, access and ticketing before an assessment starts. The main takeaway is that OCR reviews Security Rule compliance and no HIPAA certificate is issued, so the evidence set has to be complete and consistent over time.
| Evidence record | Producing component | What the reader should confirm |
|---|---|---|
| Audit policy and activity review procedures | Documented policy and standard operating procedures, referenced to 45 CFR 164.312(b) and 164.308(a)(1)(ii)(D) | Named reviewer, review frequency and sign-off history are written down and dated |
| Tracked activity scope | Asset inventory and agent coverage list from the Wazuh server and agent registry | Every system that contains or uses ePHI has an agent or documented alternative such as syslog |
| SIEM configuration and rule set | Wazuh server rule and decoder files, managed configuration, and Graylog event definitions and streams | Change history for rules and configuration is kept and can be shown for the audit period |
| Retained audit logs | Wazuh indexer alert and archive indices, or Graylog index sets with retention settings | Retention period matches the entity's own policy and the indices can be restored and searched on request |
| Activity review records | Dashboard exports, saved searches and signed review reports from Wazuh dashboards or Graylog dashboards | Each review shows the date, scope, findings and the person who performed it |
| Log-in monitoring alerts and discrepancy tickets | Alert records from the SIEM forwarded to the ticketing system, linked to the originating event | Tickets show investigation, outcome and any corrective action, not only the alert |
| Access to the logs themselves | Role-based access settings in the dashboard, plus access logs for the SIEM console | Only authorized staff can view logs that may contain ePHI, and those views are logged |
| Integrity and time source evidence | Indexer storage controls and host time synchronization settings | Confirm with your own auditor how log integrity and timestamps will be demonstrated |
What a SIEM alone does not satisfy
A self-hosted SIEM produces the records that the audit controls standard requires, but the Security Rule also expects written decisions, trained people and tested procedures around those records. The cards below list the gaps the entity must close itself, because no log platform can close them.
Named log review procedures
The information system activity review specification requires procedures to regularly review audit logs, access reports and security incident tracking reports. Name the role that reviews each log source, the frequency, and the evidence of each review, such as signed daily summaries or closed alert tickets. Confirm that the SIEM can export the access reports the review uses, and that the review is recorded somewhere an auditor can sample.
Risk analysis and addressable decisions
Each addressable implementation specification needs a documented assessment of whether it is reasonable and appropriate. If the entity decides a measure is not reasonable, it must record why and adopt an equivalent alternative. Record the decision for each log source, retention period and monitoring scope, including why a source such as a medical device log is left out of the SIEM and what compensating control applies.
Policies and standard operating procedures
NIST SP 800-66 Rev. 2 treats the audit and activity review policy and its standard operating procedures as separate key activities. Someone inside the organization must decide which events are tracked, who may search the logs, how alerts are triaged, and how discrepancies in log-in attempts are reported. Authoring these documents is not a task the SIEM vendor or implementation partner can complete on the entity's behalf, although a partner can draft them for review.
Workforce training on log-in monitoring
The log-in monitoring specification under the security awareness standard calls for procedures that monitor log-in attempts and report discrepancies. Workforce members who receive those reports, and the users whose failed log-ins are watched, need training on what to report and how. Keep attendance records and training content, and confirm that the SIEM dashboards show the log-in views the training refers to.
Entity incident response process
A SIEM generates alerts, but the Security Rule's security incident procedures and the entity's own response plan decide who acts on them, how incidents are escalated, and how the entity documents containment and reporting. Define the escalation path from a SIEM alert to a named incident commander, the decision points for notifying leadership, and the records kept for each incident. Test the plan with a tabletop exercise before an incident forces the decisions.
Pending Security Rule revision
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), and the latest Unified Agenda projects final action for July 2027. Until a final rule is published, the current text governs, but the proposal signals where regulators expect audit and monitoring controls to go. Track the rulemaking, and confirm with counsel which proposed changes would affect log retention, review frequency or documentation before designing the SIEM around them.
Common questions about HIPAA SIEM implementation
What drives the cost of a self-hosted HIPAA SIEM?
The main drivers are log volume, retention period, the number of log sources that need onboarding and parsing, and how much detection and review work the entity wants built in. Software licensing is only part of the bill. Under a build approach, the entity pays for infrastructure, staff time and detection tuning. Under a partner approach, it pays a fixed-scope implementation fee plus any retainer for ongoing support. Ask every quote to separate one-time work (architecture, deployment, parser build, dashboards, runbooks) from recurring items (hosting, storage growth, upgrades, rule updates, support). Storage is sized from daily ingest and retention, so ask the partner to show that calculation. Wazuh's core is GPL-2.0 and Graylog Open is free, but Graylog's paid editions add a published per-year price, which the Graylog pricing page lists as starting at 15,000 US dollars per year for Enterprise and 18,000 US dollars per year for Security, with a minimum of 10 GB per day or 100 Graylog Compute Units.
How long does it take to get a usable HIPAA audit trail?
The duration depends on how many systems hold or use ePHI, how many of them can send logs without custom work, and how quickly the entity can name the events it must review. No single timeline applies to every environment, so ask for a written schedule tied to the scope. A usable audit trail usually needs four things in place: agents or syslog forwarding from in-scope systems, parsed and searchable events, a defined set of log-in and access alerts, and a documented review procedure. The review procedure matters as much as the tooling, because 45 CFR 164.308(a)(1)(ii)(D) requires procedures to regularly review audit logs, access reports and security incident tracking reports. Ask the partner to deliver a first working set of sources early, then add the harder ones such as EHR audit tables or medical device logs in later phases.
What does the work need from our own staff?
Your staff must own decisions that no tool can make for you: which systems hold ePHI, which events count as reviewable activity, who reviews the alerts, how discrepancies get reported, and how long records are kept. The compliance lead owns the policy, the security or IT lead owns the source list and access to the SIEM, and a named reviewer owns the recurring review. Engineers must provide access to hosts, EHR audit configuration, and network segments, and they need to sign off on agent deployment on clinical systems. Under the addressable specification logic in 45 CFR 164.306(d), each decision to omit a control must be documented with a reason and an equivalent alternative, so your staff must also keep that record. Confirm these roles in the statement of work before work starts.
Can a small practice run a self-hosted SIEM for HIPAA?
A small practice can run a self-hosted SIEM only if it has an IT owner, a reviewer who will actually perform the review, and a plan for patching and backups. Many small practices have few systems that hold ePHI, which keeps the source list short, but the work of reviewing records and keeping the platform current does not shrink with the number of users. Wazuh offers an all-in-one installation, a prebuilt OVA and Docker options, and its dashboard includes a prebuilt HIPAA compliance view, which can reduce early setup effort. Where no in-house engineer exists, a partner can operate the platform under a retainer, or the practice can choose a managed service, but a managed service means the logs leave your environment, so review the business associate question first. Ask any partner to state who patches the platform and who answers the review questions.
Is Wazuh or Graylog the better fit for HIPAA audit controls?
Wazuh usually fits better when the entity needs host-level monitoring with agents on endpoints and servers, file integrity, and prebuilt compliance views. Graylog usually fits better when the main job is centralized log search, syslog and GELF ingestion from many applications, and event definitions for alerting. Both can meet the audit controls standard in principle, because the standard requires mechanisms that record and examine activity, not a particular product. The licensing differs: Wazuh's core is licensed under GPL version 2, while Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license. Compare the operating model as well. Wazuh's server can run as a cluster and manages agent configuration remotely, while Graylog runs server nodes with MongoDB and a Data Node or self-managed OpenSearch. Pilot both against your real log sources before choosing.
Does a SIEM make our organization HIPAA compliant?
No. A SIEM supplies mechanisms and records that support the audit controls standard and the information system activity review specification, but compliance depends on the whole Security Rule program, including the policies, procedures, training and risk analysis your organization maintains. HHS states that no Security Rule standard requires certification and that it does not endorse or recognize private certifications, so no tool or vendor can grant HIPAA compliance. What a well-built SIEM provides is evidence: retained logs, documented review, alert records and a clear link to the procedures you follow. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent assessors and HHS decide compliance.
What penalties apply if HIPAA audit logging fails?
Penalties under the HIPAA Rules are assessed per violation and adjusted for inflation each year. For penalties assessed on or after January 28, 2026, 45 CFR 102.3 sets the inflation-adjusted civil money penalty for violations on or after February 18, 2009 at a range from 145 US dollars per violation, where the entity had no knowledge, up to 2,190,294 US dollars per violation for uncorrected willful neglect, with a calendar-year cap of 2,190,294 US dollars. The actual amount depends on culpability, the timing of correction and other factors set out in the rule, so treat these figures as the ceiling and range rather than a prediction. The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits, and its 2024 to 2025 audits review 50 covered entities and business associates on the provisions most relevant to hacking and ransomware. Ask counsel to review your exposure against the current penalty table.
Why keep ePHI-bearing logs inside our own environment?
Logs from EHR systems, access reports and authentication events often contain patient identifiers, which makes them ePHI. If a hosted SIEM or log service stores or processes those logs for you, that provider usually becomes a business associate, which brings its own agreement, due diligence and breach obligations. Self-hosting inside your own cloud account or data center keeps the logs under your existing controls and limits the number of parties that touch them. This does not remove your obligations. You still need access control on the SIEM, encryption in transit and at rest, and retention rules, and any support partner that can reach the logs needs a documented relationship. Confirm with counsel whether any partner or hosting provider requires a business associate agreement under 45 CFR 164.308 before granting access.
How a HIPAA SIEM implementation is phased
The sequence moves from deciding what must be logged and reviewed to a running, documented activity review process that an assessor can examine. Each phase produces a written artifact or a verifiable check, so the audit controls standard is met by design rather than by after-the-fact collection.
Scope the ePHI systems and tracked activities
The covered entity or business associate, with its implementation partner, lists every system that creates, receives, stores or transmits ePHI, including EHR, identity, VPN, file shares and remote access tools. For each system the team decides which events to record, such as log-ins, record access, privilege changes and configuration changes, and documents the reason. Done means a scoped asset inventory and a log source register signed by the security officer, which is the input the audit controls standard requires.
Select tools against the scoped requirements
With the scope fixed, the team chooses the collection, storage, search and alerting components, such as Wazuh for endpoint and log analysis or Graylog with OpenSearch for search and retention, and confirms each candidate's license terms, supported deployment model and offline needs. The partner documents why each tool fits the scope and where the fit is weaker. Done means a written tool decision record that names the components and the open questions still to close with each vendor.
Write the activity review policy and procedures
The organization writes the information system activity review policy, defining who reviews which logs, how often, what counts as a reportable discrepancy and how log-in monitoring findings are escalated. Standard operating procedures cover triage, incident records and how reviews are signed off. Because the review specification is required, the policy must exist before the SIEM goes live. Done means approved policy and SOP documents with named owners and a review date.
Deploy the platform inside the ePHI boundary
The partner installs the SIEM in the organization's own cloud account, data center or network segment, configures access controls on the platform itself, enables encryption in transit and at rest, and restricts who can read or change log data. Logs containing ePHI never leave that boundary, so no external log service becomes a new business associate for this data. Done means a hardened environment with a configuration baseline and an access list that matches the policy.
Onboard log sources and validate event coverage
Agents and forwarders are deployed to endpoints and servers, and syslog or API connectors are configured for the systems in the register, including agentless devices. The team checks that log-in attempts, record access and administrative actions from each source are parsed and searchable, and tests that a known event produces the expected record. Gaps found here are logged and assigned. Done means a source-by-source coverage report showing which tracked events arrive, with exceptions listed.
Configure alerts, dashboards and compliance views
Detection rules and thresholds are set for failed and unusual log-in attempts, access to sensitive records and changes to audit logging itself, and alerts are routed to the people named in the SOP. Dashboards are built for the reviewer's routine, and prebuilt regulatory views such as the HIPAA dashboard in Wazuh can be used as a starting point and checked against the organization's own mapping. Done means tested alert paths with recorded test results and a dashboard set the reviewer has accepted.
Run the first review cycle and document it
The designated reviewer performs the procedure as written, reviewing logs, access reports and security incident records for the period, recording findings, discrepancies and actions taken. The partner observes the first cycle to confirm the SOP works in practice and updates it where steps were unclear. Done means completed and signed review records for the period, plus a list of procedure changes.
Collect evidence and set the ongoing review rhythm
The team assembles the evidence an assessor or OCR investigator would ask for: the scope and asset register, the policy and SOPs, source coverage reports, alert test records, review logs and the record of how addressable specifications were assessed. Ongoing upkeep, upgrades and tuning are agreed as a retainer or internal ownership. Done means an evidence index that maps each artifact to the audit controls and activity review requirements, reviewed with the compliance lead. This preparation supports an independent assessment and does not replace it.
How DeployOpen scopes and supports a HIPAA SIEM
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so ePHI-bearing logs stay in your environment. For HIPAA audit controls, we scope the log sources, review procedures and evidence first, then build the SIEM to match them.
How we scope
- We inventory systems that create, receive, maintain or transmit ePHI and agree which ones feed the SIEM.
- We document which activity is tracked, the log-in monitoring rules and who reviews the output.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen platform, such as Wazuh or Graylog, inside your infrastructure with log sources onboarded and parsed.
- We configure alerting for failed log-ins and access anomalies, and test that alerts reach the reviewers you name.
- We set retention and access controls on the logs themselves, then test them against the scope before handover.
How we hand over
- We write the activity review procedures and standard operating procedures that staff will follow day to day.
- We document configuration, data flows, retention settings and the evidence each control produces for your assessors.
- We train your operators and deliver runbooks for upgrades, backups and restores so the team can run the system.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- We can handle platform upgrades and patch releases, with testing in a staging environment before production.
- Security testing of the SIEM and its connected systems can be scheduled as part of the retainer.
