What AU.L2-3.3.6 reduction and reporting requires in plain terms
AU.L2-3.3.6 asks for two working capabilities: a way to reduce raw audit records so they can be analyzed on demand, and a way to generate reports on demand. Audit logs from servers, identity systems, endpoints and cloud services grow far too fast for anyone to read by hand, so an assessor will not accept the raw log store as proof. They will look for a tool or process that filters and summarizes records when someone asks, and for evidence that it actually works. NIST SP 800-171A (June 2018) splits the requirement into those two assessment objectives: an audit record reduction capability that supports on-demand analysis, and a report generation capability that supports on-demand reporting. Both must be demonstrated, not just described in the system security plan. The requirement carries a weight of 1 point under 32 CFR 170.24, so it has little effect on the score alone. It is still a 1-point item that is not on the exclusion list in 32 CFR 170.21, which means it may be placed on a plan of action and milestones if the overall score qualifies for Conditional Level 2 status. Confirm the current score threshold and closeout rules in the rule text before you rely on that route, because the Department of War has changed CMMC schedules recently. Also confirm that your Level 2 requirements still point to NIST SP 800-171 Rev. 2, which the CMMC rule incorporates even though NIST has since published Rev. 3. The originals must stay unaltered. The CMMC Assessment Guide Level 2 describes reduction as an automated process that extracts relevant information from raw logs without changing the source records, for example by filtering out routine nightly backup entries. Design the workflow so that filters, queries and summaries write to a separate output, and so that the raw store is protected from modification as required by AU.L2-3.3.8. An assessor will ask you to show the untouched source records alongside the reduced view, so keep both retrievable.
Which systems, log sources and teams fall inside AU.L2-3.3.6
AU.L2-3.3.6 applies to every system that stores, processes or transmits CUI and produces audit records, plus the tools and people who reduce and report on those records. The scoping decisions below, especially where logs are held and who operates the reporting tools, determine how much of the environment an assessor will test.
CUI systems that generate audit records
Start with the system security plan boundary and list every asset inside it that writes audit records: operating systems, databases, identity providers, applications, network devices and cloud control planes. Reduction and reporting only work on sources you have enabled, so an unlogged system is a gap the assessor will find. Confirm which sources feed the reduction tool and which are excluded, and document the reason for each exclusion.
Centralized versus per-system log stores
Decide whether audit records are gathered into one repository or stay on each host. Central storage makes filtering and summarizing on demand practical across systems, while per-system storage means reports must be built separately for each source. Whichever model you choose, the assessor will ask how a reviewer reaches the originals and whether the summaries can be traced back to them.
Reduction and reporting tools
Identify the software that filters, summarizes and produces reports, such as a SIEM dashboard, a log indexer or a built-in admin audit log viewer. Each tool is in scope because it performs the reduction and reporting the requirement describes. Record its version, its access permissions and where it stores its own configuration, since assessors test the tool itself as well as its output.
Reviewers and report consumers
Name the people who run searches, read summaries and receive scheduled reports, including security operations staff, system administrators, compliance leads and any incident responders. Their roles define who may run on-demand analysis, so the access model should match the people listed. Confirm that report recipients are documented and that each report's audience can be shown to the assessor.
Third-party hosted logging services
A managed SIEM or hosted log service that holds CUI-relevant audit records becomes part of the assessed environment, and its provider must meet the applicable requirements for handling CUI. Ask the provider where data is stored, how reduction and reporting are performed, and what evidence it can supply on request. Your contract and responsibility matrix should state who maintains the reduction rules and report templates.
Scoping decisions that change the work
Three decisions shift the effort most: whether logs are centralized, whether a managed service holds the data, and whether CUI systems share infrastructure with non-CUI systems. Shared infrastructure means reports must separate CUI-relevant records from the rest, or the whole shared environment enters scope. Put each decision in writing before you configure anything, because changing it later means rebuilding reports and re-collecting evidence.
How to build a reduction and reporting capability that passes
This sequence turns raw audit records into filtered summaries and scheduled reports that an assessor can see run on demand, while the original logs stay untouched. Each step ends with a artifact the assessor can inspect, so the capability is provable rather than assumed.
Inventory the log sources in scope
The system owner lists every system, application, identity service and security tool that produces audit records within the CUI boundary, along with where each one writes its logs and how long they are kept. Gaps here become gaps in reports later, so the inventory should match the system security plan and the audit logging scope already defined for AU.L2-3.3.1. The step is done when every source has a named owner, a storage location and a record format that the team can read. Hand over the inventory as a controlled document.
Define the reduction filters and summaries
Working with the people who review logs, the security team writes down the questions reviewers need answered, such as failed logins by account, administrative changes by day, or events from a given host. Each question becomes a written filter or summary definition that names the fields it uses, the time window and the output format. Reduction must extract relevant information without changing the source, so the definitions should describe selection and aggregation only. Hand over a reviewed list of filter and summary definitions tied to the sources from the previous step.
Separate the raw store from derived views
Raw audit records go to a write-protected store with restricted access, and every filter, index view or dashboard reads from that store without writing back to it. The administrator confirms that reduction jobs run with read-only permissions and that derived outputs are saved to a separate location. Check that a filtered result can be regenerated from the originals and that deleting a view leaves the raw records intact. Hand over a short architecture note that shows the raw store, the derived layer and the permissions that separate them.
Configure the report templates
The team builds reusable report templates that wrap the approved filters and summaries into a fixed layout, including the reporting period, the source systems covered and the person who generated the report. Templates should be versioned so an assessor can see what a report looked like when it was produced. The reporting tool must generate output for a chosen period without manual editing of the underlying data. Hand over the template set with version history and a sample output for each template.
Prove on-demand execution
The administrator runs each filter and each report template at the request of a named reviewer, outside any scheduled job, and records the request, the time, the parameters and the output. This demonstrates the on-demand analysis and on-demand reporting capabilities that the two assessment objectives in NIST SP 800-171A describe. Run the same test with a different time window or a different reviewer to show the capability is general rather than a one-off. Hand over the execution records and screenshots or exports that an assessor can trace back to the raw store.
Document ownership and review
The organization names who maintains the filters, who may run reports, who approves template changes and who reviews the output on a defined schedule. These roles are written into the procedures and the system security plan so the capability can be tested as an operating process, not just a tool. Confirm that the people named have the access they need and no more. Hand over the signed procedure, the role matrix and the review log, which together show that the capability is owned and in use.
How an assessor tests reduction and report generation
This table compares what an assessor examines for AU.L2-3.3.6, how each check is run, the evidence to prepare, and the findings that most often cause a requirement to fall short. Read it as a preparation checklist: each row names something the assessor will ask to see, so the organization can demonstrate it before the assessment begins. The main takeaway is that the reduction and reporting capability must work on demand against the original logs, not only exist on paper.
| Assessment object or test | What the assessor checks | Evidence to prepare | Common finding |
|---|---|---|---|
| Procedures for reduction and reporting | Written procedures define how staff run audit record reduction and generate reports, and who does it | Documented procedure, roles, and the query or report templates in use | Procedure exists but does not match how the tool is actually run |
| Reduction tool | The tool filters raw audit records into a relevant subset on demand | Live filtered summary of a defined event set, with the filter criteria shown | Filters cannot be reproduced or depend on one administrator's saved session |
| Report generation tool | A report can be produced on request for a stated period and scope | A report generated during the assessment from the live log store | Reports are static exports that cannot be regenerated for a new date range |
| Original audit records | Reduction leaves source logs unchanged and complete | Hash or record count before and after a reduction run, plus retention settings | Reduction job overwrites or trims source logs, or deletes records after summarizing |
| Reduction output traceability | A summary can be traced back to the raw records it came from | Query parameters, timestamps and record identifiers included in the output | Summaries carry no reference to source records, so findings cannot be verified |
| Access to tools | Only authorized personnel can run reductions and generate reports | List of accounts with access and the audit trail of report runs | Shared accounts run reports, so no individual is accountable for a result |
| Test of the capability | The organization has tested that reduction and reporting work as described | Recorded test run with inputs, outputs and the person who ran it | No test has ever been run, so the capability is assumed rather than shown |
Evidence that satisfies AU.L2-3.3.6 and how to keep it current
An assessor testing AU.L2-3.3.6 needs proof that both reduction and reporting work on demand and that the original logs were never changed. The cards below cover the artifacts that show this, the checks that prove the originals are intact, and how to refresh the set between assessments without relying on drafts.
Written reduction and reporting procedures
The procedure documents which log sources feed the reduction tool, which fields are extracted, and who runs each report and how often. Assessors use it to judge whether the capability is defined and repeatable. Check that the procedure names the actual tools and versions in use, that it has been approved and dated, and that the text matches what staff do on the day of the test.
Exported filtered report outputs
Screenshots or exported files from a live filtered view, such as a summary of failed authentications for a chosen period, show that reporting works on demand. Keep the query parameters, the time range and the export timestamp with each output. A bare screenshot with no visible filter or date is weak evidence, so capture the full view and the export record together.
Saved query and rule definitions
Saved searches, dashboard definitions and detection rules are the logic that turns raw records into summaries. Export them as configuration files and store them under version control so each change has an author and a date. Assessors look for evidence that the reduction logic is the one actually running, so confirm the exported definitions match what is deployed.
Integrity proof for original logs
Reduction must leave the raw records untouched, so show this directly. Record checksums of original log files when they are written, restrict write access to the storage location, and keep a sample of hash comparisons from before and after a reduction run. Where the platform supports it, document the read-only or append-only settings applied to the source store.
Report schedules and retention records
Schedules show that summaries are produced on a defined cadence as well as on request, and retention records show how long the source logs and generated reports are kept. Record the schedule definitions, the recipients, and proof of recent runs such as delivered reports or job history. Confirm the retention period with your own policy and the related audit requirements rather than assuming a default.
Final-form documents and refresh cycle
Only final, approved versions count toward a MET determination, so drafts of procedures or reports must not be presented as evidence. Assign an owner to each artifact, set a review date, and re-run the reduction and reporting tests before every assessment and after any tool upgrade. Keep superseded versions in a change record so you can show what was in force on a given date.
What meeting AU.L2-3.3.6 costs in money and effort
This table breaks the cost of meeting AU.L2-3.3.6 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No figures are published here, so use the table to build the scope you send when requesting quotes. The main takeaway is that open-source tooling mainly removes license spend, while configuration, evidence upkeep and assessor time remain.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it |
|---|---|---|---|
| Reduction and reporting tooling | Your organization, for infrastructure to host the tools; no license fee for self-hosted open-source platforms, but confirm each product's license terms | Mostly one-time setup, plus recurring hosting | Number of log sources, retention period and whether the tool runs on-premises or in a cloud enclave |
| Engineering time to configure reduction | Internal platform or security engineers, or an implementation partner under a written scope | One-time | Number of log formats, custom filters and how many filters must remove data without touching originals |
| Engineering time to build reports | Internal staff or an implementation partner, scoped against the two assessment objectives in NIST SP 800-171A | One-time, with updates when reports change | Number of report types, audiences such as leadership or assessors, and how many reports are automated |
| Evidence upkeep | Your compliance or security staff, who keep sample reports, tool configuration exports and access records current | Recurring | Assessment cycle, frequency of report generation and how many people must review evidence |
| Operating the tools | Your system administrators, who maintain upgrades, storage capacity and the reporting pipeline | Recurring | Log volume, reporting frequency and the number of systems inside the CUI boundary |
| Readiness review or external testing | An independent consultant or implementation partner, if you buy a pre-assessment check | One-time per review cycle | Maturity of current logging, number of findings and whether the review covers the full boundary |
| Assessor effort | The C3PAO or assessor, whose work is priced by their own organization and sized by scope | Recurring per assessment | Number of reduction and reporting tools in scope, and how many sample reports the assessor must test |
Which open-source tools produce reduction and report evidence
Wazuh is most useful for reduction because it turns raw collected events into a smaller set of classified alerts. Its decoders parse each log into fields, and the ruleset compares each event against more than 3,000 built-in rules and decoders plus any custom rules you add. Matching events are written as alerts to alerts.log and alerts.json, and forwarded to the Wazuh indexer, where the dashboard supports filtering and summary views. The raw archive remains a separate record, so the reduced alert view does not replace the original events.
- Built-in ruleset: Over 3,000 rules and decoders reduce raw events to relevant alerts, and custom rules extend coverage to your applications.
- Alert files:
alerts.logandalerts.jsonhold the reduced output, which you can export or hand to an assessor. - Indexer and dashboard: Alerts are indexed for on-demand filtering by agent, rule, severity or time range.
- MITRE ATT&CK mapping: Alerts are mapped to ATT&CK techniques, which helps group related activity into summary reports.
- Licensing: Wazuh is licensed under GPL-2.0-only, so confirm that your distribution and any custom modules meet your license obligations.
Confirm which log sources feed the agents, that the raw archive is retained separately from alerts, and that the report output you show an assessor is produced by the configured dashboard or export, not edited by hand.
OpenSearch Security Analytics reduces ingested logs by running detectors that match events against Sigma rules, which are prepackaged or custom rule definitions. Each match is recorded as a finding that shows the rule, log type and severity, so an analyst can filter findings instead of reading every event. The correlation engine links findings across log types into a correlation graph, which gives a summarized view of related activity. Alerts can be sent to channels such as Slack or email, so the reduced results reach the right people.
- Sigma-based detectors: Detectors match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules.
- Findings: Each finding records the rule, log type and severity, which supports filtering and summary counts.
- Correlation graph: The correlation engine links findings across log types to show related activity in one view.
- Alert channels: Findings can trigger alerts to channels such as Slack or email for review.
- Licensing: OpenSearch is licensed under Apache-2.0, which permits self-hosted deployment with the license terms intact.
Confirm which Sigma rules are enabled, which log types each detector covers, and whether the findings and correlation views are retained long enough to produce the reports you need to show.
Nextcloud's admin_audit app writes additional event information to an audit log, which gives a file-based record of administrative and file activity. The log is written to audit.log in the data directory by default, or to a path you set with logfile_audit. The file is a source for reduction rather than a reduction tool in itself, so you typically extract the entries relevant to a question, such as one user or one time window, with standard tooling or a log pipeline. The app only produces what its configuration enables, so the event coverage needs checking.
- Output location: Events go to
audit.login the data directory, or to the path set withlogfile_audit. - Configuration key: The
logfile_auditsetting controls where the audit file is written, which matters for protecting and forwarding it. - Extraction: Filtering by user, action or time window is done on the file or after forwarding it to a log platform.
- Forwarding: Sending the file to a central platform such as OpenSearch or Wazuh can add reporting views, but this integration must be built and tested.
- Licensing: Nextcloud is licensed under AGPL-3.0-only, so review obligations if you modify and distribute the server code.
Confirm the admin_audit app is enabled, that the logging configuration matches the events you must show, and that the file location is protected and included in your backup and forwarding plan.
OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Because the records are structured, they can be filtered by request path, operation or outcome, and they support summarized reporting on secret access. Most sensitive values are hashed with HMAC-SHA256 in the log, so reviewers can correlate events without exposing the underlying secrets. The original device log is the authoritative record, and summaries are derived from it.
- Structured requests: Each API request and response is written as JSON, which makes field-based filtering practical.
- Error capture: Failed requests are recorded, which supports reporting on denied or unexpected access.
- HMAC-SHA256 hashing: Most sensitive values are hashed, so reports can show that a value was used without revealing it.
- Device configuration: Confirm which audit devices are enabled and where each writes, since a request may need a working device to be served.
- Licensing: OpenBao is licensed under MPL-2.0, which applies at the file level to changes you make to its source.
Confirm which audit devices are enabled, the file or socket they write to, and that the hashing behavior matches what your reviewers need to see in reports.
Common gaps that cause findings on AU.L2-3.3.6
Assessors rarely fail AU.L2-3.3.6 because a company lacks a log tool. They fail it because the reduction and reporting capability is undocumented, manual, edited after the fact, or not tied to the systems in scope. The gaps below are the ones that most often turn a working capability into a finding.
Reduction that edits or deletes raw logs
Reduction is meant to extract relevant information from raw logs while leaving the originals intact. A common failure is a script or analyst that trims, rewrites or overwrites the source files, so the summary can no longer be checked against the record it came from. Check that reduction reads from the original store, writes to a separate output, and that the originals keep their hashes or retention settings. Test by regenerating a report and comparing it to the untouched source.
Reports that exist only as screenshots
A dashboard screenshot pasted into a document shows one moment in one view, with no query, filter or time range that an assessor can rerun. This does not demonstrate a report generation capability that supports on-demand reporting. Store the saved query or report definition, its parameters and the output format, and confirm that a staff member who did not build it can run it again.
No proof of on-demand regeneration
Assessors look for the capability to produce a report when asked, not a folder of past reports. Many organizations can show old output but cannot run the same reduction against a chosen date range during the assessment. Rehearse a live request: pick a period and a system, generate the summary, and record the time taken and who ran it. Keep the record of that rehearsal as evidence.
Unclear ownership of reporting
When nobody is named for running reduction and reporting, reports appear irregularly or not at all, and no one can explain the filters. Assign a responsible role for the reduction tools, a separate reviewer for the output, and a documented procedure in the system security plan. Confirm that these roles match the people who hold access to the audit tooling under AU.L2-3.3.9.
Drafts presented as final evidence
A report marked draft, or an export with unreviewed filters, cannot support a MET determination, because assessors need evidence in final form. Teams often hand over the working copy from the week before the assessment. Set a naming and approval step for each report, keep a version history, and present only the approved output with its generation date and parameters.
Reports that omit systems in scope
A summary built from one application server looks complete but leaves out the identity provider, secrets store or cloud control plane that also hold CUI-related events. Compare each report's data sources against the asset inventory and the system boundary in the system security plan. Document which sources feed each report, and state where a source is intentionally excluded and why.
Questions buyers ask about AU.L2-3.3.6 cost, effort and outside help
How much effort does AU.L2-3.3.6 take compared with the other audit requirements?
AU.L2-3.3.6 is a narrow requirement, but the effort sits in the tooling rather than the paperwork. The assessment objectives ask for two things: a reduction capability that supports on-demand analysis, and a report generation capability that supports on-demand reporting. If your logs already flow into a central platform with saved searches and scheduled reports, most of the work is confirming and documenting it. If logs sit on individual hosts, expect the larger effort to be collecting them first. Effort rises with the number of log sources, the number of report types you must produce, and how many people have to run them. The 1-point scoring weight does not reflect the effort, so do not size the work from the score.
Can our own team meet AU.L2-3.3.6 without an outside partner?
Often yes, provided someone on staff owns the logging platform and can run the reduction and reporting tools without assistance. The organization always owns its controls and the evidence. An implementation partner can configure systems, write procedures and prepare evidence, but only an independent assessor can judge the requirement for a certification assessment. In-house teams usually struggle with three things: documenting the reports in a form an assessor can repeat, proving that filtering never alters the original logs, and keeping evidence in final form rather than drafts. A partner is most useful when those gaps are large or the team has no time to close them.
What does the work need from our staff?
Plan for time from three groups. Platform administrators need to build or confirm the search and reporting configuration and show how a filtered view is produced without changing source records. Security or compliance staff need to define which reports matter, such as reports for investigations or access reviews, and keep a record of when they were run. Someone who can explain the process to an assessor must walk through a live demonstration. Ask any partner to name which of these tasks they perform and which your staff must keep, and put that split in the written scope.
How long does AU.L2-3.3.6 work usually take?
The duration depends on how far your logging is from a working reporting capability. A team with a central log platform and documented report templates has far less to do than a team with logs scattered across unmanaged systems. The main drivers are the number of log sources to bring under reduction, the reports you must support, the state of your system security plan, and the time needed to gather evidence in final form. No duration is given here because none has been researched for this requirement. Ask any provider for a timeline tied to a written scope, and check it against your own assessment schedule.
Can a partner issue the assessment result for AU.L2-3.3.6?
No. An implementation partner, including DeployOpen, prepares systems, controls and evidence, but it does not issue assessment reports or certifications. For Level 2 certification assessments, the work is performed by an assessor authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Self-assessments are carried out and affirmed by the organization itself. Make sure any partner agreement states plainly that the partner has no role in the assessor's findings, and that the assessor is independent of the partner.
How does a POA&M apply to AU.L2-3.3.6?
AU.L2-3.3.6 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21, so it may be placed on a plan of action and milestones if your score meets the threshold for Conditional Level 2 status. Under the rule, the score must be at least 88 of 110, and closeout is due within 180 days. Do not treat the POA&M as a way to skip the work. Assessors will still expect a working capability and final evidence at closeout, and the item must be tracked with a named owner. Confirm the current status of the POA&M rules before relying on them, since the CMMC program timeline has changed recently.
What should we ask for in a written quote for this requirement?
Ask for a scope that names each log source in reduction, each report type to be produced, and the systems that host the logging tools. Request a list of deliverables, such as configuration records, procedures, sample reports showing the original logs remain unchanged, and an evidence checklist. Ask which tasks are fixed in scope, which are optional retainers, and what the partner needs from your staff. Confirm who performs testing and who signs off. A written quote should follow from that scope, and any figure should be tied to deliverables you can check.
How DeployOpen prepares AU.L2-3.3.6 evidence
DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares the reduction and reporting configurations and the evidence that come from them. It does not issue assessment results. The organization owns its controls and its scoring, and an independent assessor decides whether AU.L2-3.3.6 is MET. In practice, the work covers the audit reduction and report generation tools you choose, the saved queries and report templates that show on-demand analysis, retention and access settings that keep originals untouched, and a written evidence pack mapped to the two assessment objectives in NIST SP 800-171A.
Every engagement starts with a written scope that names the systems in the boundary, the log sources feeding each tool, the report types the assessor should see, and the deliverables. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any work begins. A quote follows from that scope, and DeployOpen does not publish a price list. Ask for the quote to itemize platform configuration, testing of reduction and report output, evidence preparation, and any hardening or upgrade work, so you can see which parts are one-time and which recur.
Some work does not end at handover. Log sources change, reports need updating when scope changes, and platform upgrades can alter how a tool filters or formats output. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, which suit organizations that expect their CUI boundary to change between assessments. Before you sign, confirm with your assessor which evidence formats they accept, whether they will review drafts or only final-form records, and how the Department of War's current CMMC phase affects which assessment you need. DeployOpen can prepare the evidence, but only the independent assessor can state the result.
