Why an open source SIEM for healthcare must treat logs as ePHI
A self-hosted SIEM for a healthcare organization must be designed as a system that holds ePHI, because the logs it collects from EHR, PACS and medical device sources show who viewed which patient record and when. HIPAA has no certification, so the question is not whether a tool is certified but whether your audit controls, activity review and access to the logs themselves can be shown to work. The HIPAA Security Rule at 45 CFR 164.312 requires covered entities and business associates to implement audit controls that record and examine activity in systems containing ePHI, along with unique user identification and person or entity authentication. Once the SIEM ingests those records, it becomes part of the ePHI boundary, and its own storage, dashboards, exports and administrator accounts fall under the same access and security expectations as the source systems.
The main candidates are Wazuh, Security Onion, Graylog Open and OpenSearch, and the right choice depends on your source mix and in-house skills. Wazuh bundles agents, a server and a dashboard with prebuilt compliance views that include HIPAA, which suits organizations that need endpoint and log coverage in one product. Security Onion fits teams focused on network security monitoring, while OpenSearch is a search and analytics layer that needs more engineering to build detection and access rules. Before you choose, confirm which EHR, PACS and device log sources you must onboard, who on your team can tune detection content and operate upgrades, and whether a partner will carry that work. Decide early where the SIEM and its backups will run, because keeping ePHI-bearing logs in-house avoids adding another business associate.
Which HIPAA and sector requirements shape the SIEM build
This table maps the HIPAA technical safeguards, the business associate contract terms and two sector facts to specific SIEM build decisions. Read each row as a requirement, what it asks for, and the design choice it forces on the logging platform. The main takeaway is that the SIEM itself holds ePHI-bearing data and must meet the same access, audit and transmission controls as the systems it watches.
| Requirement | What it asks for | SIEM build decision |
|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i), required) | Every user of a system holding ePHI has a unique identifier that is tracked | Give each SIEM analyst and service account a named identity, disable shared dashboard logins, and map Wazuh dashboard and indexer roles to individuals |
| Audit controls (45 CFR 164.312(b)) | Hardware, software and procedural mechanisms that record and examine activity in systems containing ePHI | Define log sources for EHR, identity, database and medical device systems, then confirm agent or syslog coverage for each before go-live |
| Person or entity authentication (45 CFR 164.312(d)) | Verify that a person or entity seeking access is who they claim to be | Require strong authentication for SIEM console access, and confirm whether the SIEM can federate with the workforce SSO you already run |
| Transmission security (45 CFR 164.312(e), addressable encryption specification) | Guard ePHI-bearing data sent over networks, including encryption where appropriate | Encrypt agent-to-server and syslog paths that carry log lines with patient identifiers, and document the decision if any path stays unencrypted |
| Automatic logoff and encryption at rest (45 CFR 164.312(a)(2), addressable) | Terminate idle sessions and encrypt stored ePHI where a risk assessment supports it | Set idle timeouts on the dashboard and encrypt the indexer storage that holds retained logs, since those logs can contain patient data |
| Business associate contract (45 CFR 164.314(a)(2)(i)) | Vendors handling ePHI must comply with the Security Rule, flow terms to subcontractors and report incidents | Self-hosting keeps logs in-house, so a SIEM partner may not need a business associate agreement, but confirm this with counsel for each support or remote access arrangement |
| Pending Security Rule revision (planning note) | HHS proposed a major Security Rule revision on 6 January 2025; no final rule as of October 2026, with final action projected for July 2027 | Design retention, MFA and logging controls to the current rule, and build change room into the platform so later requirements can be added without rearchitecting |
| NIS2 health sector and CNIL enforcement (EU operators) | NIS2 Annex I lists healthcare providers and certain medical device makers as high criticality; CNIL fined a hospital EUR 500,000 on 3 September 2026 for external access without VPN or MFA | For EU operators, log access by care-team need to know, enforce MFA on remote SIEM access, and keep security logs inside EU infrastructure where the data protection analysis requires it |
Which EHR, medical device and identity logs to collect first
The EHR and patient record system is usually the first source to onboard because it is where ePHI is created, viewed and changed. For activity review, the events that matter are successful and failed log-ins, record opens and searches, break-glass or emergency access, changes to patient records, report exports, and changes to user roles or access rights. Many EHR platforms write these events to an internal audit table or a vendor-hosted audit feed rather than to a local syslog, so the collection path depends on the product and the hosting model.
- Audit trail format: Confirm whether the audit trail is available as a database table, a flat file, an API or a syslog stream, and whether it records the user, patient identifier, action and timestamp.
- Break-glass events: Confirm that emergency access is logged with a reason field, so reviewers can separate it from routine access.
- Export completeness: Ask whether the export includes failed events and administrative changes, not only successful record access.
- Hosting model: If the vendor hosts the EHR, confirm what log export the contract provides and in what format and frequency.
- Clock source: Confirm that the application server uses a synchronized time source so events line up with identity logs.
Before committing to a collection design, ask the EHR vendor in writing which audit events it produces, how they are exported, and whether the export is covered by the support agreement.
Picture archiving, radiology information and laboratory information systems hold ePHI and are often accessed by clinicians, technicians and integration interfaces at the same time. Their access events matter for activity review because they show who opened studies or results and whether interface accounts are being used in unexpected ways. Interface engines and HL7 or DICOM gateways may also create their own logs, which can be as important as the application logs themselves.
- Study and result access: Collect views, downloads, exports and print events, along with the user and the study or accession identifier.
- Interface accounts: Track service accounts used by integration engines, and alert when they log in interactively.
- Gateway logs: Where an HL7 or DICOM gateway routes ePHI, collect its message logs and error logs as well as its access logs.
- Syslog or database export: Many systems offer syslog output, but some only expose audit data through database views or vendor reports. Confirm which path is supported for the version in use.
- Retention limits: Ask whether the application purges its own audit data on a schedule and whether that can be disabled or extended.
Confirm with each vendor which audit events are supported, whether syslog forwarding is included in the license, and whether the export format is documented well enough for detection rules to be written against it.
Clinical medical devices, bedside monitors, infusion systems and network equipment often cannot run an agent. Many run embedded operating systems that the manufacturer controls, and installing third-party software may void support or the regulatory clearance. For these sources, the practical path is agentless collection: syslog from network devices, and vendor-supported event forwarding or periodic polling where the device offers it. The SIEM can receive syslog from devices that cannot run agents, but the events available depend entirely on what the device generates.
- Agentless syslog: Use syslog for firewalls, switches, wireless controllers and any device that can send events. Confirm the transport (UDP, TCP or TLS) and that the device sends authentication and configuration change events.
- Device audit events: Ask the manufacturer whether the device logs user log-ins, configuration changes and firmware updates, and whether it can send them off the device.
- Vendor support boundary: Confirm in writing whether the manufacturer permits a log forwarder, syslog relay or network tap on the device or its segment.
- Network position: For monitoring that depends on traffic, plan the sensor placement with the clinical engineering team.
- Time synchronization: Confirm that devices can use a central time source, since many embedded devices drift.
Before planning device onboarding, ask the manufacturer what events the device produces, whether syslog is supported, and whether using a relay affects the support or regulatory status of the device.
Identity and remote access events are often the most useful early signals for healthcare activity review. They show who logged in to the EHR, from where, through which path, and whether multi-factor authentication was used. This matters because the regulatory record is not limited to the application: an external log-in that bypassed MFA or a VPN is a control failure in its own right. Collecting these events from the identity provider, the VPN gateway and the MFA service gives reviewers the context that application logs lack.
- Directory and SSO events: Collect successful and failed log-ins, account lockouts, password resets and group membership changes from the directory and single sign-on service.
- VPN and remote access events: Collect session start and end times, source addresses, assigned users and failed attempts from the VPN or zero trust gateway.
- MFA events: Collect enrollment, challenge outcomes and bypass or exception events, so reviewers can see whether a log-in was challenged.
- Service and vendor accounts: Track accounts used by third-party support staff and alert on their use outside approved windows.
- Vendor confirmation: Confirm the log format, whether events are pushed or must be pulled, and how long the vendor retains them natively.
Record which identity and remote access sources feed the SIEM, because these events are the evidence that access control and MFA are operating as described.
Workstations, thin clients and clinician devices are where ePHI is viewed and sometimes copied. Endpoint events matter for activity review when they show local log-ins, removable media use, print jobs, screenshots, software installation and security tool alerts. Wazuh agents can run on Linux, Windows and macOS endpoints, which covers most desktop estates, while shared or kiosk devices often need a different approach because they may not support a persistent agent.
- Agent coverage: Confirm which operating systems and images are in scope, and whether shared clinical workstations can run the agent without disrupting clinical workflows.
- Local access events: Collect Windows security events or Linux authentication logs for log-ins, privilege changes and failed attempts.
- Data movement: Where policy allows, collect removable media and print events, since these show possible copying of ePHI outside the record system.
- Shared device accounts: Ask how shared log-ins are attributed to a person, since unique user identification depends on it.
- Agent management: Confirm that the platform team can push agent configuration and upgrades without changing clinical software.
Before rolling out agents to clinical devices, confirm with the clinical engineering and application owners which endpoints can run agents and which will rely on syslog or network-based collection.
How a healthcare SIEM rollout runs from scoping to activity review
The sequence moves from defining which ePHI systems and business associates are in scope, through log sources and retention, to a self-hosted SIEM that produces the HIPAA audit controls and activity review evidence a covered entity can show.
Scope ePHI systems and business associates
Start by listing every system that creates, receives, maintains or transmits ePHI, including EHR modules, medical device gateways, identity services, file shares and any outside party that touches that data. The HIPAA Security Rule applies to covered entities and their business associates, so the scope must name both sides. Your privacy and compliance leads, with the EHR and clinical engineering owners, sign the scope document. The output is a signed scope listing in-boundary systems, data flows and the business associates whose contracts must reflect Security Rule duties. Confirm with counsel which contracts already cover incident reporting under 45 CFR 164.314 before you rely on them.
Define log sources and retention requirements
Turn the scope into a source inventory. For each system, record which events support HIPAA audit controls and information system activity review, such as user log-ins, record access, privilege changes and failed authentication, and who owns each log source. Decide retention and search speed with your privacy office, because the logs themselves may contain patient identifiers and must be held under the same controls as the records. The output is a source inventory with event types, owners, retention periods set by your policy and access roles for the logs. Confirm the retention periods against your own legal and accreditation obligations.
Deploy the platform inside the hospital or cloud boundary
Install the chosen components, such as the Wazuh indexer, server and dashboard, or an OpenSearch-based stack, inside the boundary you defined in the first step. Use the deployment method your team operates, and where the network has no internet access, use the offline installation path. Enable TLS between components and set up role-based access from day one. The output is a build record with versions, host inventory, certificate details and a tested backup of the configuration. Your implementation partner should provide the build record and confirm that no copy of ePHI-bearing logs leaves the boundary.
Onboard log sources and test parsing
Connect each source in the inventory using agents where the operating system allows it, and syslog or API collection for devices such as medical device gateways, firewalls and EHR servers that cannot run agents. For each source, confirm that fields such as user identifier, patient or record identifier, source address, action and outcome are decoded and searchable. Run test events through each parser and compare the result against an expected field map. The output is a parser test report per source, showing pass or fail for each required field and open gaps that need vendor or clinical engineering input.
Build HIPAA-mapped detections and review workflow
Write or adapt detection rules for the events the scope requires, such as repeated failed log-ins, access to records outside a care team, logins from unusual locations and disabled audit logging. Map each rule to the Security Rule audit controls and information system activity review requirement, and enable the prebuilt HIPAA view in the Wazuh dashboard where it fits your reporting. Define who reviews alerts, how often, and how each review is recorded. The output is a detection catalog with rule IDs, owners, mapping notes and tested alerts, plus a review procedure with a sample review record. Describe the mapping as your internal control evidence, not as certification, because HHS does not certify compliance.
Validate access controls on the logs themselves
Because logs can contain ePHI, test who can read, search, export and delete them. Confirm that role-based access limits users to the logs they need, that administrator actions on the SIEM are themselves logged, and that log storage cannot be altered by the people whose activity it records. Test the authentication path for analysts, including unique user identification for every account. The output is an access test record with the roles tested, the results and any remediation. Ask your partner to show these results with the tested accounts, not only the configuration files.
Hand over runbooks and run a supervised review cycle
Before handover, run one full review cycle with your staff under supervision, from alert to recorded review. Deliver the runbook set: onboarding steps for new sources, parser maintenance, detection tuning, upgrade and backup procedures, incident escalation, and the activity review checklist. Confirm who owns each task after go-live and what support the partner provides. The output is a signed runbook set and a completed supervised review record. Ask for the upgrade and support terms in writing before the rollout closes, since they determine how the SIEM is kept current after go-live.
Which open source platforms fit a healthcare SIEM and why
A healthcare SIEM has to collect logs from EHR systems, medical devices and endpoints, keep the logs themselves protected, and prove access control and audit review under the HIPAA Security Rule. The platforms below solve different parts of that problem, so each card names the constraint it addresses and the check to run before committing.
Wazuh for endpoint and agent coverage
Wazuh combines agents on Linux, Windows and macOS with a server, indexer and dashboard, and its prebuilt HIPAA view maps alerts to the Security Rule's audit controls and activity review standard. Its core is GPL-2.0, so confirm with counsel how any modifications and distribution fit your environment. For EHR servers and workstations, confirm that agents are supported on each operating system in your fleet, and check how the agent-less path covers network devices that cannot run an agent.
Security Onion for network visibility
Security Onion bundles Suricata, Zeek and osquery on the Elastic stack, which suits a hospital network team that wants packet-level evidence of traffic to EHR and imaging systems. Its Elastic License 2.0 restricts offering the software as a managed service and carries terms that need a legal read before commercial use, so the license review belongs in the project plan. Confirm sensor placement on clinical VLANs and how medical device traffic is captured without disrupting fragile devices.
Graylog Open or OpenSearch for log search
Graylog Open and OpenSearch give you a search and dashboard layer for high-volume clinical logs under Apache-2.0. OpenSearch's Security plugin provides role-based access, document-level and field-level security, field masking and audit logs, which matter when the logs themselves contain patient identifiers and only certain care teams should see them. Confirm that field masking and audit logging cover every index that holds ePHI, and test that a support engineer cannot read patient fields by default.
HashiCorp Vault and key material
HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. If your SIEM stack stores encryption keys, certificates or signing material for log integrity, that license choice affects your long-term support and legal position. Compare it with OpenBao under MPL-2.0 before standardizing, and ask counsel to confirm how the BSL terms apply to your use.
Deployment patterns for hospital networks and private clouds
A hospital SIEM has to collect from clinical networks, medical devices and the EHR without placing ePHI-bearing logs in a third party's cloud. The patterns below differ in scale, network reach and how much the hospital network team must operate, so the choice usually follows site count, segmentation and whether the site has internet access.
Single-site all-in-one server
One host runs the Wazuh indexer, server and dashboard together, suited to a single hospital or clinic with a modest number of endpoints and log sources. It keeps the design simple and the ePHI-bearing logs on hospital-controlled hardware. The network team must provide a dedicated, time-synchronized host, storage sized for the agreed retention, backup of the indexer data and a placement that the clinical network can reach on the agent and syslog ports. Confirm the install method (step-by-step, OVA, Docker or Ansible) against the current Wazuh deployment options before committing.
Clustered Wazuh server for growth
When endpoint count, ingest or the number of sites grows, the Wazuh server can run as a cluster for horizontal scaling. The hospital network team must plan load balancing for agent connections, node-to-node traffic and indexer capacity, and must agree who owns each node's patching. Clustering adds operational surface, so it should follow measured load rather than anticipated load. Ask the implementation partner how cluster nodes are upgraded without losing agent telemetry during a maintenance window.
Collectors in clinical network segments
Clinical segments holding medical devices, imaging and EHR application servers often cannot run agents, so syslog collectors or agentless monitoring sit inside each segment and forward events to the central SIEM. This keeps device traffic on the clinical side and limits firewall rules to the forwarding path. The network team must approve the segment-to-SIEM flows, confirm which devices are agentless and supply a list of device vendors and firmware versions the clinical engineering team owns.
Offline installation and offline vulnerability data
Some clinical and research networks have no internet route, so the SIEM, its updates and its vulnerability data must arrive by approved media. Wazuh documents an offline installation guide, and vulnerability detection can use an offline repository in place of the Wazuh CTI platform. The hospital must define how packages, rules and vulnerability feeds are verified, transferred and logged, and must agree how often the offline data is refreshed. Confirm the update cadence with the change board before go-live.
Hardened management plane with SSO
The dashboard, indexer administration and agent management interfaces hold alerts that describe patient systems, so they need their own access controls. Wazuh documents single sign-on support, and Keycloak or authentik can serve as the identity provider with MFA enforced for every administrator. The hospital team must decide which roles can see ePHI-bearing alert fields, restrict administrative paths to a management network, and log administrator actions. Confirm which SSO protocol the current Wazuh release supports before designing the federation.
What auditors and OCR reviewers ask to see from the SIEM
This table maps each piece of evidence an OCR investigator or independent assessor typically asks for to the component that produces it and the work that stays outside the SIEM. Read the middle column for what the tool can generate and the last column for what your compliance and operations teams must still document. There is no HIPAA certification, so the goal is evidence that holds up when HHS reviews a complaint or audit.
| Evidence requested | Producing component | Still a process outside the tool |
|---|---|---|
| Audit log configuration | Wazuh server (decoders, rules and agent configuration) and OpenSearch Security audit logs for the indexer | Written list of systems holding ePHI, the log sources enabled for each, and sign-off on what is excluded and why |
| Sample access reports for a patient record | Wazuh dashboard or indexer search over EHR and database audit events, filtered by user and record identifier | Procedure for who may request reports, how patient identifiers are handled in the report, and the reviewer's written conclusions |
| Activity review records | Wazuh dashboard alert views and saved searches, with alert history kept in the indexer | Dated review sign-off, named reviewer, frequency set by policy, and follow-up tickets for anything escalated |
| User identification and login monitoring evidence | Wazuh server authentication rules and indexer records of successful and failed logins, tied to unique user IDs from the directory | Confirmation that shared or generic accounts are prohibited, plus the process for investigating repeated failures |
| Log integrity and access control to the SIEM | OpenSearch Security role-based access, field-level security, audit logs and TLS for node and client traffic | Separation of duties for administrators, integrity checks on archives, and access reviews for who can read logs that contain patient data |
| Retention records | Indexer index lifecycle settings and snapshots that show how long alerts and events are kept | Retention period set by your policy and counsel, plus records of deletion or legal hold decisions |
| Business associate notice records | Alert and case records in the indexer showing when a security incident was detected and triaged | Business associate contracts under 45 CFR 164.314 and the notice steps, timing and recipients agreed with each business associate |
| Independent assessment (optional) | Evidence packages assembled from the components above | HITRUST r2 assessment is separate and optional; the SIEM does not issue any HIPAA certification |
What changes for clinical IT, privacy and security teams
A SIEM that ingests EHR and access logs becomes a privacy-sensitive system in its own right. Its alerts and search results often name patients, clinicians and record identifiers, so the people who can query the indexer are part of the HIPAA access control design. The HIPAA Security Rule's technical safeguards in 45 CFR 164.312 call for unique user identification and audit controls that record and examine activity in systems containing ePHI. In practice, that means defining a small set of roles in the Wazuh dashboard or OpenSearch Security (document-level and field-level security, field masking and audit logs are all available there), deciding which analysts may see raw patient identifiers, and logging every investigation search so that the people reviewing the SIEM are themselves reviewed. Confirm with your privacy officer which fields must be masked by default and whether any role needs to see unmasked data.
Remote access is where the risk is most visible. France's CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34 on 3 September 2026, finding that external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. Treat that finding as a test case for your own environment: confirm that every remote session to EHR and clinical applications produces an authentication event in the SIEM, that failed MFA attempts raise an alert, and that role changes made in your identity provider are visible in the logs. Ask whether your EHR vendor, managed SOC and remote support providers can be reached through paths that bypass these logs.
Business associates are the second change. A managed SOC or hosted SIEM that receives your ePHI-bearing logs is a business associate, and 45 CFR 164.314(a)(2)(i) requires a contract that obligates it to meet the Security Rule and report security incidents. Keeping the SIEM, its indexer and its backups inside your own cloud account or data center means fewer contracts to negotiate, fewer parties with access to patient-linked events and a shorter list of subcontractors to track. If you do use a partner to operate the platform, the contract should state who may access the indexer, how investigations are logged and how the partner's own staff are authenticated. Confirm these points before the SIEM goes live, not after the first incident.
How much a healthcare SIEM costs and what it needs from the hospital
What drives the cost of a self-hosted healthcare SIEM?
The main cost drivers are the volume of logs you ingest per day, how long you keep them searchable, the number of endpoints and log sources, and the detection engineering needed to make alerts useful for ePHI systems. Infrastructure for the Wazuh indexer, server and dashboard, or an OpenSearch cluster, scales with ingest and retention, so storage often becomes the largest recurring line. Software licensing is usually small because Wazuh is licensed under GPL version 2 and OpenSearch under the Apache License, Version 2.0, but you should confirm whether any paid support, premium modules or hosted options are part of your plan. Ask each vendor and partner to separate one-time setup from recurring infrastructure, support and rule maintenance.
Can an in-house team run a hospital SIEM without a partner?
Many hospital security teams can run a SIEM day to day, but the work that most often stalls is onboarding EHR, medical device and identity sources, writing and tuning rules, and handling upgrades. Those tasks need people who understand both clinical systems and detection logic. Decide who owns log source onboarding, who reviews alerts that touch ePHI, who patches the platform and who documents the evidence for the HIPAA audit controls standard. If any of those roles are unfilled, a partner can cover them under a written, fixed scope, with ongoing support available as a retainer.
How long does it take to get a first working log onboarding?
No researched timeline applies to every hospital, so treat any single number with caution. The first onboarding usually depends on how quickly network and clinical teams approve log forwarding, how many source systems need agents or syslog, and whether test environments exist. A practical first step is to onboard one identity source and one EHR audit log feed in a non-production environment, then move to production after review. Ask any partner to state the milestones, the systems in each milestone and the dependencies on your teams in the written scope before work starts.
What does a healthcare SIEM need from clinical and network teams?
The project needs named contacts from clinical applications, biomedical engineering, network operations and identity administration. Clinical application owners confirm which EHR audit events are available and how they are exported. Biomedical engineering confirms which medical devices can send syslog or cannot run agents, and what changes are safe during clinical hours. Network teams approve firewall rules, time synchronization and the segment where the SIEM runs, and they confirm that traffic to the logs stays inside the hospital network. Agree on change windows early, because a monitoring change that affects a clinical system needs the same care as any patient-facing change.
Is HIPAA compliance certified, and does a SIEM provide certification?
No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. A SIEM supports evidence for the audit controls standard in 45 CFR 164.312 and for information system activity review, but it does not make a hospital compliant on its own. Any vendor or partner that claims a HIPAA certification should be asked to show the basis for that claim in writing.
How are Wazuh upgrades handled in a healthcare environment?
Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so the team should plan for frequent patching. Each upgrade should go to a test environment first, then to production during an approved window, with agent and server versions checked for compatibility. The Wazuh server can run as a cluster and manages agent configuration and upgrades remotely, which helps with rollout. Confirm with your partner who tests each release, how rollback works, who records the change for the audit trail, and whether the upgrade effort is covered by a retainer or billed separately.
What should a partner quote for a healthcare SIEM include?
A useful quote lists the scope in writing: log sources by system, agent and syslog counts, daily ingest assumptions, retention periods for hot and archive storage, and the compliance views to configure. It should separate one-time work, such as architecture, onboarding, hardening and documentation, from recurring work, such as rule tuning, upgrades, backups and support. It should name the deliverables, the responsibilities of your teams, the exclusions and how changes to scope are priced. Because DeployOpen issues quotes only from a written scope, ask any partner, including DeployOpen, to show these elements before work starts.
Questions to ask an implementation partner before signing
Start with parsing, because an EHR or medical device log source that is not parsed correctly produces no usable alerts. Ask the partner which EHR platforms and device types they have onboarded into Wazuh or an OpenSearch-based stack, and ask for the decoder and rule files they will write for each source, the sample logs they tested against, and who owns those files after go-live. Ask how they handle devices that cannot run a Wazuh agent, and whether that means syslog collection with a documented parser or a separate integration. Confirm that each source named in the scope will appear as a line item with a defined set of event types, so you can check coverage at acceptance rather than trusting a general claim about EHR support.
Next, ask how PHI is kept out of the SIEM and how access to the SIEM itself is controlled. Ask which fields the partner will drop, hash or mask before indexing, which rules apply to the data and full-log fields in alerts, and whether masking is applied at ingest or at display. Ask how the OpenSearch Security plugin will enforce role-based access, document-level and field-level security, and field masking for analysts, auditors and the privacy office, and how administrator actions on the SIEM are written to audit logs that the SIEM itself retains. Ask for the written list of roles, the test that proves a restricted user cannot see masked fields, and whether the partner will connect the SIEM to your identity provider with multi-factor authentication enforced for every console user.
Finally, ask how the partner will handle offline operation, upgrades and HIPAA detection content. Confirm whether the scope includes the Wazuh offline installation and an offline vulnerability repository if your network is restricted, and who performs updates by media. Ask for the documented upgrade path for Wazuh 4.14 and the OpenSearch version in use, including a rollback plan and a test environment, and ask who pays for and performs upgrades during the support term. For HIPAA detections, ask who writes the rules for log-in monitoring and information system activity review, how each rule is tested against replayed events, and whether the partner will deliver a written record of what each rule is meant to detect. Also confirm what support covers after go-live, including response times, the review cadence for rules, and whether the work is a fixed-scope deliverable or a retainer.
