Graylog for CMMC audit logging: what it covers and what it does not
A contractor that handles CUI and needs CMMC Level 2 must meet the audit and accountability requirements of NIST SP 800-171 Rev. 2, which CMMC identifies as AU.L2-3.3.1 (event logging) and AU.L2-3.3.5 (audit record review, analysis and reporting). Graylog can carry much of the technical work behind those two requirements: it collects events through inputs, routes them through streams and processing pipelines, stores them in index sets with retention, supports search and dashboards, and sends alerts through event definitions. Graylog does not decide what your organization must log or how often your people review it. Those decisions, and the evidence that they were made and followed, remain yours. DeployOpen configures the platform, documents the design and prepares evidence for assessment, but it does not issue certifications. Independent C3PAO assessors do that for Level 2 certification.
The timing matters. The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and the Department has said it will enforce Rev. 2 in the interim. Confirm the current status of your contracts and any DoW guidance with your contracting officer before you choose a scope, because a self-assessment still needs evidence that a reviewer could verify.
Before you configure anything, separate the platform from the program. Graylog's capabilities answer whether a log can be collected and found. Your event selection, review frequency and reporting roles answer whether the requirement is met, and the assessment objectives in NIST SP 800-171A require those decisions to be documented and backed by final-form evidence. Write down which event types your CUI systems must log, who reviews them, how often, and who receives findings, then build the Graylog streams, event definitions and dashboards to match that record. Ask DeployOpen, or your own team, to confirm which Graylog features your edition includes before you rely on them, because some detection content depends on the Enterprise or Security license.
Mapping 03.03.01 and 03.03.05 to Graylog capabilities and configuration
This table maps each audit requirement to the Graylog component that satisfies it, the configuration to build, and the values your organization must set. Read the rows in order: inputs and streams capture events, event definitions and dashboards handle review, and index retention keeps records available for the period you define.
| Requirement | Graylog configuration | Organization-defined values to set |
|---|---|---|
| 03.03.01 event logging (Rev. 2 3.3.1, AU.L2-3.3.1) | Inputs such as syslog, GELF or Beats for each in-scope source, with streams separating CUI system events from other traffic and a processing pipeline that tags event types | Event types selected for logging (ODP 1), such as logon, privilege use, account changes and log configuration changes |
| 03.03.01 review frequency | Scheduled review of the event type list, documented as a recurring task with a change record each time the list changes | Frequency for reviewing and updating the logged event types (ODP 2), recorded in your system security plan |
| 03.03.05 audit review and analysis | Dashboards and saved searches for privileged and failed-access events, plus event definitions that raise alerts on unusual patterns | Review frequency for audit records and the criteria that count as inappropriate or unusual activity |
| 03.03.05 reporting findings | Notifications from event definitions to email, Slack or PagerDuty, with a documented triage path for each priority level | Recipients or roles that receive findings and the reporting timeline they must meet |
| 03.03.05 correlation across repositories | Streams and searches that combine sources such as identity, endpoint and network logs in one Graylog cluster, with correlation handled by event definitions or Enterprise correlation features | Which repositories are in scope and the fields used to correlate records across them |
| Index retention supporting review | Index sets with rotation and retention set so the review window stays searchable, using the index model settings in Graylog | Retention period for audit records, confirmed against your contract and assessment requirements |
| Time and record integrity inputs | Consistent timestamps from the sources and Graylog nodes, with restricted access to the index and configuration backends | Time source and the access roles allowed to view or change log data |
Rev. 2 versus Rev. 3: why the audit family changes and what to build now
Build the Graylog audit design so it satisfies Rev. 2 today and can be extended to Rev. 3 without rework. NIST classifies the change from Rev. 2 requirement 3.3.1 to Rev. 3 requirement 03.03.01 as significant, because the Rev. 3 wording adds more detail and foundational tasks. The most visible change is that 03.03.01 has two organization-defined parameters: the event types selected for logging within the system, and the frequency for reviewing and updating that selection. Rev. 3 also drops Rev. 2's split between basic and derived requirements, so an assessor will read 03.03.01 as one requirement with explicit parameters rather than two tiers. Under Rev. 3, NIST does not assign these values, so the organization must set them.
For CMMC Level 2, the version in force is still Rev. 2. 32 CFR 170.14(c)(3) makes the Level 2 requirements identical to Rev. 2, which means 110 requirements, and the audit requirement AU.L2-3.3.1 carries 5 points under the 32 CFR 170.24 scoring methodology. It cannot be placed on a POA&M for Conditional status under 32 CFR 170.21. A FAR overhaul proposed rule published on 23 June 2026 would move contractors handling CUI to Rev. 3 using ODP values published by the DoW CIO. That rule was not final as of October 2026, so confirm the current contract clause with your contracting officer before changing your baseline.
Design the event type list and review frequency as a documented, versioned Graylog artifact now. Record each event type, the source it comes from, the Graylog stream or input that carries it, and the event definition or dashboard that reviews it. Set the review frequency in writing, and state the value you chose for each parameter. Then map each entry to both the Rev. 2 3.3.1 and Rev. 3 03.03.01 wording, so the same evidence answers either assessment. Ask your assessor which ODP values they expect to see, and keep a change log of selection reviews so the record shows the parameter was reviewed and updated as Rev. 3 requires.
How the CMMC scoring weight of audit requirements affects your plan
AU.L2-3.3.1 carries real weight in the CMMC Level 2 scoring methodology and cannot be carried on a plan of action for Conditional status. The cards below turn that rule into decisions about what Graylog must be collecting, reviewing and proving before an assessment begins.
Audit logging is a scored requirement
Requirement 3.3.1 is assessed as AU.L2-3.3.1 and is worth 5 points under the 32 CFR 170.24 scoring methodology. Your Graylog plan should treat audit logging as a control that is scored in its own right, not as supporting infrastructure. Ask who on your team owns the score impact of an unmet logging objective before the assessment window opens.
No POA&M for Conditional status
Under 32 CFR 170.21, AU.L2-3.3.1 cannot be placed on a plan of action and milestones to reach Conditional status. A logging gap found during readiness work therefore cannot be deferred into a dated remediation item and still count toward a Conditional result. Confirm this with your C3PAO or sponsor before you rely on any remediation timeline for audit logging.
Working logging before assessment
Because the requirement cannot be bridged with a POA&M, the Graylog inputs, streams and retention settings must be live and collecting before the assessment. A design document or a planned pipeline does not satisfy the objective. Run a dated check in which you confirm that events from in-scope CUI systems are arriving in Graylog and are searchable.
Evidence in final form
A requirement is MET only when all applicable assessment objectives are satisfied with evidence in final form, not drafts. Export and retain Graylog configuration, event type lists, review records and sample search results in finished form. Ask your assessor which artifacts they expect to see for the event logging and review objectives.
Rev. 2 scope and Rev. 3 changes
CMMC Level 2 assesses against Rev. 2, where this requirement is 3.3.1. Rev. 3 treats it as 03.03.01 with organization-defined parameters for the event types and the review frequency, and NIST classifies that change as significant. Document the event types and review interval in Graylog now so the same record supports either revision if the rules change.
Review and correlation staffing
Requirement 03.03.05 asks for regular review of audit records, reporting of findings to named roles, and correlation across repositories. Graylog event definitions and dashboards can automate detection, but a person or role must review the output and record actions taken. Assign those roles and their review frequency before the assessment, and confirm your internal staffing covers that cadence.
Which event types to select for logging in a CUI environment
Identity systems are usually the first place an assessor looks, because every access to CUI depends on them. NIST SP 800-171 Rev. 3 requirement 03.03.01 asks the organization to select the event types it logs within each system and to review that selection at a defined frequency. For identity, the justification is usually straightforward: the organization records who signed in, from where, and whether the attempt succeeded, along with changes that alter who can access what.
- Authentication outcomes: successful and failed sign-ins, including lockouts and multifactor challenges, from directory, SSO and VPN sources.
- Privilege changes: group membership changes, role assignments and changes to administrator accounts.
- Account lifecycle: creation, disabling, deletion and password resets.
- Session and token events: token issuance and revocation where the identity provider exposes them.
For each event type, record the reason it is logged and the requirement it supports. Confirm with your identity product's documentation which events it can emit and in which format, since Graylog can only search what the source sends.
Endpoints and servers hold CUI files, run CUI applications and execute the commands administrators use. The organization decides which operating system and security events are sufficient to show activity on those systems. A useful starting point is to log events that let an investigator reconstruct who ran what, when, and with which privileges, without collecting every routine process start that would bury the signal.
- Privileged commands: use of elevated privileges, sudo or administrator sessions and remote administration logins.
- Logon activity: interactive and remote logons, including failures, with the source address.
- Security configuration changes: audit policy changes, service installs and changes to logging settings.
- Malicious code and security tool alerts: detections reported by endpoint protection on the host.
- File access on CUI locations: read, write and deletion events for designated CUI directories, if the platform supports object-level auditing.
Document which events are excluded and why. Confirm the exact event identifiers and the collector agent your team will use, and test that they arrive in Graylog before the selection is treated as final.
Network devices show which systems talk to the CUI environment and whether boundary controls are doing their job. The organization must justify which device logs it collects, because firewalls and switches can generate very high volumes. Selecting events that show policy decisions, administrative access and boundary crossings usually meets the intent of the requirement while keeping storage and review workable.
- Boundary decisions: denied and permitted connections at the CUI enclave edge.
- Administrative access: management sessions, configuration commits and privilege changes on the device.
- VPN and remote access: tunnel establishment, failures and the user identity associated with each session.
- Routing and interface state: changes to routes, interfaces and high availability status.
- Time source: whether the device synchronizes its clock, since event order depends on it.
Record the volume each source produces and the reason for each filter. Confirm with the vendor which syslog facilities and formats the device supports, and whether it can send to Graylog over the protocol your design uses.
Applications and databases are where CUI is created, changed and retrieved, so the event selection should reflect the actions a user takes on the data. Generic infrastructure logs rarely show whether a particular record was viewed or exported. The organization therefore needs to define application events that tie a user to a data action, and to decide which actions are important enough to justify logging.
- Data access: views, searches and exports of records or documents that contain CUI.
- Data changes: creation, modification and deletion of CUI records, including the before and after state where the application provides it.
- Authorization decisions: denied access attempts and changes to roles or permissions inside the application.
- Database administration: schema changes, privileged logins and changes to audit settings.
- Application errors with security impact: failed input validation or repeated access errors that may indicate misuse.
No generic list can name every application event, so ask the application owner to produce the event catalog. Confirm that the log does not itself store CUI content unless that is a deliberate, protected decision.
The logging platform is part of the system under review. If someone can disable a collector, change a stream, delete an index or alter an event definition without a trace, the organization cannot show that its audit records are complete. Including Graylog's own administrative and configuration events in the selection is therefore a justification the assessor expects to see, and it sits within the same review cycle as the other sources.
- Administrative logins: sign-ins to the Graylog web interface and API, including failures.
- Configuration changes: edits to inputs, streams, pipelines, index sets, event definitions and notifications.
- Retention changes: changes to index rotation or retention settings, which determine how long evidence survives.
- Input health: input stops, restarts and gaps in collection from each source.
- Backend health: failures of the MongoDB or search backend that affect storage of records.
Confirm which of these events Graylog emits to its own logs or to an audit stream in your version, and whether they can be forwarded to a separate protected destination. Review the selection on the same schedule as the rest of the list.
Configuring Graylog for audit record review and reporting
This sequence builds the Graylog pipeline that collects audit records from in-scope systems, keeps them protected and searchable, and turns them into scheduled review, alerting and reporting. Each step ends with a check that shows the evidence an assessor can sample.
Deploy the multi-node Graylog cluster
The platform or security engineering team installs Graylog server nodes, MongoDB as a replica set and a Graylog Data Node cluster, with a load balancer in front of the Graylog nodes. Graylog's multi-node guide describes three Graylog and MongoDB nodes and three Data Nodes for medium to large deployments, and follower Graylog nodes are set with is_leader to false. The step is complete when every node reports healthy, the cluster survives a single node restart, and the Graylog web interface loads through the load balancer. Confirm the Graylog 7.x and MongoDB and Data Node versions against the compatibility matrix before you install.
Configure inputs and streams for each audit source
The logging engineer creates inputs for each in-scope source, such as syslog, GELF or Beats, and routes messages into streams by source and event type. Separate streams for authentication, privileged activity and system changes make later review and access restriction simpler. Check that a test event from each source arrives in its intended stream, and record the source list and stream rules as part of your event type selection for 03.03.01. Processing pipelines can normalize fields, but confirm that parsing changes are documented for the assessor.
Set index rotation and retention for audit data
The engineer creates index sets for audit streams and sets rotation and retention by message count, size or time, based on the retention period your contract or policy requires. Graylog's index model deletes the oldest indices under retention, so the setting must match the retention decision in writing. Size storage using the daily ingest multiplied by retention days and multiplied by 120 percent, and allow 3 to 5 times daily ingest for the message journal on SSDs. The step is complete when a sample index set shows the configured rotation and retention values and the storage headroom has been calculated and recorded.
Create event definitions and notifications for unusual activity
The security operations lead writes event definitions for conditions such as repeated failed logons, changes to privileged groups, audit logging stopping on a source and activity outside normal hours. Each definition gets a priority, a notification channel such as email, Slack or PagerDuty, and an owner who receives it. Graylog Open supports event definitions and these notification channels according to Graylog's product page, while correlation and some detection content depend on the Enterprise or Security edition, so confirm the edition before you design those rules. The step is complete when each test condition fires a notification to the named owner.
Build dashboards for periodic review
The security team builds dashboards for the review tasks that 03.03.05 asks for, covering authentication outcomes, administrative actions, audit log source health and event definition results. Each dashboard is saved with a named owner, a fixed time range and the review frequency your organization defines. Reviewers should be able to export or print the dashboard for the review record. The step is complete when a reviewer can run one review from start to finish and the review output is stored where the assessor can find it.
Set up correlation across sources
The security engineer defines searches or correlation rules that connect records from identity, endpoint, network and application sources for the same user, host or session. 03.03.05 expects analysis and correlation of audit records across repositories for organization-wide awareness, so this step tests whether the link between sources works in practice. Confirm whether the correlation method you need is available in Graylog Open or requires the Enterprise or Security edition, because the supplied facts do not settle this for every feature. The step is complete when a test scenario spanning two sources produces one correlated result.
Restrict access and test the review record
The Graylog administrator limits access to audit streams and dashboards to the roles that perform review, and confirms that administrators cannot silently change retention or stream rules without a record. The reviewer then runs a sampling exercise: pick a recent review period, reproduce the findings, and confirm that the notification, dashboard snapshot and follow-up ticket all exist. The step is complete when access tests pass and one review can be traced from alert to documented finding, which is the evidence an assessor will request.
Evidence Graylog produces for an assessor and how to keep it
An assessor looks for records that show audit logging was configured, retained, reviewed and acted on. Graylog can produce most of that evidence from its own configuration and workflow, so the work is keeping exports current, final and tied to the requirement they support.
Event definition exports
Event definitions show which conditions Graylog watches for, such as failed logons, privilege changes or logging gaps. Export each definition with its search query, aggregation, notification and owner, and store the exports under change control. Check that the exported state matches what is running, because a definition edited in the UI after export will not match the record an assessor reviews. Link each definition to the event types it covers for 03.03.01.
Retention settings per index set
Retention is set per index set, through rotation and the rule that deletes the oldest indices. Record each index set's rotation strategy, retention rule and the streams routed to it, then export that configuration on a schedule. Confirm with your contracting officer and CMMC scope owner how long CUI-related audit records must be kept, because Graylog only enforces the rule you set. Compare the stored settings against that decision each review cycle.
Dashboards and saved searches
Dashboards and saved searches show the event types being reviewed and how they are filtered for the audit record review described in 03.03.05. Keep a versioned copy of each dashboard definition, note its owner and the review frequency it supports, and capture screenshots or exports dated to the review period. Saved searches that have been edited or deleted without a record weaken the review trail, so track changes to them.
Review records and triage tickets
Assessors look for proof that someone reviewed audit records at the defined frequency, reported findings to the right roles and followed up. Keep a dated review log that names the reviewer, the searches or dashboards used, what was found and the disposition. Link each alert that led to action to a ticket in your system of record, and keep the ticket history intact. Reviews with no record of what was examined rarely count.
Configuration baselines
A configuration baseline shows the inputs, streams, pipelines, roles and authentication settings that were in force during the assessment period. Store the Graylog server configuration and MongoDB-held objects in version control or an approved repository, and record who approved each change. Include the Graylog version in the baseline, because the CMMC Level 2 scope is judged against the system as it ran. Confirm the export method with your Graylog vendor documentation before relying on it.
Final-form evidence only
Under 32 CFR 170.16 and 170.17, a requirement is MET only when its assessment objectives are satisfied with evidence in final form, not drafts. Treat exports, reviews and baselines as final once approved and dated, and keep superseded versions for the period they describe. The assessor decides whether the evidence is sufficient for each objective in NIST SP 800-171A, so ask your C3PAO early which artifacts they expect and in what format.
Questions buyers ask before outsourcing CMMC audit logging
How much does it cost to outsource CMMC audit logging with Graylog?
The cost has two parts: the DeployOpen engagement and the Graylog license, if you need one. DeployOpen works to a written, fixed scope, so the quote follows from the source count, retention period, high availability design and review workflow you agree. Graylog Open is free with no volume limits and community support, according to the Graylog pricing page. 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, and licensing is based on processed data with no per-user or per-device fees. Ask the quote to separate one-time build work from recurring support, upgrades and any license you select.
What makes the Graylog audit logging scope larger or smaller?
Scope follows the systems that handle CUI and the event types you select for logging. The main drivers are the number of log sources (directory services, endpoints, firewalls, applications and cloud services), how long you keep logs, whether you run a three-node Graylog and MongoDB cluster with a Data Node cluster and load balancer, and how many event definitions and review dashboards your team needs. Each source needs its own parsing and testing. Storage sizing is driven by daily ingest multiplied by retention days and the Graylog guidance of 120 percent, so higher volume and longer retention raise the hardware and operations work.
How long does a Graylog audit logging implementation take?
No duration is fixed in this answer because the timeline depends on the agreed scope. A single-site build with a few well-documented sources moves faster than a multi-site deployment that needs high availability and parsing for many applications. Before you agree a timeline, confirm the source inventory, the event types you must log, the review frequency you will document, and who approves the evidence. Work that depends on your own change approvals, access requests or network changes will add elapsed time that a vendor cannot control.
What does DeployOpen need from our team to start?
DeployOpen needs access to the environment where Graylog will run, including cloud accounts, data center or air-gapped network details, and the systems that will send logs. Your team should provide the system security plan or boundary description for the CUI environment, the list of in-scope assets, the current logging configuration of each source, and the names of people who will review alerts and approve changes. You will also need to confirm the retention period, the review frequency and the event types you have chosen, because these decisions belong to your organization.
Can our internal team set up Graylog for NIST 800-171 audit logging without a partner?
Yes, a capable internal team can build this, and many do. The work that usually takes the most effort is not the installation but the evidence: documenting the event types selected for logging and their review frequency, showing that reviews happen and are reported, and keeping records in final form. Check whether your team has experience with the Graylog index model, MongoDB and OpenSearch or Graylog Data Node operations, clustering, and parsing many sources. If those skills are thin, a fixed-scope engagement can cover the build while your staff keep ownership of the review process.
What changes if the CMMC Phase II suspension is lifted or extended?
The Department of War suspended CMMC Phase II on 13 July 2026, and the Department's CIO page says implementation is paused in Phase 1. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW Class Deviation 2026-O0025, Revision 3 directs contracting officers to name SP 800-171 Revision 2 and requires baseline compliance with Rev. 2 while Phase II is suspended. Because the contract clauses still reference Rev. 2, build to the Rev. 2 requirements now. Confirm the current status with your contracting officer and the DoW CIO page before you plan a certification date.
Does DeployOpen certify our CMMC or NIST 800-171 compliance?
No. DeployOpen does not issue audit reports, attestations or certifications. It plans, builds, documents and supports the logging controls and prepares the evidence that an assessment will review. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and self-assessments are performed by your organization. Ask any provider to show which assessments they are authorized to perform, and treat the evidence package as an input to the assessor, not as a finding.
Which NIST 800-171 audit logging requirements does the engagement cover?
The engagement covers the audit and accountability controls that depend on logging infrastructure. In Rev. 2 terms that is AU.L2-3.3.1, which asks you to select the event types logged and review that selection at a defined frequency, and the related review, analysis and reporting requirements. Under Rev. 3, the matching requirements are 03.03.01 and 03.03.05. Confirm the mapping for your scope with the assessment objectives in NIST SP 800-171A, because the Rev. 3 parameters must be set by your organization where no federal value is given.
Where to confirm the requirement text and CMMC rules
Confirm the wording of each requirement against the primary text before you map Graylog to it. For the audit and accountability family, start with the NIST Rev. 3 pages for 03.03.01 Event Logging and 03.03.05 Audit Record Review, Analysis, and Reporting, then read the matching assessment procedures in *NIST SP 800-171A Rev. 3*. Your assessor will test against the Rev. 2 wording for CMMC Level 2, so also pull the Rev. 2 control for 3.3.1 and 3.3.5 from the NIST withdrawn publication. Note the difference in how each version defines its organization-defined parameters, because the event types and review frequency are yours to set and document in both versions.
For the CMMC side, read the scoring method in eCFR: 32 CFR 170.24 CMMC scoring methodology to confirm the point value assigned to AU.L2-3.3.1 and the other audit requirements, and read eCFR: 32 CFR 170.21 Plan of action and milestones requirements to confirm which requirements cannot be carried on a POA&M for Conditional status. Those two sections decide how much a logging gap costs in your score, so check them against the version of the rule you are assessed under.
Check the current Department of War status before you scope or budget the work. The Department of War suspended CMMC Phase II in July 2026, and the DoW CIO *About CMMC* page and the eCFR text of 32 CFR 170.3(e) do not currently describe the same schedule. Confirm with your contracting officer which clause and which Rev. 2 or Rev. 3 wording apply to your contracts, and re-check the DoW pages before each assessment planning cycle, since the status may change again.
How DeployOpen scopes and delivers CMMC audit logging
DeployOpen plans, implements and documents self-hosted Graylog inside the client's own infrastructure, so audit logging for CUI systems runs where the controlled data lives. Engagements are fixed-scope, with event types, review duties and evidence agreed in writing before the build starts.
How we scope
- We list the systems that handle CUI and the event types each one must log for AU requirements.
- The written scope names the event types selected for logging and who approves changes to that list.
- We agree the review frequency for event types and for audit record review, with the owner of each review task named.
How we build
- We deploy Graylog server nodes, MongoDB and Data Node in your accounts, data centers or restricted networks.
- We configure inputs, streams, processing pipelines and event definitions that match the agreed event types and review cadence.
- We test that expected events arrive, alerts fire on the defined conditions and retention deletes data as configured.
How we hand over
- We document the event type selection, the review procedure and the evidence each review produces for assessors.
- We walk your operators through search, dashboards, alert triage and how to record findings for reporting.
- We deliver the configuration and runbooks so your team can show requirement status in its own environment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- We can review event type selections when the system changes or when the applicable NIST revision changes.
- Confirm with your assessor and sponsor which requirement version and evidence form apply before scope is signed.
