Why a Graylog audit log matters before an incident or audit
A security or compliance lead needs a direct answer to one question: who changed access, inputs or retention in the log platform itself, and when? A Graylog audit log is the record Graylog keeps of user and configuration changes, such as a role being edited, an input being started or stopped, or a retention setting being altered. Whether that record exists in your deployment, what it captures and how long it persists depends on your Graylog edition, so the first task is confirming the capability for the version and license you run. The edition details on Graylog's pricing page are a starting point, but confirm audit coverage directly with Graylog.
The log platform matters because it holds evidence about everything else. If someone grants themselves a broader role, disables an input that feeds a security control or shortens index retention before an investigation, the change may be the only trace of an access problem. An audit log answers those questions only if it records the actor, the time, the object changed and enough detail to see what moved from one value to another. Before you rely on it, confirm which events your edition logs, where the entries are stored, how long they persist and whether they can be read and exported without using a shared administrator account. Write those answers into the design before an incident forces the question.
DeployOpen can plan the audit log setup, configure the retention and export path agreed in the written scope and assemble the evidence an assessment typically asks for, such as sample entries, configuration records and the procedure your team follows to review them. Auditors decide whether that evidence is sufficient for the framework you are assessed against, and DeployOpen does not issue audit reports or certifications. Ask any partner, including us, to state in the scope which edition is required, the retention period you need, who reviews entries and how entries are backed up before they expire. These decisions drive most of the scope, so settle them before any build work starts.
Audit logging options and when each fits
This table compares three ways to capture who changed what in Graylog: built-in Enterprise audit logging, forwarding audit events to a separate SIEM or log store, and exporting entries through the API on a schedule. Read each column against your edition, retention duty and the team that will review the trail. The main takeaway is that the edition you license decides which option is available without extra build work.
| Option | Edition needed | Where entries live | Export method | Operational cost |
|---|---|---|---|---|
| Built-in Enterprise audit logging | Graylog Enterprise, which starts at 15,000 US dollars per year (pricing page), with a minimum of 10 GB per day or 100 Graylog Compute Units | Within the Graylog deployment, as entries stored by the platform | Reviewed in the Graylog interface; confirm the export options available in your version | Lowest build effort, but confirm retention settings and how long entries survive in your environment |
| Forward audit events to a separate SIEM or log store | Confirm the license required to send audit events out of Graylog in your version | Destination SIEM or log store, separate from the Graylog cluster | Forwarding pipeline such as a Graylog output or a shipping agent; confirm the supported method | Adds a second system to secure, size and monitor, plus parsing rules at the destination |
| Scheduled export through the Graylog API | Confirm which edition exposes the audit endpoints you need; Graylog Open may differ | Exported files or records kept in storage you control | Scheduled job calling the API, writing to write-once or access-restricted storage | Needs a service account, script maintenance and checks that every run completed |
| Signed entries and tamper evidence | Confirm whether signing is offered in your edition and version | Depends on the chosen option; signatures must survive export | Verify signatures during export or review; keep verification keys outside Graylog | Key management and a verification routine that someone owns |
| Retention in MongoDB | Applies to any option that stores entries in the Graylog backend | MongoDB, which also holds configuration and metadata | Backed up with the MongoDB backup routine | Grows with change volume; plan backups before entries expire |
| Backup before expiry | Applies to every option | Copies held outside the live cluster | Scheduled export or backup job with a documented restore test | Recurring storage cost and periodic restore testing |
| Who reviews the trail | Any option | Reviewer's tool of choice, such as the Graylog interface or a SIEM | Access granted through roles, separate from the people whose changes are logged | Reviewer time, plus sign-off evidence for assessors |
Setting up audit log capture and export
This sequence confirms that your Graylog version and license include audit logging, stores and protects the audit records, exports them to storage you control, and backs them up before retention can remove them. Each step ends with a check you can repeat later as evidence of the setup.
Confirm edition and version in the compatibility matrix
Check that your Graylog release is listed in the compatibility matrix against your MongoDB version and your search backend, whether that is Graylog Data Node or self-managed OpenSearch. Audit logging is an Enterprise capability, so confirm with Graylog that your license includes it before you plan around it. Record the Graylog, MongoDB and search backend versions and the license confirmation in your change record. The step is done when you have a written version set that the matrix supports and a license statement from Graylog, both attached to the change ticket.
Confirm MongoDB access and authentication for audit storage
Audit entries sit alongside Graylog configuration and metadata in MongoDB, so they inherit the same exposure as everything else in that database. Ask your database administrator to confirm that MongoDB authentication is enabled, that Graylog connects with a dedicated account limited to what its documentation requires, and that firewall rules let only Graylog nodes reach the database port. Ask Graylog which collection holds audit entries and whether it lives in the replica set you built for the cluster. The step is done when Graylog connects with its own account and a connection attempt from an unapproved host is refused.
Enable audit logging and verify with a test change
Turn on audit logging in the Graylog web interface using the steps in the current documentation for your edition. Then make one controlled change in a non-production context, such as creating an illustrative test user, and write down the time and the account you used. Search the audit records for that change and confirm that the entry names the actor, the object changed and the time. The step is done when the test entry appears and its fields match the change you made, which becomes your baseline for future checks.
Confirm entries are signed and verifiable
Look up in the Graylog documentation how audit entries are signed, where the signing material is kept, and how a single entry is verified. Keep any verification key outside MongoDB, so someone who can write to the database cannot also re-sign edited records. Run the documented verification on the test entry, then copy the entry into a scratch database, alter one field and confirm that verification fails. The step is done when the untouched entry verifies and the altered copy does not, and you have recorded the verification method for your auditors.
Configure a scheduled API export
Pull audit records through the Graylog API on a schedule and write them to storage that your team controls, outside the Graylog nodes. Confirm the endpoint, the authentication method for a dedicated service account, and how paging and time filters work in the API reference for your version. Store the timestamp or cursor of the last successful export so runs neither duplicate nor skip records. The step is done when two consecutive runs export the test entry only once, and the next run adds only entries created after the previous run.
Set a backup routine before retention removes entries
Find the retention setting that governs audit entries in MongoDB and write its value down before anything else. Schedule backups of the audit data that run comfortably ahead of any expiry, store copies away from the Graylog nodes, and encrypt them under keys your team manages. Restore a backup into a scratch MongoDB instance and confirm the test entry is present with its signature intact. The step is done when the restore test succeeds, the backup age is visible to your operations team, and the restore procedure is written down.
Whether audit entries can be signed and how to prove integrity
Audit entries are only useful as evidence if a reader can trust that nobody edited them after the fact, and that need for tamper evidence is the first thing to settle. Whether Graylog can sign audit entries is a capability you must confirm with Graylog for the edition and version you run before you design around it. Do not assume signing is available because audit logging is available. Ask Graylog in writing whether entries are signed, what algorithm and key material are used, where the keys live, how signatures are verified, and whether verification can be run by an independent party. If the answer is no, or the answer depends on a feature your edition does not include, the controls below become your integrity design rather than a supplement to it.
Because audit records are stored in MongoDB as configuration and metadata, the first fallback control is to restrict who can write to the database. Limit MongoDB write access to the Graylog service account and to a small break-glass group, and log every direct database session at the operating system or database layer, outside Graylog itself. Pair this with a periodic export of the audit entries and a cryptographic hash of each export, written to write-once storage such as object storage with object lock or a separate WORM-capable archive that the Graylog administrators cannot modify. Store the hashes separately from the exports so that a single compromised location does not reveal both. Test the chain by re-hashing a sample of exports and comparing results against the stored values on a fixed schedule.
Separation of duties is the control that ties the others together. The people who administer Graylog should not also control the MongoDB host, the archive bucket and the hash store, and the person who verifies integrity should not be able to change the audit trail they are checking. Write these assignments into your access model and review them when roles change. Confirm with your auditor which evidence they will accept for integrity, since the answer determines how much of this design you must build and document. DeployOpen can help plan the export, hashing and storage path, but the decision on what counts as sufficient proof belongs to your assessors and your risk owners.
Security and operational risks of audit logs
An audit trail is only useful if it stays intact, complete and recoverable. The risks below cover the places where Graylog audit entries can be altered, lost, exposed or never written, and each one needs a named owner before the audit log is relied on as evidence.
Direct database changes
Anyone with write access to the MongoDB database that backs Graylog can edit or delete configuration and metadata without the change passing through the Graylog application. Restrict MongoDB accounts to the Graylog service, keep administrative shell access separate from Graylog administrators, and compare audit entries against periodic exports. Owner: the database team, with the security team reviewing access.
Retention deleting entries early
Audit entries stored in MongoDB follow the retention you configure for them, so an entry can disappear before anyone exports it. Confirm the retention period against your own record-keeping rule, schedule exports well before that point, and test that an export restores the expected entries. Owner: the platform team sets retention, and the compliance lead signs off on the period.
Over-privileged export credentials
The account or token that pulls audit entries through the API should read audit data and nothing else. A token with administrative rights can change the same records it exports, which weakens the trail. Use a dedicated read-only account, store its credential in your secrets manager, and rotate it on a fixed schedule. Owner: the identity team issues the account, and the security team reviews its permissions.
Secrets in support bundles
Support bundles help troubleshoot a running Graylog, but they can include configuration that holds passwords, tokens and keys. Treat a bundle as sensitive data: remove secrets before sharing it, limit who can generate one, and store copies only in approved locations. Owner: the Graylog operations lead controls bundle handling.
Changes made outside the audit path
Confirm which configuration changes produce audit entries and which do not, especially changes made through the API, scripts or direct file edits on a node. Run a controlled test change for each path, record whether an entry appears, and document any gap as a known limitation. Owner: the Graylog administrator maintains the test list, and the security team accepts the gaps.
Clock drift across nodes
Audit entries are sorted and read by timestamp, so nodes with different clocks produce entries that appear out of order or are hard to correlate with other logs. Synchronize every Graylog server, MongoDB member and Data Node with the same time source and check drift as part of routine monitoring. Owner: the infrastructure team owns time sources and monitoring.
Questions teams ask before setting up Graylog audit logging
Can Graylog Open record user and configuration changes without an Enterprise license?
Confirm this before design starts, because the audit logging covered here is described as an Enterprise capability and edition boundaries can change between releases. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, and its product page describes it as free with no volume limits and community support. Ask Graylog in writing which audit events your edition records, where those entries are stored and whether they can be exported through the API. If the answer is Enterprise, the license minimum sets the floor: according to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year with a minimum of 10 GB per day or 100 Graylog Compute Units. Do not assume an Open deployment meets an audit requirement until that confirmation is on file.
What does a Graylog audit logging setup cost?
Cost has three parts: the Graylog license, the services that design and build the audit trail, and the infrastructure that stores it. The license is the only external price in this picture. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year and is licensed on processed data with no per-user or per-device fees, so adding people who review entries does not add license seats. Services are typically one-time work in a fixed-scope engagement, covering configuration, export design, backup and handover. Infrastructure recurs through MongoDB hosting, storage for retained entries and backup targets. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask each quote to separate one-time build work from recurring support and to name who owns the backup storage.
What drives the effort in a Graylog audit trail project?
Effort rises with the number of systems and administrators whose changes must be recorded, because each change source needs its own mapping and test. Other drivers include:
- The retention period you must meet, since longer retention means more MongoDB and backup storage to plan.
- Whether entries must be signed and how your team verifies signatures later.
- The export format and destination your SIEM or evidence store expects.
- How often backups run relative to your retention settings, so entries are copied before they expire.
Multi-node deployments add failover testing. The Graylog multi-node guide recommends MongoDB as a replica set for medium to large deployments. Ask for each driver to appear as a separate line in the scope so a change in one is visible in the quote.
How long does Graylog audit logging setup take?
No duration is supplied for this work, so treat any single number you hear as a claim to verify. The timeline depends on the inputs you confirm before scoping: the Graylog version you run (the current documentation covers version 7.2), whether your MongoDB is a replica set, which change sources must be covered, the retention period, the export destination and the backup location. Open answers in these areas hold up a schedule more than the build does. Ask for the plan to show when each input is needed and which steps wait on your approvals or change windows. If you are still choosing a host, the Graylog installation documentation lists the supported install methods and platforms.
What must our team provide before audit logging work starts?
Plan to provide access, information and decisions. For access, you need a Graylog administrator account and either access to the MongoDB and backup hosts or a named contact who can run commands there. For information, you need the current Graylog version, the deployment layout, a sample of user and configuration change events from your systems, and the retention and review rules that apply to your organization. For decisions, you need a named owner for the audit trail, a destination for exports, a list of who may read entries and who approves retention changes. Also reserve a test window for restore checks, since an untested backup does not show that entries can be recovered.
Can our own team set up Graylog audit logging alone?
Yes, a capable internal team can build this without a partner if it has skills in Graylog administration, MongoDB operations, API scripting and backup restore testing. The work needs more than configuration. It requires a documented retention decision, a verified export path and a tested restore. A partner is most useful where those skills are thin or where the team wants the design reviewed before it is built. Check the Graylog multi-node guide against your planned topology so you know what the Graylog and MongoDB nodes must support. Whichever route you choose, write down who runs the backups and who reads the exported entries.
How is Graylog audit logging work scoped in writing?
DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. The written scope should name the Graylog version, the change sources in scope, the retention period, the export format and destination, the backup method and location, the restore test and the handover. It should also state what is excluded. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, so the scope should state that independent auditors perform any formal assessment. Ongoing support, upgrades and checks after go-live are available as retainers and can be quoted separately.
How DeployOpen scopes Graylog audit logging work
DeployOpen starts with a written scope that confirms the Graylog edition, license and version before any configuration changes. Audit logging is described as an Enterprise capability, so the first task is to confirm with Graylog which audit entries the licensed edition records and which version the client runs, since the current documentation covers version 7.2 and behavior can differ across releases. The scope then maps the changes that must be evidenced: user logins and role changes, sharing changes on streams and dashboards, input and stream edits, processing pipeline and event definition changes, and the account that made each one. For each mapped event, the client names an owner, a review cadence and a retention period agreed with its compliance or legal team.
The scope also designs how entries leave Graylog. Audit entries are stored in MongoDB alongside configuration, so the design covers a scheduled export through the API into storage that Graylog administrators cannot edit, a check that each export is complete, and a MongoDB backup schedule that preserves entries before any expiry setting removes them. Signed entries matter here, but the team should confirm whether the edition supplies signing and, if it does not, which integrity control replaces it. DeployOpen then implements the design and tests it by making known changes in a non-production environment and confirming that each one appears in the export and the restored backup.
The handover includes runbooks for the export schedule, the backup restore test, the evidence index and the steps to follow after an upgrade, because a version change can alter audit entry fields. DeployOpen prepares controls and evidence for an assessment but does not issue audit reports, attestations or certifications; an independent auditor or certification body does that. Ongoing support, upgrade checks and periodic restore tests are available as a retainer, which is usually the right fit when the client needs evidence collected every month rather than once. A quote follows from the written scope, so the client should ask for the edition confirmation, the event map and the export and backup design to be listed as separate deliverables.
