03.03.06 audit record reduction: requirements and evidence

What audit record reduction under 03.03.06 asks for

If a contract requires NIST SP 800-171, 03.03.06 asks whether your logging stack can answer review and investigation questions after the fact. The requirement calls for an audit record reduction and report generation capability that supports review, analysis, reporting and after-the-fact investigation of incidents, and it requires that this capability preserve the original content and time ordering of the records. In plain terms, you need tools that can filter and summarize large volumes of logs without altering what the logs say or scrambling the order in which events happened. The source control is AU-7 from SP 800-53 Rev. 5, and the Rev. 3 discussion of 03.03.06 points back to 03.03.03 (audit record generation), so the reduction capability is only as useful as the records your systems generate and retain.

NIST's change analysis classifies the Rev. 2 to Rev. 3 change for this requirement as significant, describing it as more detail and foundational tasks. Rev. 2 carried the same idea as requirement 3.3.6, but Rev. 3 spells out what a defensible capability looks like. For assessment, the SP 800-171A Rev. 3 procedure uses six determination statements and checks documented procedures for reduction and reporting, the tools in use, the audit records themselves and the design documentation, and it asks staff with audit and security responsibilities how they run reviews and investigations. Confirm with your assessor which tools and documents they expect to see for each determination statement before you build anything.

The hard part is not collecting logs. Many teams have plenty of records but cannot reproduce a timeline from them: events arrive from several systems with inconsistent clocks, summaries drop the fields an investigator needs, or a filtered export quietly loses the sequence of events. Test this before an incident forces the question. Pick a realistic scenario, such as a privileged account used across two systems, and check whether your tools can produce a time-ordered view with original field values intact and whether you can show that the summary matches the source records. Open-source platforms such as Wazuh and OpenSearch provide search, correlation and alerting, but whether a given deployment meets this requirement depends on how it is configured, retained and documented in your environment.

Which systems and teams the audit record reduction requirement covers

Scope for 03.03.06 is set less by the tool you buy than by the records, stores, people and third parties that the tool touches. Each card below is a decision you should make and document before anyone configures a search or report, because each one changes what must be preserved, reviewed and evidenced.

Systems inside the CUI boundary

Every system that generates audit records for CUI, including servers, applications, identity providers, endpoints and network devices, falls into the reduction capability's scope if its records are reviewed or investigated. For example, an illustrative file server whose access logs feed a search dashboard is in scope even if the dashboard runs elsewhere. Check that the boundary in your system security plan matches the list of log sources your reduction tooling ingests.

Log stores and search tools

The indexes, databases and dashboards that hold or query audit records are where reduction actually happens, so they must preserve original content and time order. A filter that rewrites timestamps or drops fields can break after-the-fact investigation. Confirm whether your tooling stores normalized copies or the raw records, and document which copy is authoritative.

Reviewers and investigators

Staff who run searches, build summaries and reconstruct incidents need defined roles and access to the reduction tools, which are themselves sensitive. Identify who performs routine review, who handles investigations and who can export reports containing CUI-relevant detail. Those roles must line up with the access control and audit protection requirements so the people reviewing logs are not able to alter them.

Report outputs and their handling

Summaries, dashboards and exported reports can carry CUI-relevant detail even when the raw records do not. Decide where generated reports are stored, who receives them and how long they are kept, and whether they fall within the media protection and retention rules. Treat each recurring report as a scoped output, not an afterthought of the search tool.

Third-party logging and managed SOC services

Cloud logging services and managed SOC platforms that hold CUI-relevant records are part of the assessed environment when they store or process those records. Obtain the provider's responsibilities in writing, confirm where records are kept and how the provider supports search, filtering and export in original time order. Ask for the provider's own evidence of how it handles these records before relying on it.

Confirming parameters with the contracting agency

The federal agency holding the contract owns application and compliance questions for SP 800-171, and it is the party to ask when organization-defined parameters for this requirement are set or must be assigned. NIST does not assign those values, and if the agency does not specify them, the nonfederal organization must assign them. Record the agreed values in the system security plan so the reduction scope and review frequency can be tested against them.

Why reduction must never change the original audit record

Reduction, filtering, summarizing and report generation are views over audit records. They help a reviewer see what matters, but they do not replace the records themselves. An assessor testing 03.03.06 will check that the reduction capability preserves the original content and time ordering of audit records, and that the originals stay intact and retrievable for after-the-fact incident investigation. If a summary is the only thing an investigator can reach, the reduction capability has failed its purpose, even if every dashboard looks correct.

Several common practices break this in ways an assessor will notice. A parser or normalization step that rewrites fields, such as renaming user identifiers or truncating message text, changes the record without keeping the source. A dashboard that aggregates events and drops the raw entries leaves no path back to the underlying event. An export that re-stamps records on import or sorts them by ingestion time instead of event time breaks the time ordering. Retention that keeps only summaries, or that purges raw logs on a shorter schedule than the summaries built from them, removes the evidence an investigator needs. Ask the team to show one incident traced from a summary back to the raw record that produced it, and to show the stored timestamps on both.

This requirement depends on decisions made under 03.03.03 (audit record generation and retention) and 03.03.08 (protection of audit information). Generation and retention determine whether the originals exist for the full period the records retention policy requires. Protection determines whether those originals can be altered or deleted by the people who run the reduction tools. Reduction tools should read from write-protected stores and write derived outputs to separate locations. Confirm with the system owner where raw records are kept, who holds privileges to change them, and whether reporting accounts can modify source data. Any gap there undermines the claim that the reduction layer changes nothing.

How an assessor tests audit record reduction and report generation

This table groups the six SP 800-171A Rev. 3 determination statements for 03.03.06 by assessment method: examine, interview and test. Read each row as what the assessor checks, what proof they ask for, and where organizations most often fall short before the assessment begins.

Method and object	What the assessor looks for	Evidence requested	Common finding
Examine: audit and accountability policy and procedures	A documented policy and procedures that assign responsibility for reducing audit records and generating reports, and that set how reviews are done	Current audit and accountability policy, procedures for reduction and reporting, approval and review dates	Procedures describe logging in general but never mention reduction, search or report generation
Examine: procedures for audit record reduction and report generation	Step-by-step instructions covering how a reviewer searches, filters and summarizes records and how reports are produced	Runbooks, saved query libraries, report templates and example outputs	Runbooks exist only for the vendor interface and do not show how original records are kept unchanged
Examine: reduction, review, analysis and reporting tool configuration	Settings showing the tool can filter and summarize records and that it does not alter or drop the source data	Tool configuration exports, index or retention settings, access roles for query and report functions	Dashboards are configured, but no one can show that raw records remain available and in original time order
Examine: system audit records	Records that a reviewer can actually search, filter and summarize, with time ordering and original fields intact	Sample extracts of raw records, a query run live on the sample, and matching summary output	Summaries cannot be traced back to the underlying raw events, or timestamps show mixed or reordered sequences
Examine: system design documentation	Architecture showing where reduction and reporting happen, what components store records, and how the original copy is kept	Architecture diagrams, data flow diagrams, component inventory and retention design	Design documents omit the reporting layer or the copy that serves as the authoritative record
Interview: personnel with reduction and report generation responsibilities	Staff who can explain how they search and summarize records, how they keep investigations faithful to the source, and how they hand off reports	Named roles, training records for query and report tools, and examples of past investigation queries	Staff describe the tool from memory, and no one can explain how they confirm a summary matches the raw records
Interview: personnel with information security responsibilities	Security staff who can describe the capability's purpose, its use in review and after-the-fact incident investigation, and its limits	Incident examples where summarized records supported an investigation, and records of review meetings	Security staff have not used the reporting capability in an investigation, so its use in practice is unproven
Test: mechanisms supporting the reduction and report generation capability	The capability works when run: filters return expected results, summaries are generated, and original records remain unchanged and in time order	Test scripts, test results, before and after hash or count checks on source records, and test logs	Testing covers only that reports render, and nothing confirms that source records were not modified or reordered

Which evidence passes an audit record reduction assessment

An assessor testing 03.03.06 looks for proof that reduction and reporting tools work on the original records and keep their time order. The cards below describe the artifacts that show this, and each one needs a named owner and a refresh routine so it is current when the assessment begins.

Written reduction and reporting procedure

The organization's own procedure for how analysts search, filter and summarize audit records, which tools they use, which reports they produce and who approves a new report type. An assessor will check that the procedure matches what the tools actually do. Refresh it after any change to the logging stack and have the audit and accountability policy owner approve each revision. Illustrative: a procedure that names a tool no longer in service signals that the document was not maintained.

Tool configuration with filters and summaries

Configuration exports showing the filters, saved searches, aggregations and dashboards that run against a retained raw store, not a copy that has been trimmed. Check that the reduction layer reads from the same store that holds the original events. Export and version the configuration after each change, and have the platform engineering team own the refresh, with the security operations lead reviewing it.

Sample reports with source references

Recent reports that list the record identifiers, source system and original timestamps behind every summary line. A summary without record references cannot be checked against the raw events, so the assessor will ask for the link. Generate a fresh sample set before each assessment window and have the security operations team own the selection, keeping a record of which reports were chosen.

Traceability and time order demonstration

A live or recorded walkthrough in which a report figure is traced back to the original records, and the records are shown in their original time order with unchanged content. This tests the core of the requirement: reduction must not alter what was logged. Confirm that time stamps are preserved from generation (03.03.03) and that the timeline is not re-sorted in a way that hides the original sequence. Have the security engineering lead run the demonstration.

Access and change records for reduction tools

Access lists for the search and reporting consoles, plus change logs for filters, saved queries and report templates. These records show who can reduce or re-summarize audit data and whether those changes were approved. Review the access list on the schedule used for other privileged accounts, and have the identity administrator own the refresh with the audit owner signing off. Also confirm that the reduction tools' own activity is logged under 03.03.08.

Investigation timeline rebuilt from raw records

A worked example in which an investigator reconstructs an incident timeline from the retained raw records, using the reduction tools to filter and then reading the original events in order. The assessor will look for a complete sequence without gaps caused by summarization. Keep a current example from a tabletop or past investigation, with personal data removed, and have the incident response lead maintain it alongside the 03.06 incident handling evidence.

How to implement audit record reduction in order

This sequence takes a team from confirming the logs that feed reduction through to a documented, tested procedure that shows reviewers can search, filter and report on audit records without changing them or losing their time order.

Confirm upstream generation and content requirements are met
Before building any search or reporting layer, confirm that the events selected under 03.03.01 are generated with the content described under 03.03.02 and retained as required by 03.03.03. Reduction tools can only summarize what was recorded, so gaps here become gaps in every report. The owner is usually the system owner with the logging engineer, and the output is a short list of sources, their event types and their retention settings, checked against the system security plan. The step is done when each in-scope system has a confirmed log source.
Define the review and investigation questions
Write down the questions the tools must answer, such as which accounts changed a privileged setting in a given window, which hosts produced failed logons for one user, or what a single session did from start to finish. Include the questions assessors and incident responders are likely to ask, and the reports reviewers expect each month. Involve security operations, incident response and the compliance lead. The output is a dated question catalog that will serve as the acceptance criteria for the next step.
Select the search, filter and reporting capability
Choose the tooling that will search, filter and summarize records against the question catalog. Open-source options such as OpenSearch with Security Analytics, or Wazuh with its ruleset and alert outputs, can serve as the reduction layer, and each should be checked against the catalog rather than against a feature list. Confirm in writing that the chosen tool reads from a separate copy or index and does not write back to the raw store, and that original fields and timestamps are preserved. The output is a signed design note that names the tool, its data path and its read-only controls.
Build the reports and dashboards
Create saved searches, filters, scheduled summaries and dashboards for each question in the catalog, and make every summary link back to the underlying raw records. Keep report logic in version-controlled configuration so changes are traceable. The engineer builds the content and the security lead reviews it against the catalog. The output is a set of tested reports, each with a stated purpose, a data source and an owner, and each able to show the source records behind a count or summary.
Prove time ordering and traceability with a test investigation
Run a controlled investigation on a test or staging system. Generate known events, then use the reduction tools to find them, filter them and reconstruct their sequence. Compare the reconstructed order with the raw timestamps and check that the summary counts match the source records. Record any mismatch, fix the cause and rerun. The output is a dated test record showing the scenario, the queries used, the result and the comparison with raw data. This is the evidence that the capability works as the requirement describes.
Write the procedure and collect the evidence
Document how analysts run reduction and reporting, who reviews the output, how often reports are produced, and how investigations are recorded. Package the design note, question catalog, configuration exports, reports, test record and access settings for the read-only store. Ask the independent assessor which evidence they will examine, interview and test, and confirm that your package addresses each one. The output is a procedure with an approval record and an evidence folder mapped to the assessment methods in SP 800-171A Rev. 3.

Which open-source tools can support audit record reduction evidence

Audit record reduction under 03.03.06 depends on a chain: a source application writes records, a store keeps them unchanged, and an analytics layer filters, correlates and reports on them. The four tools below each cover a different link in that chain, so an assessor will expect you to show how they fit together and which one produces the reviewed output.

Nextcloud audit logging

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. This is a source of records rather than a reduction tool, so it supports 03.03.06 only once its output is fed into a search or reporting layer. Confirm the log path, file permissions and whether the log is forwarded off the host, since a reduction tool can only summarize records it can reach in their original form.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. That hashing lets reviewers correlate events without exposing secrets, but it also means reduction tools must match on hashed fields. Confirm which fields remain readable, how the audit device is configured for redundancy, and whether the JSON format is accepted by your chosen analytics tool.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and a correlation engine links findings across log types into a correlation graph. For 03.03.06, these findings and graph views are the summarized output a reviewer uses. Confirm how original records are linked from each finding and that report export preserves the original time order.

Wazuh rules and alerts

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for dashboard review. Its alert files give a reviewer a filtered, time-stamped record. Confirm that report generation keeps the unfiltered source events available for after-the-fact investigation, and review how rule changes are documented and controlled.

License review for each tool

The tools carry different licenses: Nextcloud is AGPL-3.0-only, OpenBao is MPL-2.0, OpenSearch is Apache-2.0 and Wazuh is GPL-2.0-only. These terms govern how you may modify, distribute or host each component, and the obligations differ when you customize code or bundle several tools together. License review is the organization's responsibility, so have counsel confirm the terms that apply to your deployment before you build the reduction pipeline.

What audit record reduction costs to meet

This table breaks the cost of meeting 03.03.06 into its components, showing who is paid, whether each cost is one-time or recurring, what drives it up, and what to request in a quote. Open-source tooling removes license spend, but hosting, storage, engineering and assessment time still carry cost, so use the drivers column to compare written scopes.

Cost component	One-time or recurring, and who is paid	Drivers that raise it	Levers that lower it and what to request in a quote
Tooling and licenses	Recurring if any commercial add-ons or support are chosen. Open-source search, SIEM and secrets tools carry no license fee, but infrastructure does.	Number of commercial modules, support tiers, and extra capacity needed for review dashboards	Confirm which components are open source and which are optional paid add-ons. Request a line item for each, with the license terms and version pinned.
Hosting and compute for reduction tools	Recurring, paid to the cloud provider or data center operator that runs the search and reporting nodes	Volume of records ingested per day, search concurrency, and number of dashboards refreshed	Size indexes to actual query patterns, schedule heavy reports off-peak. Ask for compute sizing tied to stated ingest volume.
Engineering to build and tune filters and reports	One-time for initial filters, correlation views and report templates. Recurring for tuning. Paid to the implementation partner or internal staff.	Number of log sources normalized, number of distinct report types, and how many custom rules are required	Start with a fixed set of report templates tied to named reviews. Request a written list of deliverables, the log sources covered, and what counts as a change request.
Storage for retained raw records	Recurring, paid to the storage provider. Original records must be kept unchanged so reduced views can be rebuilt.	Retention length set by the organization, total record volume, and replication or backup copies	Keep raw records in write-once or access-restricted storage and index only the fields reviewers need. Ask for storage projections at the approved retention period.
Evidence upkeep	Recurring, paid to internal staff or the partner. Covers saved report outputs, query logs, and proof that the original records were preserved.	Number of reports produced, review frequency set by the organization, and number of systems in the CUI boundary	Automate report archiving with timestamps. Request a description of how each report is stored, versioned and tied to a review record.
External testing or review	Periodic, paid to an independent tester or reviewer if chosen. Testing does not produce the official assessment.	Scope of the boundary, number of log sources tested, and whether the tester must recreate a past investigation	Limit the test to the reduction and reporting path. Request the test objectives, the sample of records used, and the report format before work starts.
Assessor sampling	Paid to the independent assessor during an assessment. Only the assessor issues the assessment result.	Number of reports and investigations the assessor asks to see, and gaps in documented evidence	Keep a ready index of past reviews and report outputs. Ask the assessor to confirm the sampling approach in writing before fieldwork.

Who builds, who prepares evidence and who assesses this requirement

Your organization owns 03.03.06 in full. The requirement asks for a capability that lets people search, filter and summarize audit records for review, reporting and after-the-fact investigation, while the original content and time order of the records stay intact. Deciding what that capability must answer, who uses it and what a finding looks like is a management and security decision, not a tooling decision, so it cannot be handed to a vendor or partner.

Review procedure ownership: Write and approve the procedure that says who runs reduction and reporting, how often, and what gets escalated.
Report selection: Decide which summaries matter, such as failed privileged logons or changes to access rights, and retire reports nobody reads.
Investigation staffing: Name the analysts who run after-the-fact investigations and make sure they have the access and training to do it.
Integrity rules: Set the rule that reduced views are derived copies and that originals are retained unchanged, then confirm it with the platform owner.
Evidence of operation: Keep dated review records, sign-offs and investigation notes, since these show the capability is used rather than merely installed.

Confirm with your assessor which policy and procedure documents they expect to see under the audit and accountability family before you finalize the review procedure.

Common questions about audit record reduction and report generation

How much effort does audit record reduction and report generation take, and what drives it?

The effort depends mostly on how many log sources feed the system, how varied their formats are, and how many review and reporting use cases the organization must support. A single application with one log format is far simpler than a mix of identity providers, endpoints, cloud accounts and network devices that each write records differently. Work usually falls into a few parts: deciding which searches, filters and summaries reviewers need, configuring parsing so records can be queried, building saved reports, and testing that the original records and time order survive every transformation. No public effort figure applies to this requirement, so ask any provider to break the estimate down by log source, report type and reviewer role.

Can an in-house team meet 03.03.06 without an outside partner?

Yes, an organization can build and operate this capability with its own staff, and nothing in the requirement obliges it to hire an implementation partner. The practical question is whether the team has people who understand both the logging tools and the review workflow, and whether they can keep the capability working after go-live. Partners are most useful when the team lacks experience with query languages, parsing pipelines or evidence packaging, or when the deadline is tight. Whichever route is chosen, the organization owns the requirement, and an independent assessor will test the result.

What does the organization's staff need to provide during the work?

Engineers need access to the systems that produce audit records, the current audit and accountability policy, and the procedures that describe how records are reviewed and reported. Security staff must confirm which reviewers, investigators and report consumers need which views, because those answers set the search and summary design. Someone with authority must approve the reduction rules, since filtering that hides relevant events can break investigations. Expect the organization's personnel to be interviewed later, so the people who will run reviews and investigations should take part in design, not only in testing.

How long does it take to put this capability in place?

The duration depends on the number of log sources, how much parsing and normalization is needed, and how many approval cycles the change must pass through. Environments that already centralize logs usually move faster than those that must first collect records from scattered systems. No supplied timeline applies, so ask for a schedule tied to named milestones, such as source onboarding, report design, time-order testing and handover, and confirm which of those the organization must do itself.

Does a SIEM or log platform alone satisfy 03.03.06?

A log platform can provide much of the capability, but installing one does not satisfy the requirement by itself. The organization must show that the tools support review, analysis, reporting and after-the-fact investigation, and that they preserve the original content and time order of the records. Check whether the platform keeps unmodified source records, whether normalization changes timestamps or fields, and whether reports can be rerun against the same evidence. Open-source options such as OpenSearch Security Analytics or the Wazuh ruleset can support detection and alerting, but the organization must confirm each capability it relies on in its own configuration.

What will an assessor ask to see for this requirement?

An assessor working from SP 800-171A Rev. 3 will examine the audit and accountability policy and procedures, the procedures for reduction and report generation, and the tools used for review and reporting. They will look at sample system audit records and the system design documentation, and they will interview people who run reductions and reports and people with information security responsibilities. They may also test the mechanisms directly, for example by filtering a known event and confirming that the original record and its timestamp are unchanged. Prepare a short evidence set that maps each of these items to a current document or screen capture.

How DeployOpen scopes and prepares audit record reduction evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the search, filter and summary tooling for 03.03.06 runs where your audit records already live. We prepare the configuration, documentation and evidence that an independent assessor reviews, while your organization owns the control and the assessor issues any formal result.

How we scope

Written scope names the systems whose audit records feed the reduction and reporting tooling.
Scope lists the review, analysis and reporting users and the investigation workflows each must support.
Scope states which 03.03.06 evidence we prepare and which parts your organization or assessor owns.

How we build

Configure search, filter and summary views that keep original record content and time ordering intact.
Confirm each reduction or reporting tool preserves unaltered source records for after-the-fact investigation.
Test report generation against sample incident questions, recording results for the assessor to examine.

How we hand over

Deliver configuration documentation mapping each tool to the 03.03.06 determination statements it supports.
Provide runbooks for producing audit reports and for reconstructing an incident timeline from raw records.
Hand over test records and interview-ready summaries so your personnel can explain the capability to an assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover re-testing reduction and reporting tools after platform upgrades or rule changes.
Ask any quote to state which 03.03.06 evidence refreshes on a recurring basis and who performs it.