Graylog for government and public sector

Graylog for government and public sector: why agencies self-host log management

An agency or public body that must produce audit logging evidence under NIST SP 800-53, the FBI CJIS Security Policy or CMMC can self-host Graylog so that log data stays inside its own network, under its own administrators and retention rules. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, and that matters for procurement and legal review before any build starts. Graylog 4.0 introduced this license in 2020, replacing GPL v3 for earlier releases, so confirm the license terms of the exact edition and version you plan to deploy against the LICENSE file in the Graylog repository. Self-hosting does not make a system compliant. DeployOpen prepares the controls, configuration and evidence, and independent auditors and assessors decide whether they meet the requirement.

A Graylog deployment has several parts that each need an owner. Graylog server nodes ingest, process and search logs. MongoDB holds configuration and metadata, and a Graylog Data Node or self-managed OpenSearch holds the log indices. For a public body, the practical change is that every one of these components, including the message journal and the backups of both databases, sits in infrastructure the agency or its authorized hosting provider controls. Agencies should confirm where each component runs, which administrators can reach it, and whether any vendor or support access path can read stored messages. Those answers feed the system boundary and the assessment scope, so they should be written down before the sizing exercise begins.

Two decisions shape the audit evidence most. The first is which logs are in scope for each control family, so that authentication, privileged activity and configuration changes reach Graylog and can be shown to reviewers. The second is who may search sensitive logs, since role-based access in Graylog determines whether a support analyst can read records that belong to another agency function. Confirm these design points with your assessor and your compliance office early, then have DeployOpen document the resulting configuration and test it. For cloud hosting and CMMC scope questions, check the applicable FedRAMP and 32 CFR 170 requirements with your contracting officer rather than assuming a self-hosted platform falls outside them.

Which public sector requirements shape the Graylog build

This table maps each public sector requirement to what it means for where Graylog runs, how log data is encrypted, who can search it and how long it is kept. Read each row as a design input to settle before installation, and confirm the final scope with your assessor, contracting officer or compliance lead.

Requirement	What it asks for	Graylog build impact
NIST SP 800-53 Rev. 5 baselines	Low, moderate and high baselines select 149, 287 and 370 controls and enhancements, matched to system impact level	Confirm the impact level first, since it sets how many audit, access and integrity controls the Graylog stack must evidence
FISMA and Inspector General reviews	Agencies assess system security under FISMA, and Inspectors General independently review that assessment and report to OMB	Keep Graylog configuration, index set settings and role assignments documented so reviewers can trace log coverage to the system boundary
FedRAMP scope under M-24-15	Cloud services that store or process federal information on behalf of an agency are in scope, while single-agency systems not offered as a shared service are out of scope	Decide whether a hosted or managed Graylog service is in scope before choosing it, and confirm the boundary with your authorizing official
CJIS Security Policy v6.1 encryption	FIPS 140-3 validated modules or AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations	Verify that TLS on inputs and the Graylog web interface, and encryption of index and backup storage, meet the approved module and key-length requirements
CJIS Security Policy v6.1 scanning	Vulnerability scanning at least monthly for systems in scope	Include Graylog server nodes, MongoDB, Data Nodes and load balancers in the scan schedule and retain the scan results
32 CFR 2002.14(h)(2) for CUI	Agencies apply NIST SP 800-171 requirements to protect controlled unclassified information on non-federal systems, unless the CUI category sets other safeguards	Treat log events that contain CUI as protected data, restrict search and export to named roles, and confirm the safeguards with the CUI category owner
32 CFR 170.17(c)(5) for CMMC cloud use	A CMMC Level 2 contractor may store or process CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements	If Graylog logs contain CUI and run in a cloud, confirm the provider's authorization status before ingesting those sources
NIS2 public administration scope	Central government entities are covered regardless of size, and public administration is a sector of high criticality, with some national security, defense and law enforcement activities excluded	Confirm with counsel whether your entity is covered and which Member State rules apply, since that determines the incident logging and retention duties Graylog must support

Where Graylog can run: sovereign cloud, government data center or air-gapped network

The hosting decision comes first because it determines which assessment questions apply. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure are out of scope when they are not offered as a shared service (see the FedRAMP scope rules). A self-hosted Graylog in the agency's own accounts or data center is therefore a different question from a SaaS SIEM, where the provider's authorization status and boundary decide much of the inherited control picture. Confirm with your authorizing official and assessor how a self-managed deployment in your own infrastructure will be scoped, and document which hosting environment holds the Graylog server nodes, MongoDB, the Data Node cluster and the archive storage.

Offline installation changes the build sequence. Graylog's installation documentation names Debian and RPM packages on Ubuntu, Red Hat, SUSE and Debian, and Docker Compose as the supported install paths, so every package, repository mirror and container image needed for the initial build and later patches must be staged inside the boundary before the first node is built. Plan a transfer process that records a hash for each artifact and keeps the staging repository under the same change control as the production build. Graylog Security requires OpenSearch 2.0 or later, and use of OpenSearch 1.x has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so a sovereign deployment that starts on older storage will need a migration step before it can adopt Security features or a later major release.

Offline update procedures are the item most likely to be assumed rather than tested. Ask Graylog, in writing, for the offline upgrade and patch steps for the exact version you plan to run, including how the Data Node and MongoDB packages are supplied, what the compatibility matrix requires for each component, and whether any step contacts an external service. Then rehearse one full patch cycle in a non-production enclave before accepting the design, and record the result as evidence for your vulnerability management and change control controls.

Choosing a deployment model for a public body

This model runs Graylog in a cloud account or subscription the agency controls, in a region approved for its data. Outbound connectivity is available, so packages, container images and license validation can reach their sources directly, which makes routine upgrades simpler to schedule. The core design is still the multi-node pattern used for any production install, and managed cloud services are used only where they sit inside the agency's authorization boundary.

Staging: Mirror Graylog packages or container images into an agency-controlled repository, so every upgrade passes through the agency's change control and can be pinned to a tested version.
Updates and licensing: Graylog Open does not need a license key, but Enterprise and Security licenses apply to processed data. Confirm how license validation traverses the cloud network controls the agency uses.
Edition questions: Decide whether archive restore, data tiering or 24/7 support from Enterprise is needed, and whether SIEM features from Security are part of the scope. Use the Graylog pricing page for licensing terms only.
Identity: Open supports Active Directory, LDAP and trusted header authentication, while SAML, OpenID Connect and Okta require Enterprise. Confirm which fits the agency's federated login requirements.
Boundary: Federal cloud rules cover services that store or process federal information for an agency, so check each managed storage, load balancer or database service against that agency's authorization.

Before the build, confirm with the authorizing official which cloud services fall inside the boundary and which edition the agency will license.

Which Graylog settings matter for government logging

Government logging depends on a few Graylog settings working together: how long data is kept, which sources are separated, who can sign in and how the platform is sized. Each card below covers one setting an agency or public body should decide early, because changing it later affects evidence, access and cost.

Index sets and retention rules

Each index set defines how messages are stored and when old data is removed. Rotation can be triggered by message count, index size or time, and retention deletes the oldest indices once the limit is reached. Map each log category to its required retention period before creating index sets, and confirm with your records and audit owners that deletion of the oldest indices meets the period in your policy. Confirm which retention is needed for archived copies outside the live index set.

Streams and processing pipelines

Streams route incoming messages to index sets, and processing pipelines parse, enrich or drop them. For government work, use streams to keep sensitive sources such as identity systems, classified or controlled network segments and case-management applications in their own index sets. Pipeline rules should be reviewed as changes, since a parsing mistake can silently send sensitive fields to a broader audience than intended.

Authentication options by edition

Graylog Open supports Active Directory and LDAP authentication and trusted header authentication. Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. Agencies that require central identity and multi-factor controls should confirm early whether their identity provider works through LDAP in Graylog Open or needs an Enterprise license for SAML or OpenID Connect, since this decides both the edition and the access review process.

Sizing storage from daily ingest

The system architecture guidance advises sizing log storage as daily ingest multiplied by retention days and then multiplied by 120 percent. Measure daily ingest from a representative period rather than estimates, because retention for government records often runs longer than default settings. Ask your vendor or integrator to show the calculation for each index set so that storage requests can be traced to the retention decisions.

Message journal sizing on SSDs

The message journal buffers incoming messages before they are written to storage. The architecture guidance recommends giving the journal 3 to 5 times daily ingest on SSDs. A undersized journal is a common cause of lost or delayed evidence during peaks, such as a burst of firewall or identity events, so confirm the journal size and disk type in the design review and test it under load before go-live.

Event definitions and notification channels

Event definitions turn searches into alerts for real-time and historical monitoring. Graylog Open product materials name PagerDuty, Slack and email as notification channels. For public-sector duties, define which events must reach a named on-call role, confirm that email and chat destinations are approved for the data classification involved, and document who reviews each alert and how the review is recorded.

Limiting who can search sensitive logs

Search access to logs is itself a sensitive control for agencies. Logs routinely carry personal data, case references, badge and account identifiers, and internal system details that may be controlled unclassified information (CUI). An analyst who can search everything can reconstruct a case or an individual's activity even if no one exports a file. Before building dashboards, decide which log sources hold restricted data, who may read each class, and which people must be kept out of it entirely, such as contractors on an unrelated program. Write that decision down, because an assessor will ask to see how search access maps to it.

Separate the data by classification at the point of collection. In Graylog, streams route messages into index sets, so sensitive sources such as case management, identity or criminal justice systems can be routed to their own streams and index sets rather than mixed into general infrastructure logs. Then grant roles access to specific streams and index sets, and restrict dashboards and saved searches to the groups that need them. Sharing features and the depth of role management differ by edition, so ask Graylog in writing which role, index set permission and dashboard sharing controls your edition provides, and test them with a non-administrative account before go-live.

If any log data falls within the scope of the FBI CJIS Security Policy, the encryption requirements apply to the logs as well as the source systems. Version 6.1 requires FIPS 140-3 certified cryptographic modules, or FIPS 197 AES with keys of at least 256 bits, for criminal justice information in transit and at rest outside physically secure locations. Confirm with Graylog which cryptographic modules its server, Data Node or OpenSearch backend, and MongoDB use, and whether those modules carry a FIPS validation that applies to your deployment. Have your assessor review that evidence, because the validation status of a module is a fact to verify, not one to assume from a product name.

How a public sector Graylog rollout runs

A public sector Graylog rollout moves in sequence: fix the authorization boundary first, then size, install and harden offline, and only then onboard sources and retention. Each phase ends with evidence an assessor can review.

Define the boundary and scope with the SSP owner
Start by agreeing with the system security plan owner which systems, log sources, users and hosting locations fall inside the Graylog boundary. DeployOpen maps where log data will be stored, who can search it and which external services, if any, the deployment touches. The step is done when the scope statement and data flow diagram are signed off by the agency owner and the authorizing official's delegate, so later design decisions have a fixed target.
Select the control baseline and map requirements
Confirm the applicable framework and impact level before design begins. NIST SP 800-53B defines low, moderate and high baselines, and the agency's categorization determines which set applies. DeployOpen maps the logging, audit review, access and retention controls in that baseline, and any overlays or CUI, CJIS or CMMC obligations, to specific Graylog configuration items. The output is a traceability matrix that names each control and the Graylog feature or procedure that satisfies it.
Design the architecture and size storage
Choose the topology for an isolated environment: Graylog server nodes, MongoDB as a replica set, a Data Node cluster, load balancing and the message journal. Storage sizing follows the documented formula of daily ingest times retention days times 120 percent, with the journal on SSDs. Ask the team to confirm ingest volumes from the actual sources, since estimates drive disk and cluster costs. The step closes with a reviewed architecture document and sizing worksheet.
Stage the offline installation and harden the hosts
Build an offline repository for packages, container images and the operating system updates, then install Graylog, MongoDB and Data Node from that staged media. Harden the hosts, restrict network paths between components and disable services that are not required. Every package is checked for integrity and authenticity before it crosses the boundary. The step is complete when a clean install reproduces from the staged media and the hardening baseline passes an internal check.
Onboard sources and validate parsing
Connect hosts, network devices, identity systems and applications through the inputs the environment supports, and route them into defined streams. Processing pipelines normalize fields so that authentication, privileged activity and configuration changes can be found consistently. Test each source with known events and confirm that timestamps, sources and fields are correct. The output is a source inventory showing what is collected, from where, and what is known to be missing.
Configure the access model and audit trail
Define roles and index set permissions so that only authorized staff can search sensitive streams, and record administrative and search activity. Confirm which authentication method the edition supports, such as directory integration or single sign-on, and document how accounts are provisioned and removed. Test that a user without a role cannot view restricted data and that the audit records capture the expected actions. The step closes with an access matrix and audit test results.
Design retention and archive, then capture assessor evidence
Set index rotation and retention to match the records schedule and the baseline's audit retention expectations, and design any archive or restore path for older data. Run a test of rotation, retention deletion and restore, then collect evidence: configuration exports, screenshots of settings, test records, scan results and review logs. DeployOpen prepares this evidence and the procedures, while independent assessors decide whether the controls meet the requirement. The output is an assessor-ready evidence package mapped to the traceability matrix.
Hand over operations with runbooks and review cadence
Transfer the running system to the agency's operators with runbooks for monitoring the cluster, handling journal problems, applying patches through the staged offline process, taking backups and reviewing audit logs. Agree who performs periodic log reviews and how exceptions are escalated. The handover is complete when the operators have run the runbooks themselves in a supervised session and the review responsibilities are written into the system security plan.

Compliance questions an agency has to answer about its logs

Agencies and public bodies face several overlapping log obligations, each set by a different authority with its own assessor. The cards below separate the questions by framework so the Graylog design answers each one with evidence the right reviewer will accept. Graylog produces collection and retention evidence only; DeployOpen does not issue audit reports or certifications, and independent assessors make those determinations.

NIST SP 800-53 audit and monitoring controls

The audit and monitoring families in SP 800-53 Rev. 5 define what events must be generated, how long they are kept, and how they are reviewed. SP 800-53A gives assessors a procedure for each control, with examine, interview and test methods, so the same question appears in the assessment plan. Before the build, map each audit requirement to a Graylog input, stream, index set and retention setting, then check that a reviewer can reproduce the evidence from the Graylog search history and configuration. Confirm the control identifiers against the current release, since Release 5.2.0 changed several audit-related controls.

How baselines narrow the work

SP 800-53B selects control subsets by impact level, so a low system and a high system carry very different logging obligations. The published OSCAL profiles count the selected items, which lets an agency scope its Graylog work before it writes a single pipeline rule. Decide the impact level of each system that sends logs, decide whether Graylog is inside that authorization boundary, and document which controls Graylog supports and which the surrounding platform must cover. Ask the authorizing official to confirm the baseline in writing.

FISMA reporting and Inspector General review

Under FISMA, Inspectors General independently assess agency system security and report to OMB, so log records must hold up to an outside reader who did not build the system. Plan for evidence requests that ask for proof of log collection gaps, retention periods, and who could search or alter logs. Keep configuration exports, change records for event definitions, and access logs for the Graylog administrators themselves. The agency decides what goes into its reporting, and the Inspector General decides what it tests.

CJIS Security Policy v6.1 scanning and encryption

Systems that handle criminal justice information fall under CJIS Security Policy version 6.1, which took effect on 26 June 2026. For CJI in transit and at rest outside physically secure locations, the policy calls for FIPS 140-3 validated modules or AES with 256-bit keys, and vulnerability scanning at least monthly. Graylog collectors, node-to-node traffic, and the search backend all need to meet that bar where CJI-bearing logs cross a boundary. Confirm with your CJIS Systems Agency which log fields count as CJI before you define the encryption and access scope.

CMMC and CUI handling under 32 CFR 170 and 2002

A defense contractor seeking CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. Agencies that share CUI with contractors also use NIST SP 800-171 for protecting CUI on non-federal systems under 32 CFR 2002. A self-hosted Graylog in the contractor's own boundary keeps the logging system inside that assessment scope, so the question is which systems in the log path hold CUI. Map every forwarder, node and archive location, then ask the assessor how each one is scoped.

NIS2 scope for public administration

NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration, and it does not apply to entities working in national security, public security, defense or law enforcement. Those exclusions decide whether a given agency's logging falls under NIS2 incident-detection duties at all, so the first task is confirming the entity's legal status in its own Member State. Graylog can support detection and reporting workflows, but the obligation belongs to the entity.

Questions agencies ask before a Graylog build

What drives the cost of a Graylog build for a public body?

The biggest cost drivers are the edition, the volume of data you process, the number of servers and the storage you keep. Graylog Open is free with no volume limits and community support, but a public body that needs features such as the data lake, correlation engine, 24/7 support, or SIEM capabilities will license Graylog Enterprise or Graylog Security. According to the Graylog pricing page, those editions start at 15,000 and 18,000 US dollars per year respectively, with a minimum of 10 GB per day or 100 Graylog Compute Units, and licensing is based on processed data with no per-user or per-device fees. Infrastructure is a separate cost, and storage follows daily ingest, retention days and a 120 percent headroom factor from the Graylog architecture guidance. Ask any partner for a quote that separates licensing, hardware or cloud capacity, implementation and recurring support.

Can a public body run a Graylog deployment with its own team?

Yes, if the team has Linux, database, search backend and security operations skills and enough people to run it every day. The installation options are Debian or RPM packages and Docker Compose, and the multi-node guide describes three Graylog and MongoDB nodes, three Data Nodes, and a load balancer for medium to large deployments. The harder parts are ongoing: patching across several tiers, matching the compatibility matrix on each upgrade, managing index rotation and retention, and keeping alert content current. Teams often outsource the initial build and the compliance evidence design, then keep operations in house. Confirm internal staffing for on-call coverage, access reviews and upgrade windows before deciding.

How long does a Graylog build take for an agency?

The duration depends on the number of log sources, how many environments are involved, whether the network is restricted, and how much classification and retention design must be agreed before configuration starts. Sources that need custom parsing, forwarders in segmented networks, and role-based access rules for sensitive logs add time. Approval cycles inside the agency and change control windows often set the pace more than the technical build. A fixed-scope agreement, signed in writing before work starts, lets both sides agree the phases, deliverables and dependencies. Ask for a timeline that lists the decision points that need agency sign-off.

What must the agency provide before implementation starts?

The agency should prepare the inputs that a partner cannot infer from the platform itself. These usually include:

Network diagrams showing log sources, segments, boundaries and the paths logs take to Graylog
Data classifications that state which logs contain controlled or sensitive information
Written retention rules that match the records schedule and any framework requirements
Named staff for access reviews, including who approves roles for sensitive log search
Change control contacts, maintenance windows and approved image or package sources

Without these, configuration decisions such as index sets, streams and role design have to be guessed, which is costly to correct later.

Are air-gapped Graylog installs harder than connected ones?

Yes, because every package, container image, plugin and content update must be staged inside the isolated network and verified before it crosses the boundary. The Graylog installation options assume package or image retrieval, so the team needs a mirror or transfer process, a tested offline update procedure and a record of what was imported. Vulnerability and threat content also needs an update path that does not depend on internet access. Other open-source platforms document offline installs, such as Security Onion's airgap mode and Wazuh's offline guide, which shows the general pattern. Confirm the exact offline steps and which features need a licensed edition with the vendor before the design is fixed, and plan a staging environment to rehearse each update.

Why does a partner's written scope matter for assessors?

Assessors judge what is documented, tested and repeatable, so a written scope shows which systems, log sources, controls and responsibilities the Graylog build covers. NIST describes SP 800-53 controls as implemented through an organization-wide risk management process, and it does not endorse compliance programs or estimate compliance costs, so the agency must own the mapping. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. A written scope fixes the deliverables, such as configuration records, retention settings, access role definitions and test results, so the evidence trail matches what the assessor will request.

Which Graylog features need a paid edition for public sector logging?

Core ingestion, search, dashboards, streams, pipelines and retention are part of Graylog Open, which is licensed under SSPL-1.0 and is not an OSI-approved open source license, a point procurement teams should review with their legal office. Authentication is a practical example: Graylog Open supports Active Directory, LDAP and trusted header authentication, while Okta, generic OpenID Connect and SAML single sign-on require Graylog Enterprise. Archive restore, data tiering and the correlation engine also belong to Enterprise, and SIEM features such as investigations, compliance packs and prebuilt detection content belong to Graylog Security, according to the Graylog product and pricing pages. Map each required capability to an edition before the budget is set.

How DeployOpen scopes and delivers Graylog for public bodies

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For public bodies, that means Graylog is designed around the agency's own authorization boundary, access rules and retention duties, with the written scope agreed before any work starts.

How we scope

We confirm which systems send logs, which framework requirements the agency must evidence, and where the hosting boundary sits.
The written scope names Graylog edition needs, OpenSearch or Data Node backend, MongoDB design and retention periods before work starts.
Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before the build begins.

How we build

We install Graylog server nodes, MongoDB and the search backend in the agency's environment, following the documented multi-node layout.
Inputs, streams, processing pipelines, index sets and role-based access to sensitive log streams are configured and tested against the scope.
Security testing and configuration checks run against the deployed Graylog cluster before handover, with findings tracked to closure.

How we hand over

Documentation covers architecture, access roles, retention settings, backup steps and the evidence each control produces.
Operators are trained on search, alerting, index rotation and journal monitoring so the agency's team can run the platform.
We prepare the systems, controls and evidence for the agency's assessment, while independent auditors perform the assessment itself.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Upgrade planning covers documented breaking changes, runtime and database prerequisites and parsing changes before each Graylog version change.
Support scope, response expectations and review cadence are written into the retainer so agencies can plan staffing around them.

Graylog for government and public sector