Audit & accountability.

01What this family protects

Audit & Accountability protects an organization’s ability to reconstruct what happened on a system after the fact — who did what, when, and whether it was authorized. It doesn’t stop any specific attack by itself; its value shows up later, when an account behaves oddly or an assessor asks how the organization would know if something had gone wrong. A shop that gets AU right doesn’t necessarily detect an incident faster. It has answers when someone asks.

02The rule says

All 9 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.3 has the full text and discussion for each; Source Library covers when to open it.

03In practice

For a small IT team, AU comes down to picking a manageable set of events to log, making sure the system that stores them doesn’t quietly stop working, and reviewing what’s captured on some real cadence — not necessarily daily, but often enough that a gap doesn’t go unnoticed for months.

What gets logged, and why it’s traceable (3.3.1–3.3.2). A defined list of event types — failed logons, privileged-account use, file access on systems that hold CUI — logged with enough detail (timestamp, user or process identity, what happened, success or failure) to trace an action back to a specific account. The point isn’t logging everything; it’s logging what the organization would actually need if it had to answer a question about what an account did.

Keeping the set current (3.3.3). What gets logged changes as systems change. A list built two systems ago drifts out of relevance; 3.3.3 asks that the list get revisited periodically, not written once and forgotten.

Failures and time (3.3.4, 3.3.7). Two easy-to-miss requirements: an alert when logging itself stops working (a full disk, a crashed service — the kind of failure that leaves a silent gap exactly when something might be happening), and clocks across systems synchronized to a common time source, so records from different machines actually line up when reconstructing a sequence of events.

Review and correlation (3.3.5–3.3.6). Logs that nobody looks at are not evidence of anything. 3.3.5 asks that review, analysis, and reporting work together rather than as separate, disconnected steps; 3.3.6 asks for a way to reduce and summarize records so a person can actually work with them — a raw firewall log with a million lines a week does not meet this requirement by existing.

Protecting the logs themselves (3.3.8–3.3.9). Audit records and the tools that manage them get protected from unauthorized access, edits, or deletion — and only a defined subset of privileged users can manage the logging function itself, so the people whose actions are being recorded aren’t also the people who control whether those records survive.

04Where it fails

Usually the gap is a logging system that technically runs but nobody watches — turned on during a network upgrade, checked once, then left alone. Review (3.3.5) and update (3.3.3) are the two requirements most likely to lapse quietly, because a system that isn’t alerting looks identical to a system that’s fine.

A close second is retention that doesn’t match the need: logs rotate out after a week or two because storage was sized for convenience, not for how long an investigation might need to look back. By the time anyone asks what happened last month, the answer no longer exists.

Time sync (3.3.7) is easy to skip because it fails silently — every system logs fine on its own, and the gap only shows up when someone tries to line up events across machines during an actual investigation.

05What evidence may look like

Normal output, not a special audit product: a written list of the event types the organization logs and why; SIEM or log-management configuration showing retention settings and alerting rules for logging failures; a record of a periodic log review — even a short recurring calendar item with notes — showing someone actually looked; NTP configuration showing systems synchronized to a common time source; and access controls or a group membership list showing who can manage the logging function.

06At the shop

07Commonly confused with

System & Information Integrity (SI). AU decides what gets recorded and kept; SI’s monitoring requirements (3.14.6–3.14.7) decide what an organization actively watches for and acts on in something closer to real time. AU is the record; SI is part of what uses it. See System & Information Integrity.

Incident Response (IR). AU’s records are frequently what an incident-response process draws on during investigation; AU doesn’t investigate anything on its own. See Incident Response.

08Cross-desk links

None load-bearing for this family. See Incident Response and System & Information Integrity for how AU’s records get used elsewhere in the program.

09Sources