Most teams log a lot. AU-2 asks a harder question: did you choose what to log on purpose, and can you explain why the choice is enough to investigate an incident?
NIST SP 800-53 Rev 5 binds US federal systems, and others through contract. For other organizations it is a reference, and a handy one when a customer sends a logging questionnaire.
What the control asks
AU-2 has five parts. Identify the types of events the system is capable of logging in support of the audit function. Coordinate event logging with other organizational entities that need audit information, so the selection reflects their needs. Specify the event types you will actually log. Give a rationale for why those event types are adequate to support after-the-fact investigations. Review and update the selection at a frequency you define.
The rationale is the part teams skip. NIST wants a reason, not only a list.
What it means in practice
NIST's guidance defines an event as an observable occurrence in a system. The ones that matter are significant to the security of systems and the privacy of individuals. Its examples include password changes, failed logons or failed accesses, security or privacy attribute changes, administrative privilege usage, data action changes, query parameters and external credential usage.
For a typical software company, a workable event set looks like this:
- Sign in, sign out and failed authentication.
- Password and multi-factor changes.
- Role and permission changes.
- Use of administrator or root rights.
- Access to sensitive data and exports.
- Changes to logging configuration itself.
- Production deployments and infrastructure changes.
- Creation and use of API keys and service credentials.
Then write a sentence or two on why. For example, "These events let us reconstruct who accessed customer data, with which privilege, and what changed afterward."
Evidence to collect
- A documented event list by system or component.
- The written rationale for adequacy.
- Records of who else you consulted, such as legal, security operations or a customer success team.
- A review log showing the list was revisited on your schedule.
- Sample log entries that prove each listed event type is really produced.
- Configuration screenshots or exports from log settings in cloud accounts and applications.
Common gaps
- The event list exists only as default settings nobody decided on.
- No rationale.
- A system was added and never entered in the list.
- Event types are listed but not produced, because logging was never switched on.
- Reviews happen after incidents instead of on a calendar.
How to implement it
Inventory your systems first. For each one, list what it can log, then pick what you will log. Take the list to the people who use logs: security, engineering, legal and support. Record the rationale. Verify by triggering each event and finding it in your log store.
The enhancements give options. AU-2.1 Compilation of Audit Records from Multiple Sources and AU-2.2 Selection of Audit Events by Component appear in the record. AU-2.3 Reviews and Updates and AU-2.4 Privileged Functions are also listed. For small teams, the privileged functions idea is a good first addition: make sure every use of admin power is logged.
Review the list yearly and whenever you add a system or handle a new kind of data. Keep the review note even when nothing changes.
Quick check
We log everything by default. Do we meet AU-2?
Not automatically. AU-2 asks you to specify event types and justify why they are adequate. Logging everything can still satisfy the intent, but write down the decision, the rationale and the review.
What is the quickest way to prove an event type is really logged?
Trigger it in a test account, then search for it in the log store and keep the result with the date.
