Audit Record Generation AU-12

Audit and Accountability · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds AU-12 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, Audit and Accountability family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

AU-12 (Audit Record Generation) is about the system actually producing audit records — for the event types AU-2 says to log, on the components that matter, with the content AU-3 requires — and letting the right roles choose what gets logged. It is where AU-2 (what to log) and AU-3 (what each record contains) become real, running output. It is a foundational Audit and Accountability control in the Low baseline.

What good looks like

Make sure every component that should log is actually generating records — the host, its services, and the audit daemon — not just one of them.
Cover the event types AU-2 calls for (logins, privilege use, account changes, and the like) so nothing important goes unrecorded.
Include the content AU-3 requires in each record: who did it, what happened, when, where, and the outcome.
Let only the right roles change what is logged, so logging cannot be quietly turned off.
Send records somewhere they can be read and monitored, not written to a file no one ever looks at.

Framework mapping

NIST CSF 2.0 — PR.PS-04 — Log records are generated and made available for continuous monitoring
CIS Controls v8 — Control 8 — Audit Log Management

How to move it toward Implemented

Confirm the audit daemon is running and generating records: systemctl enable --now auditd, then check with auditctl -s (status) and auditctl -l (active rules).
Turn AU-2’s event list into real rules under /etc/audit/rules.d/ — watch account files and auth logs (-w /etc/passwd -p wa, -w /var/log/auth.log -p wa) and privileged commands — then load them with augenrules --load.
Make sure journald and rsyslog are capturing service logs (systemctl status systemd-journald rsyslog) so component coverage is complete, and lock down who can change the rules (root-only /etc/audit/, and immutable mode -e 2 once the ruleset is settled).
Attach the audit ruleset plus a sample generated record (for example, ausearch or journalctl output showing a login event with its AU-3 fields) as hardening evidence on the asset, naming AU-12 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.