How Graylog supports CIS Controls audit log management
An organization that must show audit logging, central collection, 90-day retention and weekly review under CIS Controls v8.1 needs a system that can collect those logs, store them, search them and raise events for review. Graylog can supply those mechanisms for Safeguards 8.2, 8.9, 8.10 and 8.11 through inputs, streams, index retention and event definitions. The policy, the asset scope, the staffing and the decision about what counts as an unusual or abnormal event remain the organization's own responsibility. CIS publishes the Controls under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 license and states that they are free for any organization to use to improve its own cybersecurity. CIS also states that the Controls do not replace any regulatory, compliance or authorization scheme.
CIS does not certify organizations against the Controls, and DeployOpen does not issue audit reports, attestations or certifications. DeployOpen configures the Graylog deployment, documents how each Safeguard is met and assembles the evidence a reviewer would sample, such as input configuration, index set retention settings, event definitions and review records. An independent assessor decides whether that evidence is sufficient for the organization's purpose. Before work starts, confirm with your assessor or internal audit which evidence they expect, since CIS's Controls Assessment Specification describes what to measure for each Safeguard but leaves the method to the implementer.
The practical starting point is to map each Safeguard to a Graylog configuration element and an owner. Safeguard 8.10 depends on index retention, so confirm that the index set rotation and retention settings keep at least 90 days of audit logs in the place your reviewers can reach. Safeguard 8.11 depends on a scheduled review, so decide who reviews dashboards and event notifications each week and how that review is recorded. Graylog Open provides the search, dashboard and event definition features needed for this work, but the edition that adds a given detection or notification capability should be checked against the current Graylog documentation before you commit to a design.
Mapping Safeguards 8.2, 8.9, 8.10 and 8.11 to Graylog capabilities
This table maps each of the four audit log Safeguards to the Graylog inputs, streams, pipelines, index retention, dashboards and event definitions that support it, along with the setting to check. Read it as a build list: the Graylog column shows what to configure, and the final row covers the part of Safeguard 8.11 that no tool satisfies on its own.
| Safeguard | Requirement in plain language | Graylog capability and configuration |
|---|---|---|
| 8.2 Collect audit logs | Turn on audit logging on enterprise assets and collect those logs as the audit log management process defines. | Inputs (syslog, GELF or Beats) receive events from servers, endpoints, network devices and applications. Confirm each source has audit logging enabled and forwards to the correct input port. |
| 8.9 Centralize audit logs | Bring audit log collection and storage for enterprise assets into one central place as far as possible, such as a SIEM that gathers many sources. | Route all inputs into Graylog server nodes behind a load balancer. Use streams to separate audit events by source type and pipeline rules to normalize fields so one search covers all assets. |
| 8.10 Retain audit logs | Keep audit logs for at least 90 days. | Set index set rotation and retention so the oldest indices are deleted only after 90 days. Confirm index sizing against daily ingest, retention days and the 120 percent guidance in the Graylog architecture page. |
| 8.11 Review audit logs | Review audit logs at least once a week for unusual or abnormal events that could indicate a threat. | Build a dashboard of authentication, privilege and configuration events. Create event definitions with thresholds and notifications to email or chat so reviewers see anomalies between scheduled reviews. |
| Weekly review process (8.11) | A documented process must define who reviews, what they check, how findings are recorded and how the review is evidenced. | Graylog supplies the dashboards and alerts, but it does not run the weekly review. Write the procedure, assign owners, keep review records and confirm with your assessor what evidence they expect. |
How the Graylog architecture carries audit logs from assets to review
The architecture question for Safeguard 8.9 is whether every enterprise asset that produces audit logs has a documented path into one Graylog cluster. Sources send events over Graylog inputs such as syslog, GELF or Beats. Graylog server nodes receive them, the message journal buffers them on disk, and processing pipelines and streams decide which stream each message lands in. Each stream maps to an index set, so the team that owns a log source controls where its data is stored and how long it stays searchable. Before go-live, confirm which inputs each asset class needs, since some inputs and collectors are documented differently across editions.
Storage and metadata live in two separate places. MongoDB holds configuration, users, streams, event definitions and other metadata, while log messages sit in Graylog Data Node, which Graylog recommends as the search backend, or in a self-managed OpenSearch cluster. Event definitions run against the stored data and send notifications when a condition matches, which is how the weekly review required by Safeguard 8.11 can be backed by automated alerts rather than manual searching alone. Use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so a new build should start on Data Node or a supported OpenSearch line. Confirm the exact compatibility pairing for your chosen version in the Graylog compatibility matrix before ordering hardware.
The Graylog multi-node guide is the documented baseline for medium to large deployments: three Graylog server nodes and three MongoDB nodes running as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes, with is_leader set to false on follower nodes. Storage sizing follows the architecture guidance of daily ingest multiplied by retention days and by 120 percent, and the message journal should be sized at 3 to 5 times daily ingest on SSDs. Multi-node and Data Node capabilities need the right edition, so confirm with Graylog which features your Graylog Open, Enterprise or Security license covers before committing to the layout. Ask your team to document the 90-day retention target for Safeguard 8.10 against this sizing model, since storage is usually the largest recurring cost in the design.
Evidence Graylog produces for each Safeguard and how to keep it
Graylog holds much of the proof a reviewer will ask for under Safeguards 8.2, 8.9, 8.10 and 8.11, but it does not store that proof in an audit-ready form on its own. The CIS Controls Assessment Specification defines what to measure for each Safeguard, and the reader must decide how to capture, store and date each artifact.
Collection coverage reports
A coverage report compares the list of enterprise assets that should send logs with the sources Graylog actually receives from. Build it from your asset inventory and the inputs, streams and sender lists configured in Graylog, then export it on a schedule. Check for silent sources, because a host that stopped sending is the gap a Safeguard 8.2 reviewer will look for first. Keep each export dated so it shows coverage over time, not just on one day.
Index retention settings as configuration
Retention in Graylog is set through index rotation and the deletion of the oldest indices, so the active settings define how long audit logs survive. Export the index set configuration and the rotation and retention policies as files under version control, not screenshots. Record each change with a reason and an approver. Compare the exported values against the retention period your audit log management process sets for Safeguard 8.10.
Dashboard and search history for review
Safeguard 8.11 expects audit logs to be reviewed at least once a week. Saved searches and dashboards show what the reviewer looked at, but they do not prove the review happened. Ask whether your setup records who opened each dashboard, when, and which time range they used, and whether that record can be retained outside Graylog. Confirm this against your Graylog edition and audit trail settings before you rely on it.
Event definition configuration and notifications
Event definitions are the rules that turn log patterns into alerts for unusual or abnormal activity. Export each definition with its query, aggregation conditions, priority and notification target, and keep the file under change control. Keep a notification record as well, showing when an alert fired and who it reached. A reviewer will test whether the rules catch the events your process names, so map each definition to the event it covers.
Weekly review sign-off records
A review sign-off record names the person who reviewed the logs, the period covered, the findings and any follow-up tickets. Use the same template every week so the set reads as one control, not a pile of notes. Store sign-offs in a system that the reviewer cannot edit after the fact. Your audit log management process should name who signs, who backs up a missed review, and how a missed week is escalated.
Configuration choices by environment size and sensitivity
A single Graylog server node with MongoDB and a single search backend suits a small, low-complexity estate where the audit log sources are few and the log volume is modest. CIS describes Implementation Group 1 as essential cyber hygiene and a minimum standard for every enterprise, so this shape can cover the basic collection, central storage and weekly review expectations if the sources and processes are right. It does not provide redundancy, so a single failure can stop collection or search.
- Collection scope: Confirm that the enterprise assets in scope for Safeguard 8.2 all send logs to the one node over supported inputs.
- Retention capacity: Size index storage from daily ingest, retention days and the 120 percent guidance in the system architecture documentation.
- Journal sizing: Give the message journal 3 to 5 times daily ingest on SSDs.
- Access: Use the built-in authentication options available in Graylog Open, such as LDAP or Active Directory, and restrict who can read audit data.
- Gap risk: Accept that a node outage creates a collection gap, and document how the team will detect it.
Check with your auditor whether a single-node design meets your evidence expectations for availability and retention before you commit to it.
The Graylog multi-node guide describes a layout 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. Follower Graylog nodes run with is_leader set to false. This layout suits estates with more sources, more sensitive assets and a stronger need for continuous collection, which aligns with the scope CIS sets for Implementation Group 2.
- Replica set: Deploy MongoDB as a replica set across the three nodes so configuration survives a node loss.
- Data Node cluster: Keep the three Data Nodes separate from the Graylog servers so search load and storage fail independently.
- Load balancer: Route inputs and user traffic through the balancer and test failover before go-live.
- Leader setting: Set
is_leadertofalseon followers and confirm exactly one leader. - Recurring cost: Plan for the extra hosts, licenses for the platform and the operations time to patch and back up each tier.
Confirm the supported MongoDB and OpenSearch or Data Node versions against the compatibility matrix for your target Graylog release before you size the cluster.
Some features that help with Safeguards 8.9, 8.10 and 8.11 sit in Graylog Enterprise or Graylog Security rather than Graylog Open. Enterprise adds archive restore, data tiering, a correlation engine and 24/7 support. Security adds SIEM features such as investigations and compliance packs. Pricing on the Graylog pricing page starts at 15,000 US dollars per year for Enterprise and 18,000 US dollars per year for Security, with a minimum of 10 GB per day or 100 Graylog Compute Units, and licensing is based on processed data. Those figures are list prices from the vendor and may change, so ask for a current quote.
- Archive restore: Useful when a review or investigation needs logs older than the searchable window.
- Data tiering: Can lower the cost of keeping 90-day or longer retention searchable.
- Correlation and investigations: Support multi-event review and structured triage records.
- Enterprise single sign-on: Okta, generic OpenID Connect and SAML are Enterprise features, while Graylog Open supports Active Directory, LDAP and trusted header authentication.
- Support: Ask whether 24/7 support is needed for the review cadence you commit to.
Ask the vendor which features are included in the license you are quoting, and confirm the licensed volume covers your ingest.
When the audit logs cover systems that hold sensitive data, or the enterprise faces targeted attacks, CIS describes Implementation Group 3 as the tier for enterprises with security specialists and regulated, sensitive assets. The Controls alone do not replace any regulatory scheme, so this tier adds controls around the Graylog platform itself: separate administrator access, protected backends, tested recovery and documented review records. The same design can serve several frameworks through the CIS Controls Navigator, but it still needs its own verification.
- Separation of duties: Keep log administrators apart from the teams whose activity is being logged.
- Backend protection: Restrict access to MongoDB and the Data Node cluster, and encrypt traffic between components.
- Tamper evidence: Record changes to event definitions, streams and retention settings.
- Recovery: Test restoration of indices and configuration from backups.
- Review evidence: Keep weekly review records that show what was checked and what was escalated.
Ask your assessor which Implementation Group and framework mappings they will use, and confirm the tier you choose matches the sensitivity of the assets in scope.
What Graylog and this implementation do not cover
Graylog collects, stores and searches logs, but several CIS Safeguard 8 outcomes depend on work outside the platform. The cards below set out those boundaries so your team can assign owners before the build starts. This implementation prepares configuration and evidence; it does not issue certification or attestation, and independent assessors make those determinations.
Asset inventory and log process scope
Safeguard 8.9 asks you to centralize audit logs for your enterprise assets as far as you can, under a documented audit log management process. Graylog can only receive logs from sources you point at it, so the asset inventory and the process that defines which assets are in scope come from your organization. Before the build, confirm who owns the inventory, how new assets are added to it, and who signs off on the scope. Each source that is missing from the inventory is a gap that no Graylog dashboard will reveal.
Weekly review capacity and triage records
Safeguard 8.11 requires audit logs to be reviewed at least once a week for unusual or abnormal events. Graylog event definitions and dashboards make that review faster, but they do not perform it. Someone must be named, given time in the week, and trained on what counts as abnormal in your environment. Triage notes, acknowledgements and escalation records also need a home outside the search results, so that an assessor can see what was reviewed and what was done. Confirm these owners and records during scoping.
Time synchronization and log integrity
Log timestamps are only useful when every source keeps accurate time, and Graylog does not set the clocks on your hosts, network devices or applications. Time sources, their configuration and their monitoring sit in your infrastructure. Likewise, protection of the log files at the source, and of the Graylog and storage backends against tampering or deletion, depends on access controls and backup practices you run. Ask your infrastructure team to document both before expecting Graylog data to hold up as evidence.
Endpoint and application logging you must enable
Safeguard 8.2 requires audit logging to be enabled across enterprise assets, and Graylog cannot switch it on for systems that do not produce audit events. Operating system audit policies, application audit settings, database auditing and forwarding agents each need configuration on the source system and a matching Graylog input. Some sources will only send what their owners enable. Build an inventory of which events each system produces, and test that a sample event arrives in the expected stream before counting the source as covered.
Licensing limits and edition-gated features
Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, and some features used in alerting, archiving and security analytics need an Enterprise or Security license. Confirm that the inputs, event definitions and notifications in your design are available in the edition you plan to run, and that your internal use and any hosting arrangement fit the license terms. Get written answers from Graylog and your legal team before committing to a design that relies on a gated feature.
Sequence for a CIS Controls log management build
This sequence takes an organization from an undefined audit log scope to a Graylog deployment that collects, centralizes and retains audit logs for the Safeguards in scope, and runs a weekly review that leaves records an assessor can examine. Each step closes with a check the team can confirm before moving on.
Define the audit log management process and asset scope
Security leadership and the platform owners agree which enterprise assets fall in scope, which event types each asset class must log, who owns collection and review, and where the process is written down. Safeguards 8.2 and 8.9 both point back to this process, so it comes first. The step is done when the scope list names every in-scope asset class, each owner is named, and the process document is approved and stored where auditors can find it.
Select inputs and confirm logging is enabled
The engineering team maps each in-scope asset to a Graylog input such as syslog, GELF or Beats, and turns on audit logging at the source so that the required events are actually produced. Operators confirm that each host, device and application sends events, and they note any asset that cannot log. The step is done when a sample event from every in-scope asset class appears in Graylog and the gaps list is recorded with an owner and a remediation plan.
Deploy Graylog with the chosen backend
The platform team installs Graylog server nodes with MongoDB for configuration and a search backend for log storage. Graylog recommends Data Node as the search backend, and the installation and compatibility documentation sets the supported versions for each component, so the team confirms those before installing. The step is done when the cluster reports healthy nodes, the search backend is reachable from every server node, and a test message can be searched end to end.
Set index retention to at least 90 days
Engineers configure index sets so that rotation and retention keep audit log data for at least 90 days, as Safeguard 8.10 requires. Graylog deletes the oldest indices under the retention setting, so the team sizes storage from expected daily ingest and the retention period before setting limits. The step is done when a retention configuration is saved for each audit index set, the storage calculation is written down, and a check confirms that the oldest retained index is at least 90 days old.
Build streams and dashboards for the weekly review
Analysts create streams that separate audit events by asset class and risk area, then build dashboards that show the unusual or abnormal events the weekly review must examine. Access to these streams is limited to the reviewers who need them. The step is done when each dashboard loads from saved searches, a reviewer can open each one without help, and the stream membership rules are documented alongside the process.
Create event definitions and notifications
Detection engineers write event definitions for the conditions the process names as unusual or abnormal, then connect notifications to the channels the on-call team uses. Thresholds are tuned against sample data so that alerts are neither silent nor flooding the team. The notification features available depend on the Graylog edition, so the team confirms which channels its license covers. The step is done when a test event triggers each definition and the notification arrives at the intended recipient.
Run a test review cycle
The reviewers work through one full cycle using the dashboards and event definitions, record what they examined, and log each finding and its disposition. The team checks whether the cycle met the weekly interval set in the process and whether any in-scope asset was missing from the results. The step is done when the cycle record shows dates, reviewer names, findings and follow-up tickets, and the process owner signs off on any changes the test exposed.
Retain the review records and collection evidence
The process owner archives the cycle records, the scope list, the input configuration, the retention settings and the event definition exports in a controlled location for the audit period. This evidence shows that collection, centralization, retention and review operated as designed. The step is done when a reviewer who did not build the system can locate each record, trace it back to a Safeguard, and confirm that the retained logs cover the stated period.
Questions buyers ask before hiring help with CIS Controls logging
What drives the cost of a Graylog CIS Controls logging project?
The main drivers are the number of log sources in scope, how many assets and business units feed them, the search backend you choose, the Graylog edition you license, and how much review process design the work includes. Each source needs an input, parsing and testing, so source count is usually the largest variable. Costs split into one-time work (design, build, documentation, handover) and recurring costs (Graylog licensing if you buy a paid edition, infrastructure, storage and staff time for weekly review). Graylog Open is free with no volume limits and community support. The Graylog 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. Ask any quote to separate these lines.
How long does a Graylog audit log project take?
Duration depends on the asset inventory, the number of log sources that need new inputs, the size of the backend cluster, and whether the weekly review process must be designed from scratch. Work usually runs in phases: scoping and asset inventory, cluster build, source onboarding, retention and access setup, dashboards and event definitions, then a verification pass against the Safeguard requirements. Ask for a phased schedule in the written scope with named milestones and client dependencies. Be wary of any timeline quoted before the asset list and source list exist, because those lists decide most of the effort.
What does the work need from our team?
Expect to supply several roles for the length of the project:
- An owner for the audit log management process, who can approve which events are in scope and who reviews them weekly.
- Infrastructure contacts who can open firewall paths, create service accounts and grant access to the systems that generate logs.
- Application and platform owners who can confirm which audit events their systems produce and enable auditing where it is off.
- Someone who can approve storage and retention budgets, and the people who will receive alerts.
Without these inputs, source onboarding stalls, which is the most common delay.
Can our internal team implement this alone?
Often yes, if your team already runs Linux, MongoDB, a search cluster and logging pipelines, and can give the audit log work dedicated time. The gaps usually appear in three places: sizing the storage and journal for your retention period, designing event definitions that catch unusual activity without flooding the reviewers, and producing evidence that an independent assessor can sample. Assess these honestly against your team's capacity before deciding. Whichever route you pick, put the Safeguard mapping, the review procedure and the retention settings in writing so the work stays auditable.
Is Graylog Open enough to meet Safeguard 8.10?
Graylog Open can store and retain logs for the period Safeguard 8.10 requires, which is at least 90 days. Its index rotation and retention settings delete the oldest indices according to the limits you set, so you can keep indices for 90 days or longer. Confirm that your retention setting covers every in-scope source and that the storage sizing holds that period at your ingest rate. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, so have your legal team review the terms. Some features used for review, such as certain inputs and archive restore, need Enterprise or Security licensing, so check them against your design before relying on Graylog Open alone.
What should a quote for this work include?
A quote should follow from a written scope and list the in-scope Safeguards (8.2, 8.9, 8.10 and 8.11), the asset and log source inventory, the deployment topology, the search backend, and the Graylog edition or editions assumed. It should itemize deliverables such as the cluster build, each source onboarding, retention configuration, dashboards, event definitions, the review procedure and documentation. It should name client dependencies, acceptance criteria and the timeline with milestones. Recurring items such as Graylog licensing, infrastructure and any support retainer should be separate from one-time work. DeployOpen does not publish a price list, so ask for a quote tied to that written scope.
Does a CIS Controls accreditation fee apply to this project?
No. The CIS Controls Accreditation program is separate from implementation work. CIS lists an application fee of 1,500 US dollars for CREST members and 2,500 US dollars for non-members, and that program accredits CIS SecureSuite member organizations that provide CIS Controls services. Ask any provider, including DeployOpen, whether that accreditation is part of their offer, and do not assume it is. Also note that CIS says the Controls do not replace regulatory or compliance schemes, so the Safeguard work will not by itself satisfy an external audit.
What happens after go-live, and who reviews the logs each week?
Safeguard 8.11 requires audit logs to be reviewed at least once a week for unusual or abnormal events. Someone must own that review, and the review needs a written procedure, dashboards to work from, event definitions that raise alerts, and a record of what was checked and what was triaged. Decide whether your team does this or a retainer covers it, and ask the provider to document the handover. Ongoing support, upgrades and continuous testing are available as DeployOpen retainers, and the scope of any retainer should be agreed in writing before work starts.
Where DeployOpen's work stops and the auditor's begins
DeployOpen configures Graylog, documents the setup and prepares the evidence, but an independent assessor decides whether the Safeguards are met. For CIS Controls 8.2, 8.9, 8.10 and 8.11, DeployOpen's part covers the Graylog inputs that collect audit logs from in-scope enterprise assets, the streams and pipelines that route them, the index sets that hold them for the retention period you set, the dashboards and event definitions used for the weekly review, and the runbooks and exports that show each of these was built and operated as described. An assessor then samples those records, checks them against the audit log management process your organization has written, and forms a view. DeployOpen does not issue audit reports, attestations or certifications, and nothing in a Graylog build replaces the assessment your stakeholders require.
Be careful with the word "accreditation". CIS Controls Accreditation, run with CREST, applies to CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services, and it is a separate matter from this implementation work. Ask your stakeholders which Controls version they expect, since CIS Controls v8.1 was published on 24 June 2024 and is the current version as of October 2026, and which assessment method they will use. The CIS Controls Assessment Specification defines the measures for each Safeguard, so confirm whether your assessor will work from that specification or from your own internal control framework, and agree the evidence list before the build starts. If your team uses a mapping to another framework, such as NIST CSF 2.0 or ISO/IEC 27001:2022, confirm that the assessor accepts that mapping too.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure. For CIS Controls audit log management, we start from the four Safeguards in scope, agree the log sources and retention period in writing, and then build the collection, storage and review workflow around them.
How we scope
- Inventory the enterprise assets and log sources that fall under your audit log management process before any build begins.
- Agree in writing which event types each source must send, and who owns each one.
- Confirm the retention period, storage sizing method and Graylog edition each feature needs, so the quote follows from a defined scope.
How we build
- Deploy Graylog server nodes, MongoDB and the Data Node or OpenSearch backend in your environment, following the documented topology.
- Configure inputs, streams and index sets so audit logs from each source land in one central place with the agreed retention.
- Build dashboards and event definitions for the weekly review, then test them against sample events from each source.
How we hand over
- Document the log source inventory, configuration, retention settings and review procedure so your team can audit them.
- Provide a runbook describing how to add a new source, change retention and respond to a missed-collection alert.
- Walk your operators through the dashboards and event definitions, and confirm that the review procedure matches your audit log management process.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Graylog version upgrades, reviewing new log sources and checking that retention still meets your requirements.
- Confirm with us during scoping which parts of the review evidence your team or an independent assessor will need to see.
