RMFInsider

AU-2 decides which events your system logs and why. AU-12 makes the system actually generate those records, on the components you named, with the content AU-3 requires. DoD assessors test them as a pair, in that order, and a weak AU-2 makes AU-12 untestable rather than merely weak. AU-2 is the paperwork half: identify the event types the system can log, coordinate the selection with the people who need the data, specify the subset you will really log and how often, write down the rationale for why that subset supports after-the-fact investigation, and review the list on a stated frequency. AU-12 is the proof half: the generation capability exists on the named components, the right roles can select event types, and records come out carrying the required content. Fail the first and the second has nothing to be measured against.

AU-2 Event Logging, Requirement by Requirement

1. Identify the event types the system is capable of logging in support of the audit function.
2. Coordinate the logging function with the other organizational entities that need audit information, so their requirements shape what gets selected.
3. Specify the event types actually logged on the system, as a subset of what the system can log, along with the frequency of or the situation requiring logging for each one.
4. Provide a rationale for why the selected event types are adequate to support after-the-fact investigation of incidents.
5. Review and update the selected event types on a stated frequency.

Requirement d is the one that gets skipped. Teams list event types and stop, because listing feels like the deliverable. Revision 5 wants a written argument connecting the list to incident investigation, and an assessor who cannot find that argument writes the control up even when the logging itself is fine. Two paragraphs tying your event selection to the attack paths in your risk assessment will close it. For how this fits into the wider control structure, NIST 800-53 controls explained covers the family layout.

AU-12 Audit Record Generation

AU-12 is short and entirely testable. Three requirements:

1. Provide audit record generation capability for the event types from AU-2 on the system components you specifically name.
2. Allow named personnel or roles to select which event types are logged by specific components.
3. Generate audit records for the selected event types, containing the audit record content AU-3 requires.

AU-3 is where the content requirement lives, and it is the piece people forget until a validator opens a raw log. Each record needs what type of event occurred, when it occurred, where it occurred, the source, the outcome, and the identity of the individual or subject associated with the event. A log line with a timestamp and a message and no user identity satisfies nothing. The enhancements to watch are AU-12(1) for a system-wide, time-correlated audit trail, AU-12(2) for standardized formats, and AU-12(3) for restricting who can change what gets logged.

What DoD Systems Actually Have to Log

The control text is generic on purpose. The DISA Security Requirements Guides and the operating system STIGs are where the generic turns into specific audit rules, and the STIG is what gets scanned. At a minimum, expect to log and be able to produce:

• Logon and logoff events, successful and failed, including the source address and the account used.
• Account lifecycle events: creation, modification, enabling, disabling and removal. This is the same evidence AC-2(4) demands, so the two control write-ups have to tell the same story.
• Privilege use and privilege escalation, including sudo on Linux hosts and special privilege assignment on Windows.
• Changes to the audit configuration itself, plus any attempt to stop, start or clear the audit service. An attacker who can silently turn off logging makes every other audit control decorative.
• Object access to security-relevant files and directories, scoped to what you can actually review rather than everything on the volume.
• Policy changes, group membership changes and trust relationship changes.
• Application and service start, stop and failure events on the components in the boundary.

Where the STIG turns generic into specific

On Windows that means the advanced audit policy configuration the STIG specifies, not the legacy audit categories. On Red Hat it means the auditd rule set from the STIG, loaded and persistent across reboot. If your scan results and your AU-2 event list disagree, the scan wins in the eyes of the assessor. The STIG checklist for ISSOs walks through getting those two artifacts to agree before anybody else looks at them.

The 2026 Change You Cannot Skip Past

OMB issued memorandum M-26-14 in May 2026, and it rescinded M-21-31 outright. If your continuous monitoring plan still cites the EL0 through EL3 event logging maturity tiers, it is citing a rescinded document. What replaced it:

• A five level maturity model running from Ineffective at the bottom to Optimal at the top, rather than the four EL tiers.
• Five assessed elements: inventory visibility, collection coverage, collection operations, data retention, and log management.
• Two named outcomes the whole thing serves: continuous event monitoring, and threat hunting, investigation, response and forensics.
• Retention restated around usability rather than volume. Logs must be searchable for at least six months and retrievable for at least twelve, which is a shorter and more demanding bar than the old twelve months hot and eighteen months cold framing, because searchable is a higher standard than stored.

Searchable is a higher bar than stored

That last shift is the one that changes an ISSO’s day. A log that exists on a host and cannot be retrieved by anybody except the one system administrator who still has the root password is, for assessment purposes, a rumor. Component policy may set a longer retention number than the federal floor, so check your own before you write a figure into the plan. The mechanics of keeping this current between assessments live in the ISSO continuous monitoring plan.

What Assessors Ask to See

The AU-2 and AU-12 evidence request tends to arrive in this order, and each item builds on the one before it:

1. The event type list itself, as a controlled document with a version and a review date, showing what the system can log and what you selected.
2. The rationale paragraph for the selection. Requirement d, in writing.
3. The audit configuration export from a representative host of each type in the boundary, proving the selected events are actually enabled.
4. A raw log sample, unedited, so the validator can check AU-3 content fields against real records rather than a screenshot of a dashboard.
5. Evidence of time synchronization across the components, because AU-12(1) wants a correlated trail and correlation fails silently when clocks drift.
6. The audit review records from AU-6, showing somebody looked at the logs and acted on something. This is the request that catches people.
7. The retention and protection evidence for AU-9 and AU-11: where the logs go, who can delete them, and how long they stay searchable.

The Four Ways This Pair Fails

• The event list and the STIG results disagree. The document says you log privilege escalation, the auditd rule set says otherwise, and the scan result is in the package already.
• No rationale. The list exists, the argument for it does not, and requirement d is written up as other than satisfied even though the logging is adequate.
• AU-6 has no teeth. Logs are generated and retained and nobody reviews them, so the audit review artifact is a monthly email saying no anomalies were noted, with no evidence anybody opened anything. Assessors read that email for what it is.
• Coverage gaps at the edges. Network devices, the virtualization layer, the database and the application tier each get missed in turn, because AU-12 requires generation on the components you named and somebody named only the servers.

When one of these turns into a finding, the corrective action is usually quick and the documentation is what actually takes time. Write the POA&M milestone against the artifact rather than the configuration change, because the configuration change is a one afternoon job and getting the plan, the event list and the review record back into agreement is not. If the finding touches incident detection, expect the assessor to pull your incident response plan next and check whether the reporting timelines in it are supportable with the logs you actually keep.

AU-2 and AU-12 are cheap controls to satisfy and expensive controls to fail, because failing them casts doubt on your ability to reconstruct anything after an incident, which is the one question an authorizing official cannot wave through. Get the event list, the rationale and the raw log sample into the package as a set, refresh them whenever the STIG baseline moves, and the assessment conversation stays short. When findings do land, track the milestones somewhere that survives contact with a schedule slip: the POA&M Tracker is built for exactly that cycle.