What AU-2 event logging asks you to decide
An assessor or authorizing official reviewing AU-2 event logging wants proof that your organization chose its logged event types on purpose, not by accident of default settings. The control asks you to make that choice and be able to explain it. It has four duties: identify the event types the system can log, coordinate logging with the other parties that need audit information, specify which event types are logged and how often, and document why that selection supports after-the-fact incident investigations. A fifth step, reviewing the selection at a defined frequency, keeps the decision current as the system and its threats change. The control is in the low, moderate and high baselines and the privacy baseline in SP 800-53B Release 5.2.0, so most systems in scope will need a documented answer.
The investigation risk is the core of the control. If an intrusion, data disclosure or insider incident happens and the logs never recorded the relevant activity, the organization cannot reconstruct what happened. Selection is hard because both extremes fail. Logging everything floods storage, buries useful signal and makes review impractical, while logging too little leaves gaps no one notices until an incident. A workable approach names the event types tied to authentication, privileged actions, changes to security settings, access to sensitive data and administrative use of logging tools, then records the reasons. Confirm with your own assessor whether they expect the rationale per event type or per system. Also note that all four numbered enhancements, AU-2(1) through AU-2(4), are withdrawn in Release 5.2.0, so the base control stands alone and your evidence should trace directly to it.
Which systems and event types AU-2 covers
AU-2 applies wherever a system carries a low, moderate, high or privacy baseline, so scope starts with which systems are in the boundary. The decisions below set how many components, services and parties need to be covered by the logging selection, and each one changes the amount of work an assessor will test.
Systems inside the baseline boundary
AU-2 is selected in the low, moderate and high baselines and in the privacy baseline. Confirm which impact level each system carries and whether privacy baseline controls apply to systems that process PII. A system moved from low to moderate inherits a broader event selection, so the impact categorization decision directly changes the logging scope. Record the boundary in the system security plan so the logging selection matches it.
Application and platform components
List every component that can generate events: web applications, databases, container platforms, file sharing services and administrative consoles. For self-hosted open-source platforms, check each product's audit facility. Nextcloud's admin_audit app writes to audit.log, and OpenBao audit devices record API requests and responses. A component that cannot emit a selected event type needs a documented compensating source or an explicit acceptance of the gap.
Third-party and managed services
Cloud provider control planes, SaaS identity providers and hosted databases often emit events the organization does not control. Determine which of these events are inside the logging selection, whether the provider supplies them on request or through a stream, and what the contract says about retention and access. Missing provider events are a common gap that assessors find when they trace an administrative action to its source.
Identity and privileged administrative actions
Account creation, role changes, failed and successful logins, privilege escalation and changes to logging configuration are usually the first event types chosen under AU-2. Include actions by service accounts and automated processes as well as human administrators. Confirm that disabling or modifying the audit facility is itself a logged event, because an investigator needs to know when visibility was reduced.
Security operations and detection needs
Security monitoring tools need specific event types to detect threats, so the logging selection should reflect the detections the team plans to run. Wazuh decodes collected logs against more than 3,000 built-in rules and decoders, and OpenSearch Security Analytics matches ingested logs against Sigma rules. Map each planned detection to the event types it depends on, then add any missing types to the selection.
Legal, customer and regulator requirements
Legal counsel, customers and regulators may each need specific audit data for investigations, contractual reporting or examination. Ask these parties which events and time periods they need before fixing the selection, and record their requirements with the justification AU-2 asks for. Requirements that arrive after the selection is set often force a second review and a change to the documented selection.
How an assessor tests AU-2 with examine, interview and test methods
Examine is the document and record review. For AU-2, the assessor looks at the artifacts that show what the system can log, which event types were selected, why, and how often that selection is reviewed. SP 800-53A names the examine objects for this control as system auditable events and system audit records, so the assessor expects to see both the defined event list and actual records produced from it.
- Event definitions: A written list of the event types the system can generate, tied to the components that produce them.
- Selection record: The approved list of logged event types, with the frequency or conditions for each, and the owner who approved it.
- Rationale: A written explanation of how the selected events support after-the-fact investigations of incidents.
- Sample audit records: Recent log entries that show the selected events are actually being written.
- Review record: Dated evidence that the selection was reviewed at the defined frequency, with any changes.
Before the assessment, check that the event list, the approved selection and the sample records all describe the same system and the same period.
Interview tests whether the people responsible for logging can explain the selection and run it. SP 800-53A lists two interview groups for AU-2: organizational personnel with audit and accountability responsibilities, and system and network administrators. The assessor uses these conversations to confirm that the documents reflect practice and that the people named in them know their roles.
- Audit and accountability owners: They explain how event types were chosen, who approves changes to the selection and how a review is triggered.
- System and network administrators: They describe how logging is enabled on each component, what happens when a new component is added and where the logs are kept.
- Consistency checks: The assessor compares what each person says with the written selection. Disagreements between roles are a common reason for findings.
- Change handling: They explain how a new event type or a removed one gets into the selection, and who is told.
- Investigation use: They describe how logged events have been used in past investigations, if any, and what was missing.
Before interviews, confirm that the named owners are available, have read the selection document and can point to where their evidence is stored.
Test checks that the mechanisms implementing system auditing behave as the documents say. SP 800-53A names mechanisms implementing system auditing as the test object for AU-2. The assessor may trigger or observe selected events and then confirm they appear in the logs with the expected detail. The goal is to show that the selection is enforced by the system, not only described in a document.
- Event triggering: The assessor performs or observes a set of defined actions, such as a login, a permission change or a configuration edit, and checks that each selected event is recorded.
- Negative checks: Events outside the approved selection should not be logged if the selection is meant to exclude them, and the assessor may check that the configuration reflects this.
- Configuration review: Audit settings on each in-scope component are compared against the approved list.
- Coverage across components: The assessor checks that every in-scope component is included, not only the central platform.
- Retrieval: Recorded events must be retrievable for investigation, which connects this test to AU-6 and AU-11.
Before testing, confirm with the platform team which actions are safe to trigger in the assessment environment and where the resulting records can be found.
Most AU-2 findings do not come from missing logging. They come from gaps between the selection, the rationale, the evidence and the review. Assessors raise the same findings repeatedly, and each one is easier to prevent than to fix during an assessment. The list below reflects the points where documents and systems most often diverge.
- Undocumented selection rationale: The event types are logged, but no record explains how they support investigations.
- No periodic review record: The selection is defined, but there is no dated evidence that it was reviewed at the stated frequency.
- Selection and systems disagree: The approved list includes event types that a component does not actually produce, or the component logs types that are not on the list.
- Missing coordination record: Other parties that need audit data, such as a managed service provider or a security operations team, are not documented as consulted.
- Gaps in coverage: New components or services were added without updating the selection.
Before the assessment, ask the owner of each finding area to produce its dated evidence, and confirm the review frequency with the organization's own control definition.
Implementing AU-2 step by step
This sequence turns the AU-2 requirement into a documented, tested and periodically reviewed event logging selection, with each step leaving a record an assessor can examine. Ownership stays with the organization, while an implementation partner can prepare the inventory, configuration and evidence.
Inventory what each component can log
Start by listing every system, application, host, network device and cloud service in scope, and record which event types each one can generate and where those events are written. Name an owner for each component and note the default logging settings. The step is complete when the inventory covers every in-scope component and an owner has confirmed each entry against the vendor documentation or the running configuration. Gaps found here feed directly into the coordination step.
Agree event needs with other parties
Meet with security operations, incident response, legal, compliance and any external party that consumes audit data, such as a managed detection provider or a customer. Record what each party needs to see, how long it needs the data and in what format it needs it. The output is a coordination record signed off by the control owner. This record shows the assessor that AU-2 was built with the parties who depend on the logs, not in isolation.
Select and document the event types and frequency
From the inventory and coordination record, choose the event types to log and state how often each is captured or reviewed. Keep the selection tied to specific systems so it is testable. The output is a selection document that lists each event type, the components that generate it, its logging frequency and its owner. Assessors will compare this document with the inventory, so every selected event should trace back to a component that can produce it.
Write the investigation rationale
For each selected event type, write a short statement explaining how it supports after-the-fact incident investigation: what question it answers, such as who changed an access right or when a privileged session started. Involve incident response staff in drafting these statements. The rationale is complete when every selected event type has a justification that incident responders have reviewed. AU-2 specifically asks the organization to document why the selection supports investigations, so this record is a required output rather than optional commentary.
Configure logging and confirm it works
Apply the selected event settings to each component, using the configuration keys or audit devices each platform documents. Confirm that the events actually appear in the central log store by generating test activity for each event type and checking the resulting records. Store the configuration as a versioned baseline, for example in a configuration repository, so changes are traceable. Configuration files, test results and screenshots become the test evidence an assessor will request. Where a platform's logging behavior is unclear, confirm it with the vendor before relying on it.
Set the review cadence and change triggers
Define how often the event selection is reviewed, using the frequency the organization set in the selection document, and name the people who perform each review. Also list the change triggers that force an earlier review, such as a new system, a significant architecture change, a new regulatory requirement or a recent incident that exposed a logging gap. Each review produces a dated review log that records the decision, any changes made and the approver. This log is what shows AU-2 is maintained over time rather than set once.
How the selection links to AU-3, AU-6 and AU-12
AU-2 decides what gets logged, but the selection only does work when the controls around it carry it through. AU-3 defines what each record must contain, AU-12 is where the system is told to generate records for the AU-2 event types, AU-6 is where people or tools review those records at the frequency the organization set, and AU-11 keeps them long enough to support investigations. If any link is missing, an event type can be approved on paper and still never appear in a record anyone can read. Map each AU-2 event type to the component that produces it, the AU-3 fields that event must carry, the AU-6 review that will look at it and the AU-11 retention period that applies.
When the AU-2 selection changes, the change should flow in one direction: the selection record is updated first, then the configuration of each affected component, then the review procedure. For example, adding privileged database queries to the list means changing the audit settings on the database service, confirming the records include the AU-3 fields, and adding those records to the AU-6 review scope. Keep a change log that ties each configuration change to the AU-2 decision it implements. Confirm with your assessor which evidence they expect for this trail, since the mapping of change records to AU-2 is an organizational choice rather than something the control text prescribes.
Test the chain end to end before relying on it. Pick one event type from the selection, trigger it in a non-production environment, and follow the record through generation, field content, arrival in the central store, review queue and retention. Several self-hosted tools can supply parts of this chain. Nextcloud writes the admin_audit app's extra event detail to audit.log, OpenBao audit devices keep detailed JSON records of API requests, and Wazuh and OpenSearch Security Analytics can apply rules to ingested logs for review. Confirm each tool's current field set and retention behavior in its own documentation before writing it into your AU-3 or AU-11 evidence, because the fields a product emits may differ from the fields your selection requires.
Evidence that satisfies AU-2 and how to keep it current
AU-2 is tested by reading documents and checking live configuration, so the evidence has to agree with what the system actually logs. The five artifacts below each answer one question an assessor asks, and each needs a named owner and a refresh trigger between assessments.
Auditable event list per system
This is the inventory of event types each system can log, such as account logons, privilege changes, configuration edits, data exports and failed authorization checks. It is the starting point for AU-2 because the assessor compares the selected events against what the system is capable of recording. Keep it per system rather than per platform, since the same product can be deployed with different modules enabled. Refresh it whenever a plugin, module or upgrade adds or removes event sources, and confirm each entry against the product's own logging documentation.
Coordination record with other parties
AU-2 asks the organization to coordinate event logging with other entities that need audit information, such as a security operations provider, a regulator, a cloud host or a parent organization. The record names each party, the event types they need, the format and delivery method, and who approved the arrangement. Check that every party named in incident response plans appears here, and that data sharing agreements match the events actually forwarded. Review it when a new monitoring provider or reporting obligation appears.
Signed selection and investigation rationale
This document records which event types are logged, how often, and why that subset supports after-the-fact investigation. Assessors look for a link between each selected event and a realistic investigative question, such as who changed an access policy and when. Have the accountable system owner and the security lead sign it, and state any events deliberately excluded along with the reason. Revisit the rationale after significant incidents, since a missed event type often reveals a gap in the selection.
Periodic review record with dates and approvers
AU-2 requires the event selection to be reviewed at a defined frequency. The review record lists each review date, the people who attended, the systems covered, the changes approved and the reason for any change. The frequency itself should be stated in the system security plan so the assessor can compare actual review dates with the commitment. Missing or late entries are among the most common findings in this area, so set a calendar reminder tied to the defined frequency and link each review to a ticket.
Configuration exports showing the selection is in effect
Documents describe intent, but assessors also test whether the selection is active. Export the logging configuration from each system, such as the audit log settings in Nextcloud or the enabled audit devices in OpenBao, and store the exports with dates and the hash of the configuration file. Compare them with the signed selection during each review, because drift often happens after upgrades or emergency changes. Include the path where logs are written so the assessor can trace a sample event from the configuration to the stored record.
What meeting AU-2 costs in money and effort
This table breaks AU-2 cost into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since no price is set by NIST and the self-hosted tools carry no license fee.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling and licenses | No license fee for the self-hosted tools named here, but confirm each component's license terms with its publisher | Not applicable for open-source software | Choice of commercial add-ons, support subscriptions or managed services |
| Infrastructure and log storage | Your cloud provider or data center operator | Recurring | Event volume, number of components in scope, and the retention period set under AU-11 |
| Inventory of auditable events | Implementation partner or internal engineers | One-time, then periodic | Number of systems, custom applications and third-party components to catalog |
| Logging configuration engineering | Implementation partner or internal engineers | One-time, with changes over time | Number of log sources, need for custom log formats and integration with the central log platform |
| Justification and documentation | Internal compliance or security staff, with optional partner help | One-time, then updated at each review | How many event types are selected, and how well the rationale is tied to investigation use cases |
| Periodic review of the event selection | Internal security staff or retained partner | Recurring | Review frequency set by your organization, and how often system or threat changes trigger an extra review |
| Independent assessment support | Independent assessor, auditor or certification body | Recurring at each assessment cycle | Assessment scope, sampling by the assessor, and how well evidence is organized beforehand |
| Ongoing support or retainer | Implementation partner, if contracted | Recurring | Whether upgrades, log source changes and testing are included in scope |
Who does what for AU-2: your team, a partner and the auditor
AU-2 is a control your organization owns. The event types the system logs, the reasons those types support after-the-fact investigations and the frequency of review are management decisions, and no partner or auditor can make them on your behalf. Your security and compliance leads should decide what is in scope, which parties need audit data, and how the selection will be justified to investigators and regulators.
- Selection decisions: Approve the event types to be logged and the frequency at which each is captured, based on the system's risk and its investigation needs.
- Justification: Write down why the selected events support incident investigations, so an assessor can trace the reasoning back to your risk assessment.
- Coordination: Name the internal and external parties, such as a security operations provider or a regulator, that need audit information and agree what they receive.
- Periodic review: Set the review cycle and record each review, including changes made when threats or system functions change.
- Accountability: Assign a named owner for the AU-2 decisions and keep the approval records.
Before engaging anyone, confirm that your own owner can explain every logged event type and its investigative purpose.
An implementation partner such as DeployOpen prepares the technical side of AU-2 inside your own infrastructure. The partner can inventory log sources, configure the logging capability that produces the selected events, test that the mechanisms work and draft the evidence that shows it. The partner does not decide which events matter, and it does not issue audit reports or certifications.
- Source inventory: Identify the components that can generate events and document what each one can log.
- Configuration: Set up logging in self-hosted platforms, for example enabling the
admin_auditapp in Nextcloud and configuring audit devices in OpenBao, so the approved event types are captured. - Detection tooling: Where your organization requires it, connect sources to a self-hosted tool such as Wazuh or OpenSearch Security Analytics and document the rules applied.
- Testing: Generate test events and confirm they appear in the expected logs, keeping the results as evidence.
- Evidence drafting: Prepare configuration records, test results and a change history for your owner to review.
DeployOpen prepares systems and evidence for assessment. It does not issue audit reports, attestations or certifications. Independence rules limit what an assessor can accept from the party that configured the system, so the partner's documents support your owner's statements rather than replace them.
The independent assessor examines, interviews and tests the AU-2 implementation against the assessment procedures in SP 800-53A, then reports the findings. The assessor's role is to judge the evidence, not to build the logging setup. Independence means the assessor should not have designed or configured the controls it is assessing, because a finding that depends on its own work is not independent.
- Examine: Review the system's auditable events, the selection record and the policies behind them against the determination statements.
- Interview: Speak with the personnel responsible for audit and accountability and with system and network administrators to confirm how logging works in practice.
- Test: Check that the mechanisms implementing system auditing produce the selected events as documented.
- Report: Issue the assessment report with findings, which your organization then uses in its authorization or compliance decisions.
- Independence check: Confirm with the assessor, before work begins, which parts of the configuration it may rely on and which it must test independently.
Ask the assessor how it handles configuration done by an implementation partner, and agree the evidence it needs before the engagement starts.
Where AU-2 implementations usually fall short
AU-2 looks simple on paper: name the event types, pick a subset, and review it. Most assessment findings come from the gaps between those steps, where the list drifts from what components actually record and nobody can explain why an event was selected. The cards below cover the failure points an assessor is most likely to probe.
Selection without an investigation rationale
AU-2 expects the organization to document why the chosen event types support after-the-fact incident investigations. Many programs list events but never write down the investigative question each one answers, such as who changed an access role or when a privileged session started. Check that every selected event type has a short rationale tied to a named investigation scenario, and that the rationale is signed off by the people who run incident response.
Event lists that differ from actual logs
The selected event list must match what each component can and does record. A common gap is a written list that names events a reverse proxy, database or identity provider never emits, or leaves out events that are enabled only on some hosts. Pull a sample of audit output from each in-scope component and compare it line by line with the documented list. Treat any event with no matching log line as a finding to fix or formally accept.
No coordination with other log consumers
AU-2 requires coordinating event logging with the other entities that need audit information, which usually means the security operations center, the forensics team, legal and sometimes an external provider. When those parties were not consulted, the selection can omit events they depend on, or log events nobody reviews. Confirm in writing which teams consume audit data, what each needs, and who approved the final event subset.
Reviews that happen without a record
AU-2 asks for the selection to be reviewed at a defined frequency. Teams often revisit the list informally after an incident, but leave no minutes, version history or sign-off. An assessor will ask for the last review, what changed and who approved it. Set a review frequency in the logging procedure, store each review as a dated record, and keep the prior version so changes can be traced.
Selections frozen after system changes
A logging selection written for one architecture can quietly stop fitting after a migration, a new integration, a container rollout or a software upgrade. New components may run with default logging, while removed ones leave gaps in the record. Tie the AU-2 review to change management so that every significant change to a system triggers a check of its event types, and confirm that the upgrade path for the logging tool itself does not reset its settings.
Questions buyers ask about AU-2 cost, effort and scope
How much effort does AU-2 take for a single system?
The effort depends on how many components the system has, how many event types it can already log, and how much of the selection has already been documented. AU-2 itself is a selection and justification control, so the work is mostly analysis and documentation, but that analysis touches every component that produces logs. Expect effort to rise with the number of applications, hosts, cloud services and identity sources in the boundary, and with the number of parties that need audit data. Ask for the effort to be broken down by component in the written scope so you can see where the hours go.
Can we do AU-2 in-house with open-source logging tools?
Yes, an internal team can do the work with open-source tools, because AU-2 asks you to decide and justify what is logged rather than to buy a specific product. Tools such as the Nextcloud admin_audit app, OpenBao audit devices, and the Wazuh and OpenSearch Security Analytics pipelines can show what each component records, which helps the inventory step. The harder parts are the judgment calls: which events support investigations, who needs the data, and how often the selection is reviewed. Confirm with each tool's documentation which event types it can emit in your version, because capabilities differ between releases.
What does AU-2 need from our internal team?
AU-2 needs people who know the system well enough to name its event types and people who can speak for the investigations the logs must support. In practice that means:
- System owners and administrators who can list what each component can log.
- Security operations staff who describe the incidents they investigate and the evidence they need.
- Anyone who receives audit data from outside the organization, so the coordination step is complete.
- An approver who accepts the selection and its review frequency.
Without these inputs, the documented selection will be generic and difficult to defend in an assessment.
How long does AU-2 take to complete?
The duration depends on scope, meaning the number of systems, components and external parties covered, and on how much logging documentation already exists. No researched duration is available for this control, so do not accept a generic timeline. Ask the partner to state the expected duration in the written, fixed-scope agreement, with the systems included, the dependencies on your team's availability, and the points where your review is required before work continues.
Is AU-2 alone enough to pass an audit?
No. AU-2 is one control in a larger set, and an assessor will test it alongside the controls that depend on it. AU-2 is related to AU-3 (record content), AU-6 (review and analysis), AU-11 (retention) and AU-12 (generation of records), among others. An assessor testing AU-2 will expect the selection to match what those controls actually produce. Also confirm which baseline your system falls under, because SP 800-53B selects AU-2 for the low, moderate and high baselines and the privacy baseline, and the surrounding controls change with the baseline.
What should we ask a partner for in a fixed-scope AU-2 quote?
Ask for a written scope that lists the systems, components and event sources covered, the deliverables, and the assumptions behind the estimate. Useful items include:
- The inventory of loggable event types for each component.
- The documented selection, with the justification for each event type.
- The list of parties receiving audit data and how the coordination was recorded.
- The review procedure and the frequency the organization must approve.
- What the partner needs from your team, and what is out of scope.
DeployOpen prepares systems, controls and evidence for assessment, but only an independent auditor or assessor issues reports or certificates, so confirm that point in the agreement too.
What drives the cost of AU-2 work up or down?
Cost is driven by the number of systems and components in scope, how many of them are custom or undocumented, and how many external parties need audit data. Costs are one-time for the initial selection and justification, and recurring for periodic reviews and for changes when systems or threats change. Work goes faster when logging configurations are already documented, when the system boundary is stable, and when investigation requirements are written down. Ask any provider to separate one-time setup from recurring review in the quote so you can budget both.
Which parts of AU-2 are usually outsourced?
Organizations most often outsource the initial inventory of loggable events, the mapping of those events to investigation needs, and the drafting of the documented selection. They usually keep ownership of the decisions, the approval of the selection, and the coordination with external parties that receive audit data. Implementation partners can also configure self-hosted logging tools to produce the chosen event types, but the organization must confirm that the tools produce what was selected. Assessment of the control is done by an independent auditor, not by the implementation partner.
How DeployOpen scopes and prepares AU-2 evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the AU-2 event selection is written down, configured and evidenced where the system actually runs. The organization keeps ownership of its control decisions, while DeployOpen prepares the systems and records that an independent assessor can examine.
How we scope
- We inventory the platforms in the agreed boundary and list the event types each one can log.
- We identify which internal teams and external parties need audit data, and record what each one requires.
- Engagements are fixed-scope, so the written scope states which AU-2 event types and platforms are covered.
How we build
- We configure audit logging on the in-scope platforms to match the event selection the organization approves.
- We connect the logs to the organization's chosen log analysis tooling, such as Wazuh or OpenSearch, where the scope includes it.
- We test that the configured events are generated and recorded, and we record the results for review.
How we hand over
- We document the approved event selection, the rationale for each event type and the review frequency the organization set.
- We provide configuration exports and test records that an assessor can examine against the AU-2 assessment procedures.
- We confirm with the organization's owners which artifacts they will retain and where they are stored.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- When platforms are upgraded or new event types are needed, we update the configuration and the documented selection together.
- Assessment outcomes come from the independent auditor or assessor, and DeployOpen does not issue audit reports or attestations.
