Graylog for healthcare: why the build starts with what the logs must prove
A hospital or health software team that must show who accessed electronic protected health information (ePHI) needs one place to search EHR, identity and network logs, and the design of that place should start from the questions an auditor or HHS investigator will ask. Under the HIPAA Security Rule, covered entities and business associates must protect ePHI they create, receive, maintain or transmit, and the technical safeguards in 45 CFR 164.312 include audit controls and unique user identification. Before any input is configured, list the systems in scope (EHR, directory, VPN, remote access, database and file stores), the events each must record, and the people who will search them. That list determines which sources Graylog receives, how streams separate patient-related events from infrastructure noise, and who holds search and export rights.
Graylog fits a self-hosted, in-region design because the log store, the metadata in MongoDB and the Data Node cluster can all sit in the hospital's own accounts or data centers, which keeps log content under the same residency and access rules as the source systems. Logs from an EHR can contain patient identifiers even when the application itself is well governed, so plan redaction or field-level restriction in processing pipelines and treat search roles as a clinical access decision, not only an IT one. Two things differ from a generic logging setup: retention is set per index set against the documentation the organization must produce, and access to the search interface is tested like any other control. HIPAA sets no certification, and HHS states that no Security Rule standard requires one, so the evidence an assessor sees is the working control, its configuration and the records it produces. Confirm the retention period with your compliance lead and legal counsel, since no federal figure is supplied here.
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which the Open Source Initiative does not approve as an open source license, so legal and procurement teams should review it before standardizing on it. Several healthcare controls depend on capabilities that need an Enterprise or Security license on top of Graylog Open, including single sign-on through Okta, OpenID Connect or SAML, the data lake and archive restore, and SIEM features such as investigations and compliance packs. Check the current edition for each required feature against the Graylog pricing page before the design is fixed, because identity integration and archive restore often decide whether the audit trail is practical to run.
Which HIPAA Security Rule requirements shape the Graylog design
This table maps the HIPAA technical safeguards and audit controls to what each means for Graylog log sources, retention and search access. Read each row as a design question to settle before ingestion starts, with the evidence an assessor is likely to ask for. The main takeaway is that the rule sets outcomes, not tools, so the Graylog configuration is only as useful as the documented decisions behind it.
| Requirement | What it means for Graylog | Evidence to prepare |
|---|---|---|
| Unique user identification (164.312(a)(2)(i), required) | Log sources and Graylog users must trace actions to one person, so shared accounts and generic service identities need a documented owner and mapping. | Identity source configuration, user list with role assignments, and a record of how shared or service accounts are attributed. |
| Emergency access procedure (164.312(a)(2)(ii), required) | Break-glass access to EHR or identity systems should generate events that Graylog captures and routes to a reviewer, and Graylog's own admin access needs an equivalent path. | Written emergency access procedure, sample events from a test use, and alert definitions for emergency access use. |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Session timeout events from EHR, identity and workstation sources are useful audit signals. Decide whether to collect them and document why if you do not. | Assessment of reasonableness, the timeout settings in each source, and the documented alternative if a source cannot send these events. |
| Encryption and decryption (164.312(a)(2)(iv) and 164.312(e)(2)(ii), addressable) | Log transport and storage holding ePHI-adjacent data should be encrypted. Confirm which inputs support encrypted transport in your version before choosing them. | Transport and storage encryption settings, the addressable decision record, and the key management ownership. |
| Audit controls and activity review (164.312(b) and 164.308(a)(1)(ii)(D)) | Define which EHR, identity and database events are logged, how long they are kept, and who reviews them on what schedule. Searches and dashboards are the review tools, not the policy. | Log source inventory, review schedule, review records, and retention settings per index set. |
| Access to log search (164.308(a)(4) and 164.308(a)(3)) | Logs can contain patient identifiers. Restrict search and stream access by role so only people with a need to know can see sensitive sources. | Role matrix, stream permissions, and access review records. Confirm the Graylog edition that provides the roles you need. |
| Business associate terms (164.314(a)(2)(i)) | If a managed service or hosting partner handles ePHI in logs, the contract must require Security Rule compliance and incident reporting, with the same terms flowed to subcontractors. | Executed business associate agreements covering log hosting, support access and subcontractors. |
| Evidence, not certification (HHS FAQ 2003) | HHS does not certify compliance. This work produces controls, configurations and records that auditors or OCR can review, not an audit report or attestation. | Documented control mapping, configuration baselines and review logs maintained over time. |
Which Graylog inputs, streams and pipelines matter for EHR and identity logs
Clinical systems and identity servers produce the events a HIPAA audit will ask about, but they also put patient identifiers into log messages. The design choices below decide which sources reach Graylog, who can search them, and how long each class of data is kept.
Syslog and Beats inputs for EHR hosts
Most EHR application servers, database hosts and identity servers send audit events through syslog or Beats-based shippers. Decide per source which protocol, port and transport your security team will support, and whether the host can hold events locally if the collector is down. Confirm each input type in the current Graylog inputs documentation, since some inputs require an Enterprise license. Test that timestamps and time zones parse correctly, because access reviews depend on accurate event order.
GELF inputs for application audit events
Applications that write structured audit records, such as record view, export and break-glass events, can send them as GELF so fields stay typed and searchable. Agree a field naming standard with the application team before go-live, so that user ID, facility and record type mean the same thing across systems. Unstructured free-text messages make access investigations slow and make it harder to prove who viewed which chart.
Streams that isolate ePHI-bearing sources
Streams route messages to index sets and control which roles can search them. Create dedicated streams for EHR, patient portal and clinical identity sources, and keep general infrastructure logs in separate streams. Each stream should map to a named owner and a documented access list. Confirm which role and sharing controls your edition provides before you rely on them to limit clinical log access.
Pipelines that mask patient identifiers
Processing pipelines can drop fields, replace values or redact patterns before messages are indexed. Test rules against sample events containing names, dates of birth, medical record numbers and free-text notes, because a rule that works on structured fields may miss identifiers inside a message body. Keep the original raw message in a restricted index only if your privacy and legal teams approve it, and record which rules changed the data.
Index sets per data class
Index sets control shard layout, rotation and retention for each stream. Give ePHI audit trails their own index set with a retention period that matches your written policy, and give high-volume network or debug logs a shorter one. Index rotation and deletion in Graylog Open follow the oldest-first model, so set retention deliberately before data accumulates. Confirm the storage and archive options available on your edition with the current product documentation.
LDAP or Active Directory on Open, SSO on Enterprise
Graylog Open supports Active Directory and LDAP authentication, and trusted header authentication. Okta, generic OpenID Connect and SAML single sign-on are listed for Graylog Enterprise. Map directory groups to Graylog roles before go-live, and confirm with your identity team whether MFA is enforced at the directory or the SSO provider, since access to clinical logs should not depend on a single password. Verify the current authentication options in the documentation for your version.
How to keep patient data out of logs and search results
Log messages from EHR systems and integration engines often carry patient names, medical record numbers, dates of birth and free-text clinical notes, usually because an application or interface engine writes the full payload when something fails. Once that text lands in Graylog, every person with search access can read it, so the minimum necessary principle in the HIPAA Security Rule has to be applied to what analysts see, not only to what the source system stores. Before building anything, the team should inventory the sources feeding Graylog and sample real messages from each one, then confirm with its privacy officer and compliance lead which fields count as ePHI in its own environment. That decision is the team's to make, and it sets the scope of every rule below.
Redaction belongs in the processing pipeline, where Graylog applies rules to messages before they are indexed. Pipeline rules can match patterns such as record numbers or dates and replace them, and field filtering can drop attributes that have no investigative value, such as full HL7 segments or free-text note fields. Keep the raw source logs where they are only if your retention and access design allows it, because anything indexed in Graylog is searchable and anything archived can be restored. Stream-level restrictions then control who can reach the sensitive indices: route messages from clinical applications into a dedicated stream, assign that stream to its own index set, and grant access through roles that cover only the care-operations or security staff who need it. Review the role and sharing settings against the team's access model, and confirm how the Graylog edition in use supports each of these controls.
Test redaction against a set of sample messages before any production source is connected. Build a test set that includes known patterns, edge cases such as names split across fields and identifiers in free text, and messages from every integration type, then run the pipeline and search the output for the original values. Record the results as evidence for the team's own control review. Repeat the test after every pipeline change, parser update or new interface, because a single new message format can bypass a rule that worked yesterday. The HIPAA Security Rule does not certify tools, so this testing supports the organization's own risk analysis rather than replacing it.
Rolling out Graylog in a hospital or health software environment
This sequence moves Graylog from agreed scope to a monitored production service, with ePHI boundaries, access rules and retention decided before any log source is connected. Each phase ends with a check that a privacy, security or operations owner can sign off.
Scope log sources and ePHI boundaries
Work with your privacy and security officers to list the systems in scope, such as the EHR, identity provider, VPN, remote access gateways, medical device networks and integration engines, and to mark where electronic protected health information could appear in events. The scope, deliverables and timeline are agreed in writing before any work starts. Done means every source has an owner, a documented purpose for its logs, and a record of which fields are expected to hold patient identifiers.
Build a non-production multi-node environment
Stand up a non-production cluster using the multi-node pattern Graylog documents: three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer, with follower Graylog nodes set to not be leaders. Confirm the MongoDB and search backend versions against the compatibility matrix for your release, and size storage with the documented formula of daily ingest times retention days times 120 percent. Done means the cluster passes failover tests and the sizing worksheet is approved by the operations owner.
Onboard sources and test redaction
Connect each in-scope source through the inputs Graylog supports, such as syslog, GELF or Beats, and route events through streams and processing pipelines. Use sample events that contain synthetic patient-like values to test whether pipeline rules mask, drop or hash identifiers before they are indexed. Done means each source has a redaction test record, and the privacy officer has reviewed any field that could still carry patient data.
Define the access model and emergency access
Map roles to care, security, audit and administrative duties so that only staff with a need to know can search sensitive streams. Connect authentication to your directory: Graylog Open supports Active Directory, LDAP and trusted header authentication, while Okta, OpenID Connect and SAML single sign-on need an Enterprise license. Document the emergency access procedure, test it with a break-glass account, and log every use. Done means a tested role matrix and a signed emergency access runbook exist.
Configure retention and archive settings
Set index rotation and retention per stream so that audit trail data and general system logs follow different periods, as agreed with your compliance lead. Confirm the retention periods that apply to your organization with your legal and compliance owners, because HIPAA sets safeguards and documentation duties but does not prescribe a log retention period in the Security Rule. Done means each index set has a written retention rule, and a restore from the archive has been tested.
Build the alert and review workflow
Create event definitions for the access and authentication patterns your security team cares about, such as repeated failed logins to the EHR, access outside normal working hours, or bulk record views. Route notifications to the channels your on-call staff use, and define who reviews each alert and how a finding becomes an incident. Done means a test alert reaches each channel, and the review steps are written into the security operations procedure.
Hand over to operations
Move the approved configuration from non-production to production through the same change process used for other clinical systems, then transfer monitoring, backup, journal and upgrade runbooks to your operations team. Plan upgrades with the documented breaking changes in mind, and confirm which support model covers the platform after handover. Done means the operations owner accepts the runbooks, a production review has been recorded, and the evidence pack for the scope is filed with the privacy and security officers.
Compliance frameworks healthcare teams check against
Healthcare teams rarely answer to one framework. The HIPAA Security Rule sets the baseline for US electronic health information, while HITRUST, NIS2, GDPR and 21 CFR Part 11 apply depending on where you operate and what records you keep. Graylog can collect and retain the evidence each one asks for, but DeployOpen prepares that evidence and does not issue audit reports or certifications.
HIPAA Security Rule
The Security Rule applies to covered entities and business associates for all electronic protected health information they create, receive, maintain or transmit. HHS states there is no HIPAA certification, so there is no badge to buy. The Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. A proposed revision published in January 2025 is not final, so confirm the current text before you design retention and review rules. Graylog evidence should show audit controls over EHR and identity systems, including who searched which patient-related logs and when.
HITRUST as an assessed option
HITRUST is a voluntary, privately assessed framework that many health software buyers request in contracts. Its CSF is organized into control categories, objectives and specifications, and an external assessor determines the result. An e1 or i1 certification lasts one year and an r2 certification lasts two years. Ask your customers which HITRUST assessment type they need before you map Graylog controls to specifications, and confirm the CSF version in use at the time of assessment.
NIS2 health sector scope
NIS2 lists health as a sector of high criticality. In scope are healthcare providers, EU reference laboratories, medicinal product research and development, manufacturers of basic pharmaceutical products, and manufacturers of medical devices critical during a public health emergency. If you fall in one of these groups in an EU member state, your logging, monitoring and incident handling are part of your statutory obligations. Confirm your classification with national authorities and legal counsel before you set Graylog alert and reporting duties.
GDPR Articles 32 and 34
Article 32 requires appropriate technical measures for personal data, and Article 34 governs communicating breaches to affected people. In September 2026 the French data protection authority fined a private hospital EUR 500,000 under these articles. It found that external access to the patient record system lacked VPN and multi-factor authentication, and that access control ignored the care team's need to know. For Graylog, that means restricting who can search patient-identifiable log fields and reviewing access rights regularly.
21 CFR Part 11 records
If your health software supports FDA-regulated research or clinical trials, 21 CFR Part 11 governs electronic records and electronic signatures. Audit trails, access controls and record integrity matter when the logs themselves are part of a regulated record set. Decide early which Graylog data counts as a regulated record, how it is retained and whether any validation is required for the platform. Ask your quality team to confirm scope rather than assuming ordinary application logs fall outside it.
Questions hospitals and health software providers ask before hiring help
What drives the cost of a Graylog healthcare implementation?
The main drivers are the number of log sources, how much parsing and redaction each source needs, how many environments must be built (test, staging, production), and the high availability sizing you choose. A fixed-scope quote follows from a written list of sources, data types, retention periods and environments. Each source that needs custom parsing or field-level masking of patient identifiers adds design and test work, and a clustered deployment adds build and verification work over a single node. Software licensing is a separate line. Ask for the quote to show each of these items so you can see what changes if scope changes.
How much does Graylog licensing cost for a health system?
Graylog Open is free with no volume limits and community support. Graylog's pricing page lists Graylog Enterprise from 15,000 US dollars per year and Graylog Security from 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Those are list figures from that page and should be confirmed there before budgeting. Enterprise adds features such as the data lake with archive restore, data tiering and 24/7 support, and Security adds SIEM features. Decide which of these your monitoring duties need, since licensing recurs annually while implementation is usually a one-time project.
How long does it take to get Graylog live for a hospital?
The duration depends on the number of sources, whether you need a clustered build, how many EHR and identity systems must be onboarded, and how long your change approvals take. Install, parsing and dashboard work can run in parallel with access reviews, but patient data handling and retention decisions often need sign-off from privacy and security owners before production ingest starts. Timelines should be stated in the written scope, not assumed. Ask any partner to show the phases, the dependencies on your own teams and the test evidence each phase produces.
What must our team provide before a Graylog project starts?
Plan to provide the following before work begins:
- Read access or exported samples from each EHR, identity and network source, along with vendor documentation for their log formats
- A data classification for each log type that states which fields are protected health information
- Named owners for security monitoring, privacy, the EHR application, identity and infrastructure
- Decisions on retention periods, who may search logs and who approves access
- Network paths, certificates and a test environment that matches production
Missing owners or sample data are the most common causes of delay, so confirm them in the scope document.
Can our own team build and run Graylog without a partner?
Yes, many teams do, provided they have engineers who can operate Linux servers, MongoDB, a search backend and load balancing, and who can write parsing rules and event definitions. Graylog's installation documentation covers packages, Docker Compose and multi-node layouts, and the multi-node guide recommends three Graylog and MongoDB nodes, three Data Nodes and a load balancer for medium to large deployments. The questions to answer honestly are whether anyone can own upgrades, backups and capacity over time, and whether the team can document the controls an auditor will ask about. A partner is useful when those skills or hours are missing for a fixed period.
How do we size Graylog log retention for healthcare?
Graylog's system architecture guidance advises sizing log storage as daily ingest multiplied by retention days multiplied by 120 percent. For example, an illustrative site ingesting 50 GB per day and keeping 365 days would plan for 50 times 365 times 1.2, or 21,900 GB, before indexing overhead is reviewed. Retention length should come from your legal and policy owners, not from the storage math. Add the message journal sized at 3 to 5 times daily ingest on SSDs, as the same guidance describes, and confirm which logs must be kept in searchable storage and which can move to archives.
Does Graylog alone make us HIPAA compliant?
No. Graylog is a tool that can collect, retain and help review audit logs, but HIPAA's Security Rule applies to your organization and its business associates for all electronic protected health information, and it requires policies, risk analysis, access control, workforce procedures and documented decisions. HHS states that no Security Rule standard requires certification and that HHS does not recognize private certifications, so no tool or vendor can grant HIPAA compliance. Graylog can support technical audit control evidence, but the program around it is your responsibility, and independent assessors or the HHS Office for Civil Rights judge the outcome.
How do we keep patient data out of Graylog logs?
Start by classifying which fields in each source can carry identifiers such as names, record numbers or dates of service, then decide whether to drop, mask or pseudonymize them at ingest. Graylog processing pipelines can apply these changes before messages are indexed, and access rules can limit who sees raw fields. Test redaction against real sample messages from each EHR and identity system, because a single unmasked field in a verbose error message can expose patient data. Document the rules, the owners who approve them and the test results, since these become part of your audit evidence.
Planning retention and restricting who can search audit logs
Set the retention period from your written log retention policy and advice from counsel, not from a Graylog default. Graylog manages storage through index sets: each index rotates by message count, size or time, and retention then deletes the oldest indices. That means the retention you configure is only as long as the indices that still exist, so the rotation strategy and the number of retained indices must add up to the period your policy requires. The HIPAA Security Rule does not set a fixed log retention period, but it does require documentation of policies and procedures, and your audit control evidence must still be available when an investigator or the HHS Office for Civil Rights asks for it. Confirm with your compliance lead which records must survive, how long each must be kept, and whether any records belong in a separate index set with its own rotation. Before you go live, test a deletion cycle in a non-production environment so you know exactly what Graylog removes and when.
Separate search rights by job function. Security staff usually need broad search across authentication, EHR access and network events, while compliance reviewers need read access to specific audit streams and clinical IT may need only the systems they operate. Build these as Graylog roles and grant index set and stream permissions per role instead of giving everyone the built-in Admin role. Decide who can save searches, share dashboards and export results, because a shared export can leave the access boundary your design intended. Log access to Graylog itself as well: administrator logins, role changes, search activity on sensitive streams and changes to retention settings should be retained and reviewed. Confirm which of these audit trails your Graylog edition and version produce, and whether they can be forwarded to a separate, protected store. Also plan the emergency access procedure, which the Security Rule treats as a required specification, by defining a break-glass account that is held offline, used only under a documented trigger and reviewed afterward.
Archive and restore needs a separate decision. Graylog Open can delete old indices through retention, but Graylog Enterprise documents a data lake with archive restore and data tiering. Treat these as capabilities to confirm for your edition and version before you design around them, since they change how long data remains searchable and how quickly a restore can happen. Ask the vendor or your implementation partner to confirm the archive, restore and tiering behavior against your exact release and your license terms, and record the answers in the retention plan so auditors can trace each decision.
How DeployOpen scopes and delivers Graylog for healthcare
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Graylog deployments for healthcare organizations. Work starts with a written scope that defines which systems, log sources, roles and retention rules are covered before any build begins.
How we scope
- Inventory the EHR, identity, VPN and remote-access systems whose audit events Graylog must receive
- Agree in writing which log sources, retention periods and search roles are in the engagement
- Confirm where the Graylog nodes, Data Nodes and MongoDB will run and who can administer them
- Identify which fields could contain patient data and decide how they are handled before ingest
How we build
- Deploy Graylog server nodes, MongoDB and Data Node in the environment you control, following Graylog's documented multi-node layout
- Configure inputs, streams and processing pipelines for EHR, identity and network audit events
- Set index rotation and retention to match the retention plan agreed in the scope
- Test ingest, search access restrictions and alert notifications against the documented scenarios
How we hand over
- Deliver configuration, role mappings and retention settings as documented, versioned artifacts
- Provide runbooks for backups, journal monitoring, user access reviews and index retention checks
- Map delivered controls to the HIPAA Security Rule standards in scope, so your compliance team can review evidence
- Walk your administrators through operations, and record open items for your own team to confirm
How we support
- Support is available as a retainer for upgrades, patching, monitoring and changes to log sources
- Upgrades are planned around Graylog's documented breaking changes and version compatibility requirements
- Continuous security testing of the deployment can be added to the retainer where your scope includes it
- DeployOpen prepares evidence for your assessors; independent auditors issue any audit report or attestation
