How Graylog helps meet HIPAA audit controls for ePHI systems
If you are a covered entity or business associate, you must record and examine activity on every information system that contains or uses electronic protected health information. The two requirements Graylog supports directly are the audit controls standard in 45 CFR 164.312(b), which calls for hardware, software or procedural mechanisms that record and examine that activity, and the information system activity review specification in 45 CFR 164.308(a)(1)(ii)(D), which calls for regular review of system activity records such as audit logs. The Security Rule (45 CFR Part 164 Subpart C) applies to health plans, health care clearinghouses, covered health care providers and their business associates for all ePHI they create, receive, maintain or transmit. HIPAA has no certification. HHS states that no Security Rule standard requires certification, so DeployOpen does not certify anything. We plan and build the logging and review mechanism and prepare the evidence, and your auditors or HHS decide whether it meets the rule.
Graylog is one part of that picture, not the whole of it. It does not perform your risk analysis under 164.308(a)(1), write your policies, train your workforce, manage business associate contracts under 164.314, or handle physical safeguards. Those remain your responsibility and should be documented separately. Before you commit to a design, confirm with your compliance lead which systems hold or use ePHI, since that inventory defines the log sources Graylog must receive. Also confirm how your organization has decided which implementation specifications are required and which are addressable, because the documented rationale for any addressable choice is part of the evidence an examiner will ask for.
The practical decision is how much of the audit trail to centralize and who may read it. Start by listing the EHR, identity provider, VPN, database and server sources that record access to ePHI, then map each to a Graylog input such as syslog, GELF or Beats. Review the Graylog pricing and product pages before you choose an edition, because some of the event definition and correlation features used for regular review sit in the Enterprise or Security editions rather than Graylog Open. The access controls on the log data itself also matter: Graylog's roles and index set permissions should keep audit records readable only by the people who review them, and the log platform's own administrator activity should be logged. Ask DeployOpen or your team to document each choice as a written design that an auditor can follow.
Mapping HIPAA audit requirements to Graylog capabilities
This table maps the HIPAA audit controls, activity review and unique user identification specifications to the Graylog components that satisfy them, with the configuration each needs. Each row also marks whether the feature is available in Graylog Open or needs an Enterprise or Security license, so you can confirm edition fit before you design the deployment.
| Requirement | Graylog configuration | Edition needed |
|---|---|---|
| Audit controls (45 CFR 164.312(b)): record and examine activity on ePHI systems | Enable inputs such as syslog, GELF or Beats on EHR, identity and infrastructure sources. Route audit events into dedicated streams with processing pipelines that normalize fields. | Graylog Open |
| Information system activity review (45 CFR 164.308(a)(1)(ii)(D)) | Build dashboards for access to ePHI systems and schedule event definitions that alert on failed logins, privilege changes and off-hours access. Record who reviewed each finding and when. | Graylog Open (event definitions and dashboards). Verify correlation and investigation features against your edition. |
| Unique user identification (164.312(a)(2)(i)) as it affects log attribution | Require individual accounts at every source and forward the user identifier as a normalized field. Confirm that shared or generic accounts are flagged in pipeline rules. | Graylog Open |
| Single sign-on for Graylog console access | Use Active Directory, LDAP or trusted header authentication so each reviewer signs in under a named identity. | Active Directory, LDAP and trusted header: Graylog Open. Okta, generic OpenID Connect and SAML: Enterprise |
| Access restriction on log data | Create roles that limit which streams, dashboards and index sets each reviewer can search. Keep administrator and reviewer roles separate. | Graylog Open (confirm sharing and role depth for your use) |
| Retention and protection of audit records | Set index rotation and retention so audit indices are kept for the period your policy requires. Size storage as daily ingest times retention days times 120 percent, per Graylog guidance. | Graylog Open. Archive restore and data tiering: Enterprise |
| Alerting and notification of review findings | Send event notifications to email, Slack or PagerDuty, and record triage outcomes in your own ticketing workflow. | Graylog Open (notification channels). Confirm investigation records for your edition |
Which audit logs to collect from EHR, identity and infrastructure systems
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, so the collection scope starts with every system that touches ePHI, not only the EHR. In practice that means the EHR application and its database, the identity provider and directory, VPN concentrators, remote access gateways, file shares holding clinical documents, hypervisors and the operating systems and containers underneath them. Build the source list from your own risk analysis and system inventory. The standard does not name the events to capture, so the event types for each source should be written down and approved by the security official before any input is configured. Confirm with each vendor which log format, fields and timestamp convention the EHR and identity products emit, because a Graylog extractor cannot parse a format you have not checked.
Graylog receives these logs through inputs. Syslog inputs suit network devices, VPN appliances and most Linux hosts, GELF suits applications that can send structured messages, and Beats inputs cover agents such as Filebeat or Winlogbeat that ship files and Windows event logs. Choose the input per source and record the choice in the inventory, since it determines transport security, message size limits and how fields arrive. Within Graylog, streams route each message into a defined category, and processing pipelines parse and normalize fields. Create a dedicated ePHI-scope stream for sources in the risk analysis, with rules based on source host, input or known application name, so that these messages go to their own index set and are easier to restrict, review and retain under the access controls covered later on this page.
Plan for sources that fail silently. A change in a vendor update, a disabled audit policy or a broken forwarder can stop events without any error in the EHR. For each source, define the expected event types and a baseline message rate, then test that a sample of real events arrives, parses and lands in the right stream after every configuration change. Keep a short record of the tested events per source, because an examiner reviewing activity records will ask whether the mechanism captured what the organization said it would capture. Confirm with your compliance lead whether any source falls under a business associate contract that requires the vendor to supply logs or incident data, as set out in 45 CFR 164.314(a)(2)(i).
Configuring Graylog for HIPAA activity review
This sequence turns Graylog into the activity record and review mechanism for ePHI systems, from scoping the systems through a documented review procedure with a named owner. Each step ends with a check you can show an assessor.
Scope the ePHI systems and log sources
Start by listing every information system that creates, receives, maintains or transmits ePHI, including the EHR, identity providers, directory services, databases, file stores, and the servers and network devices that support them. Your compliance lead and system owners confirm the list, then mark which sources emit audit records for user access, authentication, record views, changes and administrative actions. The output is a signed source inventory with an owner for each system, which becomes the basis for the input and stream design that follows.
Deploy Graylog nodes on the documented multi-node layout
Build the production cluster as Graylog documents for medium to large deployments: three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes. Set is_leader to false on follower Graylog nodes, and size storage with the documented formula of daily ingest times retention days times 120 percent, plus a message journal on SSDs. Your platform team performs the installation from packages or Docker Compose, and the check is that all nodes report healthy and the cluster accepts a test message through the load balancer.
Configure inputs and streams for audit sources
Create one input per source type, such as syslog for network and Linux hosts, GELF or Beats for applications and agents, and the protocol your EHR vendor supports for its audit feed. Route each source into streams that separate ePHI audit records from general operational logs, so reviewers and access roles can be scoped to the right data. Confirm the inputs you need are included in your Graylog edition, because some inputs require an Enterprise license. The check is a test event from each source appearing in its intended stream with the expected fields.
Set index rotation and retention on a dedicated index set
Create a dedicated index set for ePHI audit logs so its rotation and retention settings do not depend on general log traffic. Choose rotation by message count, size or time, and set retention so the oldest indices are deleted only after your documented retention period has been met. Your compliance owner sets the retention period from the policy that applies to your organization, and the platform team confirms it in the index set settings. The check is a saved configuration export and a test index that rotates and ages as expected.
Build dashboards and event definitions for review
Build dashboards that show the activity your reviewers need to examine, such as failed and successful logins, record access outside expected patterns, privileged changes and logging gaps from each source. Turn the conditions that need timely attention into event definitions with defined thresholds and notifications to the responsible channel, and test each one with replayed or simulated events. Document which dashboards are reviewed and which events generate alerts. The check is a test alert delivered to the intended recipient and a dashboard that loads with current data from every source in the inventory.
Restrict access to log data through roles
Create Graylog roles that limit who can search, view dashboards and read each stream, so that people reviewing general operations do not gain access to ePHI audit records by default. Connect authentication to your identity provider where your edition supports it, and remove shared or default administrative accounts from daily use. Record who holds each role and review those assignments on a set schedule. The check is an exported role list and a test account that can see only the streams its role allows.
Document the review procedure and its owner
Write the procedure that states what is reviewed, how often, which dashboards and event definitions are used, how findings are triaged and escalated, and how reviews are recorded. Name an accountable owner and a backup, and define the evidence each review produces, such as a dated checklist or ticket. HIPAA requires regular review of system activity records, so the procedure should be specific enough that a second reviewer could repeat it. The check is an approved procedure with a named owner, plus a first completed review record that an assessor can trace back to Graylog.
Regular activity review with dashboards and event definitions
The information system activity review specification in 45 CFR 164.308(a)(1)(ii)(D) requires a covered entity to review records of system activity on a regular basis. In Graylog, the routine review is a recurring workflow that a named person performs against dashboards built for the review, not an ad hoc search. The review routine should state which dashboards are checked, how often, by whom, and where the reviewer records findings and follow-up actions.
- Dashboards per system: Build one dashboard for EHR access, one for identity events and one for infrastructure administration, each showing failed logins, privilege changes and record access counts over the review period.
- Named reviewer and cadence: Assign a reviewer and a backup, and set the review frequency in your written policy so that the schedule is defined before an audit.
- Sign-off record: Keep a dated log of each review, the dashboards viewed, anomalies found and the ticket or decision that resolved each one.
- Coverage check: Confirm that every audited source still sends events, because a silent source produces an empty dashboard that looks like a clean review.
- Review scope: Document which event types are in scope for routine review and which are reviewed only when an alert fires.
Before you rely on the routine, confirm with your compliance lead how the review frequency and evidence format must be documented for your organization.
Event definitions in Graylog evaluate incoming messages or search results against conditions and raise events that trigger notifications. For HIPAA audit controls, the useful definitions target activity that needs prompt attention: repeated failed logins, privilege changes outside change windows and access to patient records by users who are not on the care team. Writing the conditions around your own care-team and role model usually matters more than the default thresholds.
- Failed logins: Define a condition that counts failed authentication events per account within a time window, and alert when the count passes a threshold you set and document.
- Privilege changes: Alert on group membership or role changes for EHR and directory accounts, and route them to the security queue.
- Record access outside the care team: Compare the user and patient relationship available in your EHR audit logs with your access model, and alert on accesses that have no documented care relationship. Confirm with your EHR vendor which fields are logged.
- Notifications: On Graylog Open, notifications can be sent to PagerDuty, Slack and email, according to the Graylog Open product page. Confirm the channel you need is supported in your edition before you design around it.
- Editions: Correlation, some aggregation features and advanced detection content depend on Graylog Enterprise or Graylog Security, so confirm each alert type against the current feature list before you commit to it.
Test each event definition with a known test event and record the result, since an alert that never fires is a control gap an auditor can find.
Historical investigation covers questions that arise after a complaint, an alert or a scheduled review: who viewed a patient record, what an administrator changed, and whether a pattern existed before an incident was reported. Graylog provides search over stored messages within the retention of each index set, and event definitions can also run over historical data to find past matches. The quality of these investigations depends on consistent field names and time synchronization across sources.
- Saved searches: Save the queries used for common questions, such as all accesses to a given record, so that investigations are repeatable and the query itself becomes evidence.
- Time range and retention: Confirm that the index sets holding EHR and identity logs keep the period your investigation policy requires, since older data may be removed by rotation and retention.
- Consistent fields: Use pipeline rules to normalize user, patient and source host fields across systems so that one query finds the same person across the EHR and identity logs.
- Case records: Record the search, the time range, the results reviewed and the conclusion in your incident or ticketing system, not only in the Graylog interface.
- Clock accuracy: Verify that all sources use synchronized time, because investigation timelines are unreliable when sources disagree.
Before relying on historical searches for an audit, confirm your retention settings and whether searches over archived data need a particular edition or restore step with your Graylog representative.
Evidence Graylog produces for HIPAA audits and how to keep it
An OCR reviewer or auditor will ask to see what the audit log system captured and whether anyone looked at it on a schedule. The records below answer those questions, and each one needs its own owner, storage location and change control so it stays credible after the audit window closes.
Retained audit log records
The raw and indexed messages from EHR, identity and infrastructure sources are the core evidence for 45 CFR 164.312(b). Keep a documented copy of the index sets that hold them, with a record of which sources were expected to report and which actually did. Check that retained messages still carry timestamps, source hostnames and user identifiers after parsing pipelines run. A reviewer will usually sample a date range, so confirm you can export that range without relying on live search.
Input and stream configuration exports
Inputs define which systems send logs and streams decide where those messages are routed. Export both on a regular basis and store the exports outside the Graylog server so they survive a rebuild. An auditor can use the export to confirm that EHR and identity sources were connected during the period under review. Record who changed a stream rule and why, because a silent rule change can hide events from every later review.
Dashboard and event definition records
Dashboards and event definitions show what the organization chose to watch and how often it was reviewed. Keep a versioned copy of each definition with its owner, threshold, notification target and the date it was last changed. Include the rationale for each alert, since an unexplained gap between a policy and a configured condition is a common finding. Review the list at least once per cycle to confirm no definitions were disabled quietly.
Review sign-off records
Section 164.308(a)(1)(ii)(D) requires regular review of system activity, so the review itself is evidence. Use a ticket or form for each review that names the reviewer, the period covered, the dashboards or searches used, and the findings or the statement that none were found. Store completed records in a system with write-once or audit trail behavior. Confirm the schedule is written into policy so the reviewer can show the cadence matched what was documented.
Role and access assignments
Access to log data is itself sensitive, because audit logs can reveal who viewed which patient record. Export the list of Graylog roles, the users and groups assigned to each, and the authentication source used for each user. Record approvals for every privileged role and the date it was removed when someone changed jobs. Compare this export with the identity provider each quarter so that orphaned accounts are caught before a reviewer does.
Retention settings and change history
Retention is set by index rotation and deletion behavior, so a changed value can shorten the history without anyone noticing. Keep a dated record of each index set configuration and the reason for any change, including the retention period chosen in your risk analysis. Ask your compliance lead to confirm the period required by your own policies and any state or contractual rules, because HIPAA sets no fixed number of days. Preserve these records for the same period as the logs they describe.
Restricting access to log data that contains ePHI
Audit logs holding ePHI or identifiers need the same access discipline as the systems they describe. An EHR audit trail often records patient identifiers, record numbers, user names and the scope of each chart opened, so a Graylog search, stream or archive can expose protected information even though no clinical record is visible in it. Plan Graylog roles before you connect the first input. Separate the people who administer Graylog (inputs, index sets, retention, users and pipelines) from the people who review activity, and give reviewers read access only to the streams and dashboards their review duties require. Administrators who can both change retention and search every stream are in a position to shorten or hide their own trail, so that combination should be a documented exception, not a default.
Choose the authentication source deliberately, because it decides how joiners, movers and leavers reach the log platform. On Graylog Open, the authentication documentation covers Active Directory and LDAP, along with trusted header authentication, which only makes sense behind a proxy you control and have hardened. Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. Confirm with Graylog which of these your edition supports before you commit to a design, and confirm that de-provisioning a user in your identity source disables their Graylog access promptly. Shared local accounts should not be used for reviewers, since the review record is only meaningful if it names the person who performed it.
Treat access control on Graylog as one layer, and verify the others separately. Encryption in transit between agents, server nodes and the search backend, and protection of the MongoDB and Data Node storage that holds the logs, are covered in the Graylog security topic and should be designed alongside this section. Ask your team to test, rather than assume, that a reviewer account cannot reach the backend directly, that archived or restored data follows the same role boundaries, and that your access review process retains evidence of who held which role on which date.
What Graylog does not cover for HIPAA
Graylog supplies the audit mechanism that 45 CFR 164.312(b) asks for, but it does not make an organization compliant with the Security Rule. The cards below cover the obligations that sit outside the log platform and that the organization must decide, document and staff itself.
Risk analysis and risk management
The Security Rule requires an accurate and thorough assessment of risks to ePHI, followed by risk management measures. Graylog does not identify which systems hold ePHI, which threats matter or how much residual risk is acceptable. Use the risk analysis to decide which sources must feed Graylog, which event definitions matter most and how often review happens. NIST SP 800-66 Rev. 2 offers sample questions you can use to test the analysis.
Reasonable and appropriate decisions
For each addressable specification, the organization must assess whether a measure is reasonable and appropriate under 45 CFR 164.306(d), document the reason if it is not adopted and implement an equivalent alternative if one is reasonable. Graylog cannot make that determination. Record each decision for audit log retention, review frequency and log access so an assessor can trace why the configuration looks the way it does.
Written policies and procedures
The Security Rule's organizational and documentation standards require written policies, procedures and documentation that describe how safeguards operate. Graylog stores logs but does not hold your review procedure, escalation path or log access policy. Write down who reviews dashboards, how often, what triggers an investigation and how review records are kept. Graylog event definitions can enforce parts of the procedure, but the procedure itself must exist outside the platform.
Workforce training
Staff who run, review and investigate Graylog must understand the systems feeding it and the ePHI they touch. Graylog provides no curriculum for recognizing suspicious access to EHR records or for handling a flagged event. Plan training for reviewers, administrators who manage inputs and retention, and clinical or support staff who may be asked about access. Keep attendance and content records as part of the audit evidence.
Business associate contracts under 164.314
A business associate contract must require the business associate to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI and report security incidents to the covered entity. If a managed service or hosting provider can access the Graylog cluster or its stored logs, that provider is a business associate. Graylog does not create these obligations. Confirm contract terms before any party outside your control receives log data containing ePHI.
Physical, administrative and encryption safeguards
Graylog can log automatic logoff and access events on source systems, but it does not enforce them. Physical controls over data centers and workstations, encryption of ePHI at rest and in transit, and automatic logoff settings are the organization's responsibility. Confirm that the Graylog server, MongoDB and Data Node hosts use encrypted storage and transport, and that log data is not exposed to users who should not see ePHI.
Pending Security Rule revision
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22). As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. The proposal could change specific requirements, including those related to audit controls. Track the rulemaking, reassess your audit control design when a final rule appears and keep the configuration documented so changes can be mapped quickly.
Questions buyers ask about Graylog and HIPAA audit controls
Does running Graylog make an organization HIPAA compliant?
No. Graylog is a tool that can support the audit controls standard in 45 CFR 164.312(b), but compliance depends on the whole Security Rule program across administrative, physical and technical safeguards. HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications, so no product or partner can issue a HIPAA certificate. Graylog helps you record and review activity on systems holding ePHI, while policies, risk analysis, access management and business associate contracts remain your responsibility. Independent auditors and certification bodies issue audit reports; DeployOpen prepares systems, controls and evidence for those assessments but does not issue them.
Is there a HIPAA certification for a Graylog deployment?
No. HHS's 2003 FAQ says no Security Rule standard requires certification, and private certifications do not stop HHS from later finding a violation. The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits. When a buyer asks for proof, the practical answer is documented evidence: configuration records, collected log sources, event definitions, review records and retention settings that you can show an assessor. Be wary of any vendor offering a HIPAA seal for its logging platform.
What does Graylog cost for HIPAA logging?
Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, according to Graylog's pricing page. Both paid editions carry a minimum of 10 GB per day or 100 Graylog Compute Units and are licensed on processed data, with no per-user or per-device fees. Costs recur annually for licenses. Your own costs include infrastructure for servers, MongoDB, storage and backups, plus staff time. Ask for a written quote that lists which features need an Enterprise or Security license, such as the data lake, archive restore or correlation engine.
What drives the cost of a self-hosted Graylog setup?
Four factors drive most of the cost: daily log volume, retention length, search performance requirements and how much redundancy you need. The Graylog system architecture guidance advises sizing storage as daily ingest multiplied by retention days multiplied by 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. Multi-node designs use three Graylog and MongoDB nodes, three Data Nodes and a load balancer for medium to large deployments. Each added source, parser or dashboard adds design and test effort. Ask any partner to show the sizing assumptions behind the quote.
How long does a HIPAA-focused Graylog setup take?
Duration depends on the number of EHR, identity and infrastructure log sources, how many already export audit logs, whether you need a multi-node cluster, and how quickly your team can approve retention and access decisions. A single-node proof of concept is much quicker than a clustered production build with tested backups and encrypted connections. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask for a timeline that lists each source and each review dashboard. DeployOpen does not publish a fixed duration.
What does our organization need to provide for the project?
You need to provide a named owner for HIPAA compliance, access to the EHR, identity provider and infrastructure systems that produce audit logs, and decisions on retention periods and who may search or review log data. Your team also supplies network paths for log forwarding, server or cloud accounts in your own environment, and sign-off on access roles. Because logs can contain ePHI, you must decide how long they are kept and who may see them. Confirm with your compliance and legal teams which records must be retained under your own policies.
Can our in-house team build and run this themselves?
Often yes, if you already run Linux servers, MongoDB, a search backend and identity integration, and you have time to test and document the work. Graylog Open is free to use, and its documentation covers packages, Docker Compose and multi-node setups. The harder parts are usually data source mapping, parsing, role-based access, review routines and evidence collection, which need security and compliance knowledge as well as operations skills. Compare the internal effort, including ongoing upgrades and on-call coverage, against a fixed-scope engagement, and decide which parts you want to keep in-house.
What is the HIPAA civil money penalty range under 45 CFR 102.3?
For penalties assessed on or after January 28, 2026, the inflation-adjusted range under 45 CFR 102.3 runs from 145 US dollars per violation with no knowledge to 2,190,294 US dollars per violation for uncorrected willful neglect. The calendar-year cap for identical violations is also 2,190,294 US dollars, according to the amount published in 91 FR 3666. These figures are the reason to document how your logging and review controls work, but penalties depend on facts such as knowledge, correction and culpability. Confirm the current figures on the eCFR page before using them in internal documents.
How DeployOpen scopes and delivers HIPAA-aligned Graylog configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure. For HIPAA audit controls, we start from the systems that hold ePHI, agree the audit log sources and review routines in writing, and build the Graylog configuration to match, so your compliance and security teams can examine the result against your own risk analysis.
How we scope
- We inventory the systems holding or using ePHI and agree which EHR, identity and infrastructure log sources feed Graylog.
- We document the review cadence, dashboards and event definitions that your security team will own after handover.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Graylog server nodes, MongoDB and the Data Node or OpenSearch backend in infrastructure you control.
- We configure inputs, streams, processing pipelines, index sets and role-based access restrictions on log data.
- We test that expected events arrive, searches return them, and event definitions fire to your chosen notification channels.
How we hand over
- We deliver configuration documentation mapping each audit log source to its Graylog stream, index set and review routine.
- We record retention settings and the storage sizing basis so your team can reproduce and justify them later.
- We walk your administrators through daily operations, access reviews and how to adjust event definitions safely.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- Upgrades are planned around Graylog's documented breaking changes, compatibility matrix and backend version requirements.
- DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or HIPAA certifications.
