AU-7 Audit record reduction and report generation

What AU-7 audit record reduction requires and why it is hard

An assessor who asks how you find the relevant events in a large log set is really asking whether your reduction capability works on the records you hold, without changing them. AU-7 asks for a capability to reduce audit records and generate reports that supports on-demand review, analysis and reporting, and that supports after-the-fact incident investigations. The two rules that make it testable are that the original content of each record stays unaltered and that the time ordering of records stays intact. A search tool, a filtered dashboard or a summary report can all satisfy the purpose, but only if the source records are still there, complete and in their original sequence when someone asks for them. Before the assessment, confirm which systems in scope produce audit records, where those records are stored, and which people are responsible for running reductions and reports during an investigation.

The difficulty is that a reduced view and the source record are easy to confuse. A dashboard that drops fields, a parser that rewrites timestamps into a local format, or an export that overwrites the original file can all appear to work while quietly breaking the rule. Assessors typically test this by picking a reduced report, tracing a line back to the raw event, and comparing content and order. Plan for this by keeping raw logs in write-protected storage, recording the query or filter used for each report, and checking that reduction tools write to separate outputs. The automatic processing enhancement, AU-7(1), adds a second layer. It requires audit reduction and report generation to be automated for processing audit records, and it applies in the moderate and high baselines of SP 800-53B but not in the privacy baseline. Confirm your baseline selection before you scope this enhancement.

Organizations usually underestimate the effort in the reduction logic itself, not the tooling. Someone must define which fields matter for each investigation type, test that filters return the same results after upgrades, and document the reports that auditors will ask to see. Open-source options such as OpenSearch Security Analytics, which matches ingested logs against Sigma rules and records matches as findings, or Wazuh, which writes matching alerts to alerts.log and alerts.json, can support automated reduction, but they do not decide what your investigations need. Confirm with your implementation partner and your assessor which reduction outputs you will show as evidence, and how the original records are preserved alongside them.

Which systems, logs and teams AU-7 reaches at moderate and high

AU-7 is selected in the moderate and high baselines but not the privacy baseline, so the scope question is driven by system impact level. The cards below cover the decisions that determine what the reduction and reporting capability must reach, and who must be able to use it.

Authorization boundary at moderate or high impact

AU-7 applies to every system inside the authorization boundary at moderate or high impact, so the first decision is where that boundary sits. Include the identity provider, the log collectors, the log store and the reporting console, because a reduction tool that cannot reach a source leaves an investigation blind. Confirm with your assessor whether shared services that hold audit data sit inside or outside the boundary, and document the answer in the system security plan.

Audit sources selected under AU-2 and AU-12

The reduction and reporting capability can only work on records that exist. Map the event types selected under AU-2 and the components that generate records under AU-12 to the sources the tool ingests, such as operating systems, databases, applications and network devices. Gaps between the documented event selection and the sources actually connected are a common finding, so check both lists against each other before testing.

Identity and privileged access logs

Identity events, including logons, privilege changes and account administration, are the records investigators most often need to reconstruct an incident. Confirm that directory, single sign-on and privileged access management logs reach the reporting capability with their original fields and timestamps intact. Test a sample query for a privileged account change end to end, since this shows whether reduction preserves the record content that AU-7 requires.

Cloud control plane and workload logs

Cloud provider control plane activity and workload logs often arrive through separate pipelines with different retention and time settings. Decide which cloud accounts, regions and services feed the capability at moderate or high impact, and record any source that is excluded with a reason. Verify that time order is preserved when events from several cloud services are merged into one report.

Report ownership across SOC, incident response and compliance

Three teams generate reports from the same records for different purposes: security operations for alert triage, incident response for after-the-fact investigation, and compliance for control evidence. Assign a named owner for each report type, along with the queries and templates they may run. Shared report definitions that change without review can alter what an assessor sees as the basis for a finding.

Third-party log platforms and their scope

A hosted log or SIEM service that stores or processes audit records of a boundary system generally falls inside the scope of that boundary, even though the provider runs it. Confirm the provider's responsibilities, where the data resides, and how the provider preserves record content and time order. Ask the provider for its own assessment evidence before the assessor asks for it, and check whether it holds the authorization level your system requires.

How an assessor tests AU-7 with examine, interview and test methods

This table maps the three SP 800-53A assessment methods for AU-7 to the test approach, the evidence an assessor requests and the findings that commonly appear. Read each row as a step the assessor takes, and use the last column to check your own evidence before fieldwork begins. SP 800-53A lists four determination statements for AU-7, and CPRT labels the control as AU-07.

Method	What the assessor does	Evidence requested	Common findings
Examine: audit reduction, review, analysis and reporting tools and system audit records	Reviews the tool configuration, the audit records it consumes and the reports it produces, and checks whether reduction logic leaves source records intact.	Tool configuration and version, sample raw audit records, the reduced or filtered outputs, and documentation of the filter and report definitions.	Reports that overwrite or truncate source data, and no documented separation between raw logs and derived views.
Interview: personnel with audit reduction and report generation responsibilities	Asks the people who run queries and build reports how they select events, how they confirm completeness and how they handle time order.	Named roles and responsibilities, runbooks for common queries, and the person's explanation of how output is checked against source records.	Responsibilities assigned informally, staff unable to explain how time ordering is preserved, and no owner for report definitions.
Test: the reduction and report generation capability	Runs a live or representative query on defined audit data during the assessment and compares results with the source records.	A witnessed reduction run, a generated report with its input range, and a comparison showing record content and sequence were unchanged.	No demonstrated on-demand query, output that reorders events by a default sort, and results that cannot be reproduced from the same inputs.
Determination: time-order and content integrity	Checks that reduced output keeps original timestamps, field values and sequence, and that re-running the same query yields the same order.	Hash or count comparisons between source and output, timestamp fields in the report, and a documented sort rule.	Missing time-order checks, timestamps rewritten to display time zones without a record, and duplicate or dropped events with no explanation.
Determination: on-demand review and incident support	Confirms that defined personnel can produce reduced views for review, analysis and after-the-fact investigation without waiting for a batch job.	Demonstrated query turnaround during the test, saved queries for incident types, and records of past investigations that used the capability.	Reports only generated on a fixed schedule, and investigators who export raw logs to spreadsheets because the tool cannot filter them.
Determination: enhancement for automatic processing (AU-7(1))	For moderate and high baselines, checks whether the reduction and reporting runs automatically on defined audit records as an organization-defined enhancement.	Scheduler or pipeline configuration, the defined audit record set, and output logs showing automated runs.	Enhancement claimed but no automated job exists, or automation not documented in the system security plan.
Evidence owner check	Confirms the organization holds the configuration, queries and report outputs, not only the vendor dashboard.	Exported configuration, versioned query files and retained report archives inside the organization's environment.	Evidence that exists only as screenshots, or reports that cannot be regenerated after the tool is upgraded.

How to build AU-7 reduction and reporting in the right order

This sequence moves from the investigations the capability must serve to a documented, tested reduction and reporting tier that sits on top of an untouched original audit store. Each step closes with an artifact an assessor can inspect.

Define review and investigation use cases
The organization, through its security operations and audit owners, lists the recurring reviews and incident investigations the reduction capability must support, such as user activity reviews, privileged access checks and reconstruction of a single incident timeline. Each use case names the people who run it, the questions they ask and the report they need. The step is done when the list is approved and every later filter or template traces back to one of these use cases. The output is a signed use case register that an assessor can compare against AU-7 and AU-6 test results.
Confirm source records meet AU-3 and AU-11
Before building any query layer, the team checks that the source records carry the content AU-3 requires, including event type, time, source, outcome and the identities involved, and that retention set under AU-11 covers the look-back periods in the use case register. Gaps are logged as configuration changes to the logging sources rather than patched downstream. The step is complete when a sample of records from each source is reviewed against the AU-3 fields. The output is a field mapping per log source with the sample review results attached.
Separate the immutable store from the query tier
The original audit records are written to a store where normal operators cannot alter or delete them, and the reduction and reporting tier reads from copies or indexes of that store. Access controls for each tier are defined separately, so analysts can query without holding write rights to the originals. The step is done when the architecture diagram shows both tiers and the access model for each. The output is an architecture record and a role matrix that an assessor can trace to the protection controls in AU-9.
Define reduction filters and report templates
The team writes the reduction filters, such as time window, event type and identity selectors, and the report templates that each use case needs, then stores them under version control. Filters select records for review but never rewrite them, and each template states which fields it displays. The step closes when a reviewer can run each template against the test data set and get the expected output. The output is a versioned library of filters and templates with an owner and change history for each item.
Prove reduction preserves content and order
The team runs a test that takes a fixed set of original records, applies each filter and report template, and compares the results with the originals. The test checks that field values are unchanged, that records keep their original time order and that no record is added or dropped by the reduction logic. Failures go back to the filter or template owner before release. The step is done when the test passes on the current versions and is repeated after each change. The output is a test plan, the recorded test results and the list of versions tested, which together support the AU-7 test method.
Configure automatic processing for AU-7(1)
For the moderate and high baselines, the team configures the reduction and reporting tier to process audit records automatically for the use cases that need it, such as scheduled reports or correlated detections that feed a review queue. The organization decides which processing runs automatically, documents the schedule and the people who receive output, and confirms that automatic processing follows the same preservation rules as on-demand queries. The step is complete when a scheduled job runs, produces its report and is recorded in the system. The output is the automation configuration, the job run history and the list of automated outputs.
Document each output for assessors
The team writes the operating procedure for the capability, covering who runs each report, how requests are logged, how the filters and templates are changed and how the preservation test is repeated. The procedure is linked to the AU-1 policy set and the system security plan so assessors can follow the evidence chain. The step is done when the operators have followed the procedure once and recorded the result. The output is the reduction and reporting procedure, the request log template and a cross-reference table tying each artifact from this sequence to AU-7 and its assessment objects.

Evidence that passes AU-7 and how to keep it current

An assessor testing AU-7 wants to see that the reduction and report capability works, that it leaves original records untouched, and that it still works today. The cards below cover the artifacts that show this and how to refresh each one between assessments so the evidence reflects the system as it runs now.

Configured reduction and report tooling

Export the configuration of every tool used for audit record reduction and report generation, including query templates, filters, field selections, output formats and the role that can change them. Store the exported settings with a version identifier and the date they were captured. Between assessments, compare the current configuration with the stored export and record any difference. An assessor will ask whether the settings shown are the ones in production, so the export must come from the live system, not from a design document.

Sample reports with their producing queries

Keep a set of sample reports, each stored with the exact query or filter that produced it, the time range it covered, the person who ran it and the date. A report without its query cannot be reproduced, which weakens the claim that the capability supports on-demand review. Schedule re-runs of the same sample queries against current data at a frequency your assessment plan defines, then retain the new output beside the old. Differences in row counts after a log source change are a signal to investigate, not to file away.

Proof that originals stayed unchanged

Show that reduction and reporting work on copies or views and never rewrite source audit records. Useful artifacts include hash values recorded when records were written, access logs showing that the reporting roles have read-only permissions on the source store, and a test where a reduced report is generated and the original records are then checked against their stored hashes. Recheck this proof after any storage migration or index change, because a change in storage layout can alter what is actually protected.

Time-ordering checks

AU-7 requires that reduction keeps the original time order. Run a scheduled check that pulls a sample of records, confirms that timestamps in each generated report are monotonic within the expected sort, and flags gaps or reordering. Record the check output with the timestamp source each system uses, since mixed clock sources or time zone offsets produce ordering problems that look like missing events. Keep the check script under version control so the same test runs at each review.

Automatic processing configuration for AU-7(1)

The automatic processing enhancement, AU-7(1), applies to the moderate and high baselines in SP 800-53B Release 5.2.0. Evidence here is the rule or schedule that triggers automated reduction and reporting, the list of event types it covers, and logs showing that runs completed or failed. Confirm with your assessor which automated processing is in scope before you collect this evidence. Keep change records for every rule edit, because an unreviewed change to automated filtering is one of the most common gaps assessors find.

Records of investigations that used the capability

Keep a register of incidents and reviews where reduced reports or on-demand queries supported the investigation. Each entry should name the case, the report or query used, the analyst, the date and the finding. Real use is stronger evidence than a demonstration because it shows the capability works under pressure. Review the register at each assessment cycle and confirm that every entry links to a stored query so the investigation can be rebuilt from the record.

What meeting AU-7 costs in money and effort

This table compares the cost components of building and keeping AU-7 audit reduction and report generation in place, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape a written scope before asking for quotes, because the drivers depend on your own log volume, sources and boundary. No prices or durations are given, since none are supplied for this control.

Cost component	One-time or recurring, and who is paid	What drives it up, and how to keep it down
Tooling and licenses	Recurring for commercial log platforms, typically per volume or per node. Self-hosted open-source options such as Wazuh, OpenSearch and Nextcloud's audit logging carry no license fee but still need hosting and administration. Confirm license terms directly with each vendor.	Log volume, number of sources and retention period drive storage and subscription size. Filtering noisy events at collection and choosing self-hosted tools can reduce license spend.
Engineering to build the reduction layer	One-time, paid to internal staff or an implementation partner under a written scope. Covers filters, parsers, correlation rules and the reduction logic that leaves original records untouched.	Number of log sources, number of event formats and the need to preserve original content and time order. Reusing standard decoders and rulesets and limiting the first release to high-value sources keeps effort down.
Report templates and query design	One-time to build, with occasional recurring updates. Paid to engineers or analysts who define report types for on-demand review and incident investigations.	Number of report types and audiences, such as security operations, legal and auditors. Start with the report types your incident response plan actually uses and add others on request.
Evidence upkeep	Recurring, paid to the control owner and operations staff. Covers keeping configurations, rule versions, sample reports and change records current.	Frequency of rule and report changes, and how many systems are in the boundary. Version control for rules and scheduled evidence captures reduce manual effort.
External testing or review of the reduction logic	Periodic, paid to an independent tester or reviewer. Checks that reduction does not alter original records or time ordering. Scope and frequency are agreed in writing.	Size of the boundary, number of reduction rules and whether testing is combined with other assessment work. Reviewing a defined sample of rules and reports is usually easier to scope than a full review.
Auditor sampling and assessment	Recurring per assessment cycle, paid to the independent assessor. The assessor examines reduction tools, tests the capability and interviews the people who generate reports.	Number of systems in scope, number of report types and the evidence available on request. Keeping reports reproducible and dated shortens sampling work.
Quote preparation	One-time, requested from a partner or vendor. Ask for a written, scope-based quote that separates build, license, upkeep and assessment support.	Clarity of the scope. A boundary with defined log sources, report types and retention needs produces a quote that can be compared directly.

Which self-hosted tools can produce AU-7 evidence and their license terms

AU-7 is a capability requirement, so no single tool satisfies it alone. The tools below cover adjacent parts of the audit pipeline: log generation, rule-based filtering, correlation and reporting. Each card states what evidence the tool can help produce and what the organization must confirm before relying on it.

Wazuh alert files and dashboard review

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. This can support on-demand review and investigation evidence, but the reader must confirm whether its alert filtering meets the organization's own reduction criteria and whether original records are kept unchanged alongside the alerts.

OpenSearch Security Analytics findings

OpenSearch (Apache-2.0) Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with rule, log type and severity, alerts go to channels such as Slack or email, and a correlation engine links findings across log types in a correlation graph. This supports reduction and reporting, but the reader must confirm which detectors are enabled, how findings are retained, and that the source events remain unaltered.

Nextcloud admin_audit log

Nextcloud (AGPL-3.0-only) ships the admin_audit app, which logs additional event information to audit.log in the data directory, or to a path set with logfile_audit. The file is a raw event source rather than a reduced report, so it gives assessors original records to test against. The reader must confirm that the app is enabled, that the log path is protected and retained, and whether any reduction or report generation is done by a separate tool.

OpenBao audit devices

OpenBao (MPL-2.0) audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. This gives a complete, structured source of privileged secret access events that can be filtered later. The reader must confirm which values are not hashed, who can read the device output, and whether filtering or reporting happens in a separate system, since OpenBao itself does not perform AU-7 reduction.

Who does AU-7 work: in-house team, implementation partner or auditor

Your organization owns AU-7. That means it decides what the audit record reduction and report generation capability is for, which investigation and review use cases it must serve, and what gets reviewed and how often. The control is accountable to your risk owners even when a partner builds the tooling, so the decisions behind it need to be written down and approved by the people who carry the risk.

Reduction policy: Define which fields can be filtered, summarized or grouped, and which must always be preserved in full for investigations.
Investigation use cases: List the questions responders must answer quickly, such as tracing a privileged session or reconstructing an access sequence.
Report ownership: Name who runs on-demand reports, who receives them and who signs off on findings.
Operational decisions: Decide what is reviewed, at what scope and by whom, and who may change report definitions.
Evidence custody: Keep the approved configuration, report samples and review records under your own document control.

Confirm that a named owner can explain every report definition in use, because assessors interview the people responsible for reduction and reporting.

What buyers ask before bringing in help on AU-7

Can we implement AU-7 audit record reduction in-house?

Yes, if your team already runs its own logging pipeline and has people who can build and test reports. AU-7 requires a capability to reduce audit records and generate reports for on-demand review and after-the-fact investigations, without altering record content or time order. The work is hardest where logs come from many platforms in different formats, where no one owns report design, or where the team has never produced the evidence an assessor will ask for. A partner can help in those cases, but the organization keeps ownership of the control either way. Settle that split in writing before work starts.

What drives the effort and cost of AU-7?

The main drivers are how many systems and log sources are in scope, how varied their formats are, and how many report types the investigators need. Internal staff time, partner fees under a written scope, tooling, and the independent assessor's fees are separate cost lines. Design, build and initial evidence are usually one-time costs. Report maintenance, testing after upgrades and evidence retention recur. Automatic processing under AU-7(1) adds effort because it is selected in the moderate and high baselines. Use the cost breakdown on this page to see which lines apply to your system, and ask any partner for an itemized quote tied to named deliverables.

How long does AU-7 work take, and what sets the timeline?

No duration applies to every environment, so confirm the schedule against your own systems before committing. The timeline is set by the number of in-scope systems, how mature the surrounding audit controls are (event selection, record content, review and generation), the availability of staff to test reports, change windows in production, and when the assessment is scheduled. Ask the partner for a milestone-based schedule in the written scope, with each milestone tied to a deliverable and a named reviewer. Treat any single number offered without those inputs as a starting assumption, not a commitment.

What does AU-7 work need from our own staff?

Your staff must own the outcome, even when a partner builds the reports. You will need a named owner for audit records, system administrators who can grant access to log stores and provide representative data, and investigators or security analysts who can say whether a report answers a real question. Someone must be able to approve changes, run a test investigation, and confirm that original record content and time order are unchanged. Personnel who hold report generation responsibilities are interviewed during assessment, so they should be identified and available for those conversations.

Does AU-7 apply at the privacy baseline?

No. In SP 800-53B Release 5.2.0, AU-7 is selected for the moderate and high security control baselines but not for the privacy baseline. If your system is scoped only to the privacy baseline, AU-7 is not required by that baseline, although you may still adopt it to support investigations. Confirm the baseline selection with your authorizing official or privacy office, and check the privacy baseline's own control list, because the privacy baseline applies regardless of impact level and may bring in other audit controls.

Can an implementation partner issue an audit result for AU-7?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Only an independent assessor or certification body can do that. Assessors test AU-7 against the procedures in NIST SP 800-53A Rev. 5, which include four determination statements and the examine, interview and test methods. Your partner's job is to make sure the reduction and reporting capability, its configuration and its evidence are ready for that examination.

How do we write a scope a partner can quote?

List the systems and log sources in scope, the report types investigators need, the output formats, and who receives each report. State whether automatic processing under AU-7(1) is required by your baseline. Confirm that the design must preserve original record content and time order, and name the evidence to deliver, such as configuration records, sample reports, test results and procedures. Add acceptance criteria, who performs testing, the change process, and what is excluded. DeployOpen works on fixed scope agreed in writing before work starts, so a written scope with named deliverables is the basis for a quote.

How DeployOpen scopes and prepares AU-7 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so audit record reduction and report generation can be demonstrated for AU-7. We prepare the systems and evidence; your organization owns the control, and an independent assessor reaches the conclusion.

How we scope

Engagements are fixed-scope, with the systems, log sources and reporting paths agreed in writing before work starts.
We confirm which AU-7 baseline applies to each system, and whether the AU-7(1) automatic processing enhancement is in scope.
The written scope names the reduction and report tools, the reports produced, and who in your organization runs them.

How we build

We configure reduction and reporting on the self-hosted platforms, such as search, alerting and audit log tooling, against your audit records.
We check that filtering and reports leave original record content and time ordering unchanged, and test that behavior directly.
We set up on-demand report templates for incident investigations and, where scoped, automated processing of recurring reports.

How we hand over

We document the configuration, data sources, report definitions and the procedure an assessor would use to examine them.
We deliver evidence packages that show reduction and report outputs, with the test results that demonstrate record integrity.
Your team receives walkthroughs so staff with reporting responsibilities can run and explain the reports during an assessment.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover tool version upgrades, changes to report definitions and re-testing after a change to audit sources.
Confirm with your assessor which evidence format they accept before the scope is finalized, since they issue any conclusion.