AU-6 audit record review: requirements and evidence

What AU-6 audit record review requires under NIST SP 800-53

AU-6 requires your organization to review and analyze system audit records at a defined frequency for defined signs of inappropriate or unusual activity, report the findings to defined personnel, and adjust the level of review when credible information shows that risk has changed. If an assessor asks why a log source exists, the answer must describe who reads it, how often, what they look for and what happens when they find something. Collecting logs without that answer is the gap AU-6 addresses. Logs that nobody reads detect nothing, and an incident is often visible in the records long before anyone is alerted to it. Three problems make this control hard in practice. The first is an undefined frequency: the organization has never written down whether review is daily, weekly or triggered by alerts, so no one can show that it happened. The second is unclear reviewers: the responsibility sits with a shared mailbox or a team that assumes another team is watching. The third is logs collected but never reviewed, where a SIEM or log store is filling up with data that no workflow touches. AU-6 applies to the low, moderate and high SP 800-53B baselines but not to the privacy baseline. The organization owns this control and its decisions about frequency, scope and escalation. An implementation partner can prepare the review workflow, the alerting and the evidence trail, but the organization must confirm that the defined parameters match its own risk.

The practical work starts with a short set of decisions. Name the log sources in scope, the personnel who review each one, the review frequency and the criteria that count as inappropriate or unusual activity. Record how findings are reported and what triggers a change in review depth, such as a new threat intelligence report, a security incident or a significant change to a system. Then confirm these settings in the systems themselves. In an open-source stack, that might mean checking the rules that feed Wazuh alerts or OpenSearch Security Analytics detectors, and confirming that alerts reach a named queue rather than a dormant channel. Keep the review records: who reviewed, when, what was found and what action followed. The enhancements matter once the baseline is clear. AU-6(1) concerns integrating review with other automated processes, and AU-6(3) concerns correlating audit repositories. The high baseline adds integrated analysis (AU-6(5)) and correlation with physical monitoring (AU-6(6)). Confirm with your assessor which enhancements apply to your system category before you design tooling. Ask your auditor or assessor to confirm whether your defined parameters are sufficient and which evidence they will sample.

Which systems, logs and teams AU-6 reaches

AU-6 scope is set by three choices: which baseline a system falls under, which log sources feed review, and who holds review duties. Each choice changes how much monitoring, reporting and evidence an assessor will expect, so settle them in writing before counting effort.

Baseline selection sets the AU-6 scope

AU-6 is selected for the low, moderate and high baselines, but not for the privacy baseline. A system categorized as low still needs AU-6 review, and the moderate and high baselines add enhancements. Confirm the impact categorization for each system boundary first, because a system that only processes personally identifiable information may fall under the privacy baseline without any AU-6 obligation. Record the selected baseline in the system security plan so the assessor can trace each review duty to a system.

Host and identity log sources

Hosts, domain controllers and identity providers generate the authentication and privilege events that AU-6 reviews most often. Inventory which sources forward logs at all, which ones keep local logs only, and whether time stamps agree across them. A review scope that omits identity sources usually misses account misuse, so confirm that each source appears in the review plan with an owner and a defined frequency.

Network and cloud control plane logs

Network devices, firewalls and cloud control planes record changes to routing, security groups and administrative roles. These logs often arrive in different formats and volumes than host logs, which affects how detectors are written. Ask which control-plane events are captured by default and which need explicit enablement, and confirm retention periods with the platform owners. Without these sources, reviews of privileged cloud changes have nothing to analyze.

SaaS admin and self-hosted application logs

SaaS administrative consoles and self-hosted applications hold their own audit trails, such as administrative role changes, data exports and sharing events. Nextcloud's admin_audit app, for example, writes additional event information to audit.log in the data directory unless a different path is set with logfile_audit. Confirm which application events are enabled, where they are written, and whether they are shipped to the central review point, since an unshipped local file is rarely reviewed.

Internal teams and third-party reviewers

Review duties may sit with a SOC, platform engineering or a managed security provider. AU-6 requires the organization to define who reviews, who receives findings and who acts on them. Where a provider reviews logs on your behalf, the reporting path and the authority to adjust review frequency must still be documented and owned internally. Ask for the written handoff between teams, the escalation path and how provider findings are recorded in your own tracking system.

Records shared with related controls

The same audit records support AU-7 reduction and report generation, AU-16 cross-organizational logging, CA-7 continuous monitoring and AC-2 account management. A change in review scope therefore affects several controls at once. Map which reports feed which control, and confirm that a finding from AU-6 review can be traced to a CA-7 monitoring record or an AC-2 account action. Shared records reduce duplicated work only when the mapping is written down before assessment.

How an assessor tests AU-6 with examine and interview methods

This table maps the three AU-6 determination statements to the examine and interview methods an assessor uses, the objects each method reads, the evidence to prepare and the findings that appear most often. Read each row as a testing step: prepare the artifact named in the evidence column before the assessor asks for it.

Assessment element	What the assessor checks	Evidence to prepare	Common finding
Review frequency and scope (examine)	A defined review frequency exists, and the review covers the audit records the organization has chosen to generate under AU-2 and AU-12.	Written review frequency, list of log sources in review scope, and the procedure that names the reviewers.	Frequency is stated in policy but never defined for specific log sources.
Detection of inappropriate or unusual activity (examine)	Reviews look for defined types of inappropriate or unusual activity and consider the potential impact of each.	Detection use cases or rule list, sample alerts with triage notes, and the list of activity types the organization defines as in scope.	Review checks generic log volume but no defined activity types are documented.
Reporting of findings (examine)	Findings go to defined personnel, and the reports record what was found.	Reports of audit findings, distribution lists, and ticket or case records linked to each finding.	Reviews happen but no recorded output exists to show findings were reported.
Actions taken in response (examine)	Records show what the organization did after a review or analysis produced a finding.	Records of actions taken, such as incident tickets, escalations or closure notes tied to specific audit findings.	Findings are closed without a record of the action taken or the reason for closure.
Adjustment of review on changed risk (examine)	The organization changes review depth or frequency when credible information shows a change in risk.	Risk event records, dated changes to review scope or frequency, and approvals for those changes.	No evidence that review depth changed after a known risk event, such as a threat advisory or a significant incident.
Responsible personnel (interview)	Staff with audit review, analysis and reporting responsibilities can explain what they review, how often and what they do with findings.	Named role assignments, training or onboarding records for reviewers, and a current on-call or review rota.	Interviewees describe a review routine that differs from the written procedure.
Review adjustment decisions (interview)	Personnel can describe how they learn of changes in risk and how that changes their review.	Threat intelligence feed subscriptions, escalation paths and a short description of past adjustments.	Staff cannot name the trigger that would change review depth.

Which AU-6 enhancements the high baseline adds

AU-6 has 10 numbered enhancements in SP 800-53 Release 5.2.0, but only 8 of them are current because AU-6(2) and AU-6(10) are withdrawn. The baselines in SP 800-53B select just four of the current enhancements. AU-6(1) and AU-6(3) are added at the moderate level and carried into high, while AU-6(5) and AU-6(6) apply only to high systems. Before you plan evidence, confirm the enhancement numbers and titles against the Release 5.2.0 catalog in your own tooling, since assessors will cite the current numbering.

AU-6(1) asks that the review and analysis process be integrated with other automated processes, so that suspicious activity is surfaced by machines rather than found by someone reading logs by hand. In practice, a moderate system needs to show that a detection rule or analytics job runs against its audit records, that its findings reach a ticketing or alerting channel, and that the configuration of that pipeline is itself controlled and reviewed. A Wazuh deployment with custom rules writing to alerts.json and a forwarded alert queue is one illustrative pattern. AU-6(3) asks that audit records held in different repositories be correlated, which matters once logs from identity systems, endpoints and applications sit in separate stores that no single analyst can join by eye.

AU-6(5) and AU-6(6) are where a high system needs a single analytical view. AU-6(5) expects integrated analysis across audit records from multiple sources, and AU-6(6) expects analysis to be correlated with physical monitoring, such as badge access or facility surveillance records. Decide early who owns the correlated view, which physical data sources are in scope, and how the link between a logical event and a physical access record is recorded. Ask your team or implementation partner to confirm which of these capabilities the chosen platform, such as OpenSearch Security Analytics correlation graphs, supports natively and which need custom integration.

How to build an AU-6 review process that produces evidence

This sequence turns AU-6 from a policy statement into a repeatable review cycle, where each step leaves a record that an assessor can examine and trace back to the requirement.

Define review frequency and activity types
The organization sets the review frequency it has defined for each system, along with the inappropriate or unusual activity types reviewers must look for, such as failed logons clustered in time, privilege changes outside change windows, or unexpected administrative access to audit tooling. Both decisions are written into the review procedure and approved by the control owner. The step is complete when the procedure names the frequency, the activity list and the systems it covers. Ask the assessor what they expect to see: a dated, approved procedure that matches the systems in the scope statement.
Assign named reviewers and reporting recipients
Name the people who perform reviews and the defined personnel who receive findings, and record a backup for each role so reviews continue during absence. Reviewers need access to the relevant log sources and enough system knowledge to judge whether an event is unusual. The output is a responsibilities matrix or RACI tied to the review procedure, with signed acknowledgments from the people named. Confirm with the assessor that the named roles match the interview objects in SP 800-53A, since personnel with audit review and reporting responsibilities are examined directly.
Configure detection tooling for defined log sources
Connect the log sources in scope to a review or detection platform and document which sources feed which detectors. Open-source options include OpenSearch Security Analytics, which runs detectors against ingested logs using Sigma rules and records matches as findings, and Wazuh, which compares decoded events against its ruleset and writes alerts for review. Application logs such as the Nextcloud admin_audit output in audit.log and OpenBao audit device logs can be routed in the same way. Keep a record of each rule set version, detector and source mapping, and confirm the product capabilities against current vendor documentation before relying on them.
Run reviews and record each outcome
Reviewers work through alerts, detector findings and log extracts at the defined frequency, then record for each cycle the period covered, the sources reviewed, the events examined, and the disposition of each item: no finding, finding under investigation, or finding closed. Records should show who performed the review and when it was completed. A review with no findings still produces a record, because an empty cycle is evidence that the review occurred. Ask the assessor to examine a sample of these records against the reporting cycle to confirm the frequency was met.
Route findings into tickets and reports
Each finding that needs action is opened as a ticket in the organization's tracking system with the source event references, severity, owner and the required response. Findings are summarized in a periodic report to the defined recipients, showing what was reviewed, what was found, and what actions were taken. The evidence is the chain from report to ticket to closure, including the action records. Confirm that tickets link back to the underlying audit records so the assessor can trace a finding from the report to the original event without relying on verbal explanation.
Set triggers that change review depth
Define the conditions under which the level of review increases, such as a new threat advisory, a security incident affecting the same systems, a change in system ownership, or a new administrative account. When credible information indicates a change in risk, the review procedure states how the frequency, scope or depth changes and who approves the change. Record each trigger event, the decision, and the adjusted review schedule. Assessors commonly look for documented decisions that show the review was actually adjusted, so keep a dated log even when no change was needed.
Review the process and update the procedure
Periodically examine whether the frequency, activity types, sources and recipients still fit the systems and the risk picture, and update the procedure where they do not. Feed lessons from closed findings and missed events into the next cycle. The output is a documented review of the AU-6 process with dated changes, approvals and the reasons for them. This closes the loop that AU-1 and the continuous monitoring program depend on, and it gives the assessor evidence that the review process itself is maintained rather than set once.

Evidence that shows AU-6 review is operating

An assessor testing AU-6 looks for proof that review happened on the schedule the organization defined, that findings were reported and acted on, and that review depth changed when risk changed. The cards below cover the artifacts that prove each part, and how to keep them current between assessments so the evidence is not rebuilt in a rush.

Written review frequency and procedure

The policy or procedure states how often each audit source is reviewed, which defined activities count as review (such as triaging alerts, checking privileged account use and reviewing failed logons), and who performs each step. Assessors compare the document against what staff actually do, so the frequency must be one the team can meet. Review the document at least annually and after any change to log sources or staffing, and record the revision date and approver in the document header.

Review logs and dashboard activity records

Assessors look for a record of who reviewed which logs, when, and what they concluded. A ticket queue, a review log in a case tool, or dashboard acknowledgment history can serve this purpose, provided each entry shows a reviewer name, a date and a scope. Keep these records as they are created instead of compiling them before an audit. Confirm that your chosen platform retains acknowledgment and alert history long enough to cover the assessment period.

Reports of audit findings to defined personnel

AU-6 requires findings to go to the personnel the organization named in the control parameters. Keep dated reports, showing the recipient list, the activity reviewed and the potential impact identified. Alert notifications sent to a shared channel or email alias are useful only if the distribution list matches the defined roles and membership changes are tracked. Retain sent copies so the record shows the report left the system.

Records of actions taken on findings

A finding without a recorded response does not show that review led to action. Keep the linked case or incident record for each finding, with the disposition (closed as benign, escalated, or converted to an incident), the owner, and the closure date. An assessor often samples a few findings and traces each one from the original alert to the action taken. Set your case tool so a finding cannot close without a disposition.

Review-depth change records after risk events

AU-6 expects review depth to change when credible information shows a change in risk, such as a threat advisory, a failed penetration test or a compromised credential. Record the triggering information, the decision, the new review scope or frequency, and the date it took effect, then record when the change was lifted. Without these entries, an assessor cannot tell whether the organization adjusts review or simply keeps a fixed routine.

Detector and correlation configuration exports

If the organization uses the AU-6 enhancements for automated process integration or correlation across repositories, the assessor needs the configuration itself: detector definitions, rule sets, correlation settings and the log sources they read. Platforms such as Wazuh and OpenSearch Security Analytics store this as versioned rule and detector content, so keep exports under change control alongside the review records they generate. Re-export after each rule change and note the change ticket.

What meeting AU-6 costs in money and effort

This table compares the cost components of running AU-6 review and analysis, showing who is paid, whether each cost is one-time or recurring, what drives it up and how to keep it down. NIST does not estimate compliance costs, so the table names cost drivers rather than amounts; use it to scope a quote and to see where open-source tooling removes license spend but not staffing.

Cost component	One-time or recurring, and who is paid	What drives it up	How to keep it down
Tooling or licenses	Recurring for commercial SIEM or log analytics subscriptions; open-source platforms such as OpenSearch Security Analytics and Wazuh carry no license fee but still need hosting and storage	Volume of ingested logs, number of log sources, retention length, and vendor-specific features needed for correlation or central analysis	Confirm license terms with each vendor, size storage to the sources that AU-6 review actually needs, and separate hosting costs from license costs in any quote
Engineering time to configure detection and integration	One-time for initial rule, decoder and integration setup, then recurring for tuning; paid to internal staff or an implementation partner under a written scope	Number of log sources to onboard, custom detection content, and how many AU-6(1) automated process integrations are selected	Start with a defined set of high-value sources, reuse prepackaged rules where they fit, and agree the integration scope in writing before work starts
Reviewer time for recurring review	Recurring; paid to internal analysts or an outsourced monitoring provider for reviewing findings at the frequency the organization defines	Review frequency set in the organization's parameters, alert volume, false positive rate, and whether review is 24 hours a day or business hours only	Tune detections to reduce noise, document the review frequency the organization can sustain, and ask providers to state how alerts are triaged and escalated
Reporting and response records	Recurring; internal staff prepare reports to defined personnel and records of actions taken in response to reviews	Number of recipients, reporting cadence, and the volume of findings that need documented follow up	Automate standard report generation where the platform supports it and keep one consistent template for findings and actions
Evidence upkeep	Recurring; internal compliance staff or the implementation partner keep review logs, findings, and change records current	Frequency of assessments, number of systems in scope, and changes to review parameters after risk changes	Store findings and review records in a single system of record, and update evidence at the same time as configuration changes
External testing or review	Periodic; paid to an independent assessor or a testing firm, which is separate from the implementation partner	Baseline level (AU-6 applies to low, moderate and high), enhancements selected, and the number of systems sampled	Ask the assessor to confirm the scope and sampling approach before fieldwork, and prepare evidence against the assessment objects in advance
Auditor sampling	Periodic; paid to the independent assessor under a separate engagement, not to DeployOpen	Number of review cycles in the assessment period, and how many findings and actions the assessor selects for testing	Keep review cadence consistent and documented so the sample is easy to pull, and resolve open findings before testing begins

Open-source tools that produce AU-6 review evidence

Self-hosted logging and detection tools can generate much of the raw material an assessor looks for under AU-6: findings, alerts, action records and audit trails of the platforms themselves. None of them performs the review, signs it off or documents the response, so the organization still owns the procedure and its records. Each card below names what a tool supplies, what it leaves to the organization and the license or version points to confirm.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules, and records each match as a finding with its rule, log type and severity. Its correlation engine links findings across log types in a correlation graph, which supports the analysis step AU-6 describes. Alerts can go to channels such as Slack or email. The review cadence, triage decisions and closure notes still come from your analysts. Confirm detector and correlation features in your deployed version. License: Apache-2.0.

Wazuh rule-based alerting

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. These files are useful evidence that defined activity was flagged, but a rule firing is not proof that a person reviewed it. Keep the reviewer's disposition for each alert group in your case system. License: GPL-2.0-only, so check how your distribution and any modifications are licensed.

Nextcloud admin_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. For AU-6, this gives reviewers a file-level trail of administrative and security-relevant actions on the file platform to examine against defined activity. Confirm which events your server version records and where the log path is set, because coverage varies by configuration. Nextcloud does not decide what counts as inappropriate activity, and the review schedule and findings report must be documented by the organization. License: AGPL-3.0-only, which matters if you modify and offer the service over a network.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. Reviewers can use these records to examine privileged secret access and unusual request patterns, and to show that review covered the secrets platform itself. Hashing protects values but does not stop an analyst from needing a process for comparing hashed fields. Confirm the audit device configuration in your environment, and keep the reviewer sign-off and escalation records outside the device. License: MPL-2.0, which applies file-level copyleft to modified source files.

Who owns AU-6 work, what partners prepare and what auditors test

Your organization owns AU-6 in full. The control asks you to review and analyze system audit records at a defined frequency, decide what counts as inappropriate or unusual activity, report findings to defined personnel and change the level of review when credible information shows that risk has changed. None of those decisions can be delegated to a tool or a vendor, even when a tool produces the alerts that start the review.

Review procedure: Write down what is reviewed, how often, by whom, and what an analyst does when a finding appears. The procedure is the first thing an assessor will examine.
Named reviewers: Assign specific roles or people to the review, with backups, and record who holds responsibility for each log source.
Findings decisions: Record the disposition of each finding, including dismissed alerts, escalations and the reasons behind them.
Risk-triggered changes: Define the events that cause review frequency or scope to increase, such as a threat advisory, a failed audit, or a significant system change, and keep records of each adjustment.
Reporting lines: Name the defined personnel who receive findings and show that the reports reached them.

Before an assessment, confirm that your procedure matches what analysts actually do and that the records of their decisions exist.

Where AU-6 programs usually fall short

AU-6 fails in predictable places: the review rhythm exists on paper, logs sit unread in a central store, and findings never leave a trail. The cards below pair each gap with one fix and the evidence an assessor would expect to see after the fix is in place.

Review frequency set in policy only

AU-6 requires a defined review frequency, but many programs write a number into the policy and never schedule the work. Close the gap by putting each review cycle into the ticketing or task system with an owner and a due date, then keep the completed tickets. Evidence to keep: dated review records showing who reviewed which log sources and when, and any missed cycles with the reason. Ask the auditor which sample period they will test before you set the cadence.

Central logs nobody reviews

A log platform that ingests every source is not the same as a review process. Assign defined log types to named reviewers and define what counts as inappropriate or unusual activity for each one, such as failed privileged logins or changes outside a change window. Tools like Wazuh and OpenSearch Security Analytics can generate alerts that feed the review queue, so reviewers work from findings rather than raw volume. Evidence to keep: the alert-to-review workflow, detector or rule configuration, and closed alert records.

Findings reported verbally only

AU-6 expects findings to be reported to defined personnel, and an assessor will ask to see the report. Verbal hallway updates leave no record of what was found, who was told, or what happened next. Use a standard finding template that captures the event, its potential impact, the recipient, and the action taken, and store it in the case management system. Evidence to keep: written findings reports and the records of actions taken in response, which SP 800-53A lists as examine objects.

Review depth unlinked to risk

AU-6 asks that the level of review change when credible information shows a change in risk, such as a threat intelligence alert, a new privileged account, or a vulnerability disclosure affecting a key system. Many programs review every log at the same depth at all times. Document the triggers that raise review depth, the people who decide on the change, and how long the heightened review lasts before it returns to baseline. Evidence to keep: dated risk-change decisions with the information that triggered them, and records showing the adjusted review.

Enhancements claimed without automated evidence

AU-6(1) covers automated process integration, AU-6(3) covers correlating audit record repositories, and AU-6(5) and AU-6(6) cover integrated analysis and correlation with physical monitoring in the high baseline. Organizations often state these are in place without showing the integration working. Confirm each enhancement you claim against the baseline that selects it, and export the configuration and sample correlated events that show the integration operating. Evidence to keep: correlation rules, integration configuration, and a sample of correlated records. Confirm the exact requirements with your assessor, since the enhancement text is in the control catalog.

Reviewers without training or time

A review program depends on people who understand the log sources and have protected time to work through them. Reviewers who are new to a system or who carry a full operations load tend to skim or skip. Set a training path covering each log source they review, and allocate review hours in the role description so the work is planned rather than squeezed in. Evidence to keep: training records for reviewers, role assignments that include review duties, and workload or rota records that show the review occurred.

AU-6 questions buyers ask before hiring outside help

Can we do AU-6 audit record review in-house, or do we need outside help?

Many organizations can run AU-6 in-house if they already have log sources, a defined review frequency and staff who can triage alerts. The effort depends on how many systems produce audit records, how much of the review is automated, and whether reviewers can show findings and follow-up actions. Your own team owns the control and the review decisions. An outside implementation partner is most useful when the work is to deploy and integrate a log analytics platform, write detection content, and prepare the review records an assessor will ask for. No effort figure for AU-6 is supplied here, so ask any partner to break its estimate down by log source, detection content, integration work and evidence preparation, and to state which of those tasks your staff would perform.

How long does AU-6 preparation take?

No preparation duration for AU-6 is supplied, so treat any single number with caution. The timeline is driven by the number of log sources to onboard, whether a central analytics platform already exists, how mature the detection rules are, and how many review cycles you need to produce a record of findings. Organizations that already collect logs centrally usually have a shorter path than those starting from scattered local logs. Ask for a timeline in the written scope with milestones such as log source onboarding, rule tuning, a pilot review cycle and evidence handover, and confirm which milestones depend on your change approval and staffing.

What does AU-6 require from our staff day to day?

AU-6 needs named people who review audit records at the frequency your organization defines, look for inappropriate or unusual activity, record what they found and what they did about it, and report findings to the personnel you have defined. Your staff must make the judgment calls, such as deciding whether an alert is a real incident or a false positive, and they must be able to explain their reasoning to an assessor. Expect time for alert triage, periodic review of the review itself, and changes to review depth when threat information or system risk changes. Interviews are part of the assessment, so the people with these responsibilities should understand the procedure and their role in it.

Can open-source tools produce the AU-6 evidence an assessor expects?

Open-source platforms can generate much of the evidence AU-6 assessments look for, but the tool does not make the control compliant on its own. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules, records matches as findings with severity, sends alerts to channels such as Slack or email, and correlates findings across log types. Wazuh compares events against a ruleset of over 3,000 built-in rules and decoders, writes alerts to alerts.log and alerts.json, and maps alerts to MITRE ATT&CK. Your evidence still needs documented review decisions and records of actions taken. Confirm each platform's capabilities against its current documentation before you rely on them in an assessment.

Can an implementation partner issue the AU-6 assessment report?

No. An implementation partner prepares systems, configurations and evidence, but only an independent assessor, auditor or certification body issues assessment results. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Your organization owns its controls and its risk decisions. In practice, the partner configures log sources and detection content, documents the review process, and packages the records that show findings and responses. Your assessor then examines those records, interviews the responsible people and reaches their own conclusions. Ask any vendor to state this division of roles in writing.

Which baselines select AU-6 and which enhancements apply?

SP 800-53B Release 5.2.0 selects AU-6 for the low, moderate and high baselines but not for the privacy baseline. The moderate and high baselines add AU-6(1) on automated process integration and AU-6(3) on correlating audit record repositories. The high baseline alone adds AU-6(5) on integrated analysis of audit records and AU-6(6) on correlation with physical monitoring. Your system's impact level determines which baseline applies, and tailoring can change the final control set, so confirm your selection with the people who own the system categorization. Check the current baseline profiles in NIST's OSCAL content before you write requirements into a contract.

How do we ask for a fixed-scope quote for AU-6 work?

Ask for a written, fixed-scope proposal that lists the systems and log sources in scope, the detection content to build, the integrations to deploy, the evidence deliverables, and the tasks your staff will carry out. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list; a quote follows from the written scope. Ask which items are one-time and which recur, such as rule tuning, platform upgrades and review support under a retainer. Also ask what is excluded, including the independent assessment itself, and what changes would require a new quote.

How DeployOpen scopes and prepares AU-6 evidence

DeployOpen prepares the logging, review and reporting setup that an AU-6 assessment examines, inside your own infrastructure. We build on self-hosted open-source platforms and hand over the records, configurations and documentation your organization owns, while independent assessors make any judgment about conformance.

How we scope

Agree which systems, log sources and review personnel fall inside the AU-6 boundary in writing before work starts.
Confirm the review frequency and the baseline your organization selected, such as moderate or high, so enhancements are scoped correctly.
Define which findings go to which named personnel and how review levels change when your risk assessment changes.

How we build

Configure detectors and rule sets in the chosen open-source platform to match your defined inappropriate or unusual activity categories.
Integrate alerts with your ticketing or notification channels and test that each finding is recorded with its rule and severity.
Set up correlation across repositories and physical or identity sources where AU-6 enhancements apply to your baseline.

How we hand over

Deliver configuration exports, rule inventories and sample finding records that show the review process operating as documented.
Provide a written AU-6 procedure mapping each determination statement to the evidence your organization holds for it.
Document the review log, escalation records and changes to review level so assessors can examine them directly.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
Re-verify rule sets and integrations after platform upgrades so review evidence stays consistent over time.
Confirm with your assessor which artifacts they expect for interviews and examinations before the assessment begins.