Graylog for NIST SP 800-53 audit logging

How Graylog supports NIST SP 800-53 audit and accountability controls

If you own a federal, contractor or regulated system and must show audit logging evidence against NIST SP 800-53, Graylog can cover the technical collection, search, alerting and storage behind AU-2, AU-6, AU-11 and AU-12. Event selection, review frequency, retention periods and the assessment itself stay with your organization and its assessor. DeployOpen prepares the system, controls and evidence for that assessment, but it does not issue certifications or attestations, and no tool makes a system compliant on its own.

In practice, Graylog helps with the mechanics of each part. Inputs such as syslog, GELF and Beats bring event records from the systems you name into one place, streams and processing pipelines route them, and index rotation and retention settings hold them for the period you define in the index_set configuration. Event definitions and dashboards support the recurring review that AU-6 asks for, and the Enterprise and Security editions add correlation and compliance content that some AU-6 enhancements depend on. Graylog does not decide which event types the system should log, how often the selection is reviewed, how long records must be kept under your regulatory duties, or whether a review is adequate. Those are decisions you document and an assessor tests. Under the Rev. 5 model, the controls are flexible and implemented through an organization-wide risk management process, so the evidence you produce should show why your choices fit your risk, not only that a feature was switched on.

Mapping AU-2, AU-6, AU-11 and AU-12 to Graylog capabilities

This table maps each audit and accountability control in scope to the Graylog capability that supports it, the configuration it needs and the edition required. Read each row as a question to answer for your system: what you must log, how you review it, and how long you keep it. Correlation and several SIEM features sit in Enterprise or Security, so confirm the edition before you commit the design.

Requirement	Graylog capability and edition	Configuration needed
AU-2 Event logging: identify event types, specify which are logged and how often, document the basis for investigations, and review the selection	Inputs (syslog, GELF, Beats) collect the chosen event sources. Available in Graylog Open.	Inventory each system's event types, document why each supports incident investigation, set a review date, and record the selection in your control documentation.
AU-12 Audit record generation: generate records for selected event types on defined components and let defined personnel change the selection	Inputs and per-source configuration determine what is generated and forwarded. Available in Graylog Open.	Enable audit logging at the source, configure forwarding per component, and restrict who may change input configuration in Graylog roles.
AU-6 Audit record review, analysis and reporting: review at a defined frequency for inappropriate or unusual activity and report findings	Streams route events by source, and event definitions alert on patterns. Event definitions are available in Graylog Open for real-time and historical monitoring.	Define review frequency, build saved searches and dashboards for each stream, and configure notifications to named responders.
AU-6(1) Automated process integration (moderate and high)	Notifications to PagerDuty, Slack and email are listed for Graylog Open. Ticketing or SOAR hand-off needs your own integration work.	Connect notification channels to on-call rotations and document the handoff from alert to case record.
AU-6(3) Correlate audit record repositories (moderate and high)	Correlation engine is an Enterprise feature. Investigations and anomaly detection are Security features.	Confirm the edition, define which repositories feed Graylog, and map shared fields such as user and host names across sources.
AU-6(5) Integrated analysis of audit records (high only)	Risk scoring, anomaly detection and investigations are Graylog Security features. Confirm their availability in your chosen version.	Select the analysis use cases, assign analysts, and document how analysis outputs feed review records.
AU-6(6) Correlation with physical monitoring (high only)	Graylog does not collect physical access systems by default. Requires external feeds sent as inputs and confirmed with your vendor.	Identify physical access sources, define the inputs or ingestion method, and agree on time synchronization across systems.
AU-11 Audit record retention for a defined period: support investigations and meet regulatory retention	Index rotation by message count, size or time and retention that deletes the oldest indices. Long-term archive restore needs Enterprise data lake.	Set index set rotation and retention to your defined period, size storage using daily ingest times retention days times 120 percent, and document the retention period.

Selecting event types that support after-the-fact investigation

AU-2 and AU-12 start with a decision the organization must make and write down: which event types each system component logs. AU-2 asks for the event types the system can log, which of them are logged and how often, and a documented reason why that selection supports after-the-fact incident investigation. AU-12 then requires audit record generation for those selected types and lets defined personnel change the selection per component. In a Graylog deployment, the register of selected event types should name each source, the inputs that receive it (syslog, GELF or Beats), the streams and pipeline rules that route it, and the index set where it lands. A selection that cannot be traced from source to index is the most common gap an assessor finds first.

Per-component selection matters because a domain controller, a reverse proxy and a database host produce different evidence and fail in different ways. Graylog routes by the input and the fields each message carries, so a pipeline rule that matches on source or on a message field is only as accurate as the component's configuration. Record which events each component is set to generate, who may change that setting, and how a change reaches Graylog. Confirm with your own environment that each source emits the fields your rules depend on, and test one event per type end to end before the selection is signed off. Graylog event definitions and notifications are covered in the alerting section.

The selection is not a one-time sign-off. AU-2 requires a defined review frequency, and AU-6 review depends on the selection still matching the systems. Set the review trigger in your own policy, then document each review: the date, who reviewed, changes to event types and the investigation scenarios that justify keeping each type. Ask your assessor or the NIST CPRT entry for AU-02 which evidence they expect for the review, and confirm the frequency your organization-wide risk process sets. Keep the reviewed register under configuration control alongside the Graylog pipeline and stream exports so both change together.

What Graylog evidence an assessor can examine

An assessor testing AU-2, AU-6, AU-11 and AU-12 will ask for records, not descriptions. The items below are the artifacts a Graylog deployment can produce, where each comes from, and what to confirm in your own environment before the assessment starts.

Documented event type selection

This is the written record of which event types each system component logs, why that selection supports after-the-fact investigation, and when it is next reviewed, as AU-2 and AU-12 require. Graylog does not generate this document. Keep it alongside the input list, with each source mapped to the event types it emits and the review date. Confirm that the mapping matches what is actually arriving in the streams, since a documented source that sends nothing is a common finding.

Input and stream configuration exports

Exports of inputs, streams and processing pipelines show how each event type is collected, routed and tagged. They answer the assessor question of whether the selection in the documented list is what the platform really does. Export them on a schedule through the Graylog API or the web interface, store them under change control, and compare each export with the previous one so unexplained changes to routing are visible.

Event definition records and notification history

Event definitions show the conditions that flag unusual or inappropriate activity under AU-6, and notification history shows whether those alerts were delivered and to whom. Keep the definition configuration with its owner, last change and priority. Confirm that the notification channels you rely on, such as email, Slack or PagerDuty, were working during the period under test, because a rule that fired into a failed channel will not satisfy an assessor's sampling.

Review records and analyst reports

AU-6 requires review at a defined frequency, reporting of findings to defined personnel, and adjustment of review when risk changes. Evidence is the dated record of who reviewed what, what was found, and who received the report. Graylog stores search and dashboard activity, but the review log itself usually lives in your ticketing or case system. Confirm the link between each alert and the ticket it created, and keep a record for each review cycle, including quiet periods.

Index set retention and rotation settings

AU-11 asks for retention for a defined period. In Graylog, retention is set per index set through rotation (by message count, size or time) and a retention strategy that deletes the oldest indices. Export each index set configuration and record the retention period it implements against the period your policy defines. Confirm that the retention you configured is what your regulator or contract requires, not only the platform default.

Deletion and rotation history

Assessors also check that retention was actually applied, not just configured. Index rotation and deletion events in the Graylog system logs, together with the storage backend history, show whether older indices were removed on schedule and whether any were removed early. Preserve these logs for the full assessment period. Confirm with your platform team how long the Graylog and OpenSearch or Data Node logs themselves are kept, because they are the evidence for the retention claim.

What moderate and high systems add to AU-6

AU-6(1) asks the organization to automate how audit records are reviewed, analyzed and reported by connecting them to other information sources, so analysts do not work each log source by hand. In Graylog, this is usually built from streams, processing pipelines and event definitions that route security-relevant messages to one review queue and notify the right people. Automation still needs a person to act on each alert. The platform handles the trigger, the routing and the record of delivery.

Stream routing: Send authentication, privileged command and configuration-change messages into dedicated streams so each review queue sees only the events it owns.
Event definitions: Build searches with aggregation conditions that match the review frequency and risk analysis your organization sets, and record the trigger logic in your control documentation.
Notification paths: Route alerts to an on-call or review mailbox. The Graylog Open product page lists PagerDuty, Slack and email as notification targets.
Case creation: Confirm how alerts open tickets in your case system, since the method depends on the notification or API approach you choose and your Graylog version.

Confirm that each automated path records who received the alert, when it was delivered and what action followed.

Configuring Graylog for AU-2 through AU-12

This sequence turns the NIST SP 800-53 audit controls into Graylog configuration: a documented event selection, collection on defined components, routing and review rules, retention, access restriction and a deployment that fits the system's size. Each step ends with a check you can show an assessor.

Document the AU-2 event types and review frequency
Before touching Graylog, the system owner and security lead list the event types the system can log, the components that will log them, and the reason each type supports after-the-fact incident investigation. Record the review frequency you define, since AU-2 expects the selection itself to be reviewed at a defined interval. Coordinate with any other entity that needs audit information, such as a managed service provider or a parent organization, and record who receives what. The output is a signed event selection register that maps each event type to its source, its Graylog input and the reason it is kept. If this register is incomplete, every later step inherits the gap.
Enable audit record generation on defined components
Work through each component in the register and turn on the audit logging it can produce, whether that is operating system auditing, application audit trails, identity provider events or network device logs. AU-12 lets defined personnel choose which event types each component logs, so record those choices per component. Send the records to Graylog through the inputs your sources support, such as syslog, GELF or Beats, and confirm the inputs appear as running with messages arriving. Verify a sample event from each component type is searchable in Graylog and contains the fields your AU-3 content requirements call for. Keep the configuration files under version control so changes are traceable.
Route selected events with streams and pipelines
Create streams that separate the audit events defined in the register from general application logs, so that review and access rules can apply to the audit data specifically. Add processing pipeline rules to parse fields, normalize timestamps and drop only the event types that the register does not select. Any filtering should be justified in the register, because discarding an event type the register selects is a gap an assessor will find. Test each rule with sample messages and confirm each selected event type lands in its intended stream. The output is a stream map that matches the register one to one.
Define event definitions for review criteria
AU-6 expects review for signs of defined inappropriate or unusual activity, so translate the criteria your organization set into Graylog event definitions. Start with conditions tied to the event types in the register, such as repeated failed logins, changes to privileged accounts or logging failures on a monitored source. Set notifications to the people named in your review procedure, and confirm the notification channel works with a test alert. Where you need correlation across repositories, plan that work against your edition, since correlation capability depends on the license. The output is a list of event definitions, each traced to a review criterion and an owner.
Set index set retention to the organization-defined period
AU-11 requires you to retain audit records for a period your organization defines, so set that period as a written value before configuring anything. Create a dedicated index set for the audit stream, then set index rotation and retention so that the oldest indices are deleted only after the defined period. Graylog Open rotates indices by message count, size or time and deletes the oldest indices under retention, so confirm the settings match the period in your policy. Size storage using the architecture guidance: daily ingest multiplied by retention days multiplied by 120 percent, with the message journal sized at 3 to 5 times daily ingest on SSDs. Check the resulting disk capacity against that figure and record the calculation.
Restrict access to log data
Limit who can read, search and change the audit index set and its streams, using Graylog roles that grant only the views each reviewer needs. Keep administrators who can change retention or event definitions separate from the reviewers who analyze events, and log those administrative changes. For authentication, Graylog Open supports Active Directory, LDAP and trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on, so choose the option that matches your edition and your identity standard. Test that a reviewer without the role cannot open the audit stream. Save the role matrix as evidence of access restriction.
Confirm the multi-node deployment for medium and large systems
If the system is medium to large, confirm the deployment matches the multi-node layout Graylog documents: three Graylog server nodes and three MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes. Set is_leader to false on each follower Graylog node and confirm only one node holds the leader role. Check the cluster status and confirm that a node failure does not stop log ingestion or search in a test. Whether a system counts as medium to large is a determination for your own impact analysis, so record the reasoning. The output is a cluster health report and a documented failover test.
Record the evidence for each control
Assemble the outputs from the earlier steps into one evidence package keyed to AU-2, AU-6, AU-11 and AU-12, along with the baseline enhancements your impact level selects, such as AU-6(1) and AU-6(3) for moderate and high systems. For each control, list the configuration, the screenshot or export that shows it, the test you ran and the date it was confirmed. Note that DeployOpen prepares this evidence, while the independent assessor decides whether the controls are met. Confirm with your assessor which artifacts they expect and in what format before you package them.

What Graylog does not cover for these controls

Graylog can collect, search, alert on and retain audit records, but it cannot decide what your organization must log, who reviews it, how long it is kept, or whether the control passes assessment. The cards below mark the decisions and evidence that stay with your organization and its assessor.

Event selection and review frequency

AU-2 requires you to name the event types the system logs, document why that selection supports after-the-fact investigations, and review the selection at a defined frequency. Graylog ingests whatever your inputs send, so the selection lives in your input configuration and stream rules. Check that each source in scope has an input, that the chosen event types are actually emitted by the source, and that the review interval is written into your procedure. Graylog will not make that determination for you.

Defined personnel and review procedures

AU-6 expects you to review audit records at a defined frequency, look for defined inappropriate or unusual activity, report findings to defined personnel, and change the review level when risk information changes. Graylog provides dashboards, event definitions and notifications, but it does not name the reviewers or write the escalation path. Document who reviews which streams, how findings are triaged and recorded, and who is told when a review finds something. Confirm that these people hold the Graylog roles they need.

Retention period and its basis

AU-11 leaves the retention period to the organization, which must set it to support after-the-fact investigations and to meet regulatory and organizational retention requirements. Graylog retention is configured through index rotation and retention settings, and the index model deletes the oldest indices when the limit is reached. The period you choose must be justified by the rules that apply to you, not by the storage you have. Record the basis for each period and test that deletion happens as configured.

Independent assessment and evidence

Graylog produces records, but it does not assess the control. NIST's SP 800-53A procedures describe examine, interview and test methods that an assessor uses to judge whether AU-2, AU-6, AU-11 and AU-12 are implemented. Assessors may also ask for evidence of review, such as triage records, and for proof that logging was not silently interrupted. Agree the assessment objects and sample evidence with your assessor before you build, and confirm which framework or authorization body you are answering to.

Physical monitoring feeds for AU-6(6)

AU-6(6) requires correlation of audit records with physical monitoring information, and the high baseline selects it. Graylog can ingest logs from badge, camera or facility systems only if those feeds exist and you configure an input for them, so the integration depends on your physical security stack. Confirm that the physical systems can export events, agree on time synchronization between them and Graylog, and decide who owns the correlation rules. Without these feeds, the enhancement is not met.

Licensing for correlation and SIEM features

Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license. Correlation and SIEM capabilities that AU-6(3) and AU-6(5) rely on, such as the correlation engine, risk scoring, investigations and compliance packs, need Graylog Enterprise or Graylog Security. Pricing 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. Confirm the license your design needs before you commit to the control mapping.

Setting AU-11 retention and the edition decision

AU-11 requires your organization to define the retention period for audit records, and that period has to follow from investigation needs and the regulatory rules that apply to you. Graylog will keep whatever you configure, so the retention value is a decision to record before anyone changes an index set. Write down which event types are kept, for how long, and who approved the period, then configure Graylog to match. Confirm the period with your legal, compliance and incident response owners, since the control leaves the number to you.

In Graylog, retention is managed through index sets. Indices rotate by message count, size or time, and the retention setting deletes the oldest indices once the configured limit is reached. Storage needs follow the sizing formula in Graylog's system architecture guidance: daily ingest multiplied by retention days multiplied by 120 percent. Run that calculation for each index set with its own retention, and size the message journal at 3 to 5 times daily ingest on SSDs. Test deletion on a non-production cluster first, because deleted indices cannot be recovered from Graylog itself.

The edition decision follows from the retention and review model. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support. Graylog Security starts at 18,000 US dollars per year and adds SIEM features such as risk scoring, anomaly detection, investigations, compliance packs and prebuilt threat detection content. Both paid editions have a minimum of 10 GB per day or 100 Graylog Compute Units and are licensed on processed data. Confirm current terms, minimums and inclusions directly with Graylog pricing before you commit.

Questions buyers ask about Graylog and NIST SP 800-53 audit logging

Does Graylog alone satisfy NIST SP 800-53 AU-2 through AU-12?

No. Graylog is a mechanism that collects, stores, searches and alerts on logs, but AU-2 through AU-12 also require decisions and records that a tool cannot make for you. The organization must identify the event types it logs, justify that selection for incident investigations, define how often it reviews audit records, set the retention period, and document who reviews findings and how. Graylog supplies much of the technical capability behind these requirements, such as input collection, streams, search, event definitions and index retention. Your assessor will look at the policies, procedures and evidence around the tool as well as its configuration, so plan the governance work alongside the build.

What does a Graylog audit logging build cost, and what drives it?

Cost has four main components: the engineering work to design and deploy Graylog, the event selection and documentation work, the licensing for the edition you need, and the infrastructure that runs it. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. The main cost drivers are the number of log sources, the retention period, whether you need a multi-node cluster, whether you need Enterprise or Security features such as correlation or compliance packs, and how much assessor involvement you expect. Ask any provider for a written, fixed scope that lists each of these items separately.

How long does it take to set up Graylog for NIST SP 800-53 audit logging?

Duration depends on scope, and no supplied figure sets a standard timeline, so confirm it in writing before work starts. The variables that matter most are the number of source systems to onboard, whether parsing and pipelines must be written for each source, the size of the production cluster, the retention and archiving design, and how many review and approval cycles the event selection requires. A single-node proof of concept takes less time than a multi-node production build with MongoDB as a replica set and a Data Node cluster. Ask for milestones tied to the written scope, with separate dates for the event selection, the build, the alerting and review workflow, and the evidence pack.

What must our organization provide for a Graylog audit logging engagement?

Your organization needs to supply decisions and access that only you can give. Expect to provide:

The list of system components in scope and an owner for each one.
The event types each component must log under AU-2 and AU-12, with a documented reason tied to incident investigation.
A defined retention period under AU-11, covering both the investigation need and any regulatory or contractual requirement.
A defined review frequency and the personnel who review, triage and report findings under AU-6.
Named staff who approve the design and accept the evidence.
Access to the source systems, network paths, cloud accounts or data centers, service accounts and a test window.

Delays in any of these items usually move the schedule more than technical work does.

Can our internal team set up Graylog for NIST SP 800-53 audit logging?

Yes, if the team has the right skills and time. Internal teams with experience in Linux operations, Graylog and its backends, and NIST SP 800-53 control language can often build the platform themselves. Check these before you start:

Someone can deploy and operate Graylog server nodes, MongoDB and Data Node or OpenSearch, following the installation and multi-node guides.
Someone can write parsing and pipeline rules for each source and test them.
Someone can map AU-2, AU-6, AU-11 and AU-12 to documented procedures and evidence.
Someone owns patching, backups and capacity checks after go-live.

If one or more of these is missing, a fixed-scope engagement can cover the gap, with the work and handover defined in writing.

How does the SP 800-53B baseline selection change the scope of audit logging?

The baseline your system falls under determines which controls and enhancements you must implement. SP 800-53B Release 5.2.0 selects 149 items for the low baseline, 287 for moderate and 370 for high, counting base controls and enhancements together, according to NIST's OSCAL profiles. For audit logging, the moderate and high baselines add AU-6(1) and AU-6(3), and the high baseline also adds AU-6(5) and AU-6(6). Those enhancements mean automated review integrated into a process, correlation across audit record repositories, integrated analysis and correlation with physical monitoring. Confirm your impact level and baseline with your authorizing official or compliance lead before scoping the correlation design, because it changes the number of sources, the alerting rules and the review evidence you must produce.

Will an assessor accept Graylog logs as evidence of AU-6 review?

The assessor decides, and no tool or service can promise a result. What an assessor typically looks for under AU-6 is a documented review frequency, evidence that reviews happened on schedule, records of findings and how they were reported, and proof that the review level changes when risk information changes. Graylog can help by keeping dashboards, event definitions, notifications and search history, but those records only help if your procedures define who reviews, what counts as unusual activity and how triage is closed. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Ask your assessor early which evidence formats they accept.

How DeployOpen scopes and delivers Graylog audit logging evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Graylog. For NIST SP 800-53 audit and accountability, we start from the event types, review duties and retention periods your system owner has defined, then build the Graylog configuration and the records that show it works.

How we scope

Engagements are fixed-scope, with the written scope naming the systems, log sources, event types and AU-6 review duties covered.
We confirm the AU-2 event selection, review frequency and retention period with your system owner before any build begins.
Scope records which moderate or high baseline enhancements, such as AU-6(1) and AU-6(3), your authorization boundary requires.

How we build

We deploy Graylog server nodes, MongoDB and Data Node or self-managed OpenSearch in your cloud accounts, data centers or air-gapped networks.
We configure inputs, streams, processing pipelines, index sets and event definitions to match the agreed event types and review workflow.
We test log collection, search, alert notifications and retention rotation against the agreed scope before handover.

How we hand over

You receive configuration documentation mapping each in-scope AU control to the Graylog settings that implement it.
Handover includes runbooks for event review, alert triage, access restrictions on log data and index retention changes.
We prepare evidence of configuration and operation for your assessors, while independent auditors remain responsible for any audit conclusions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed in writing after the initial scope.
Retainer work can cover Graylog version upgrades, review of changes to event definitions and periodic checks of retention settings.
Confirm with us during scoping which Graylog edition your required features need, since some correlation and compliance features depend on a licensed edition.

Graylog for NIST SP 800-53 audit and accountability