AU-2: Event Logging

What this control requires

AU-02 requires organizations to identify, select, and maintain the specific event types their systems must log to support security monitoring and incident investigation. You don’t just turn on logging and walk away. You define which events matter, justify why those events are sufficient, coordinate with stakeholders who depend on audit data, and revisit your selections on a regular schedule.

In practice, this means building a deliberate inventory of loggable events, from failed authentication attempts and privilege escalations to configuration changes and data access patterns. The control forces you to think about coverage before an incident occurs, not after. Most organizations can technically log far more than they actually capture, and the gap between capability and configuration is where investigations fail.

The requirement also addresses a tension that practitioners deal with constantly. Logging everything degrades system performance, and logging too little leaves blind spots that attackers exploit. AU-02 exists to make that tradeoff an explicit, documented, reviewable decision rather than something that happens by default.

Why it matters

The most common AU-02 failure is a logging configuration that was never designed to catch the access patterns that actually precede a breach. When organizations skip the deliberate event selection process this control requires, they end up with systems that log noise while missing the signals that matter.

Florida Hospital Celebration insider theft

Between 2009 and July 2011, a registration clerk at Florida Hospital Celebration accessed records on approximately 760,000 patients across multiple locations within a 22-facility health system. Dale Munroe II sold patient data for motor vehicle accident victims to a co-conspirator running chiropractic clinics, who used the information to solicit patients.

Munroe was terminated in July 2011, but his wife Katrina, also a hospital employee, continued the scheme independently until she was fired in August 2012. The activity went undetected for roughly two years and was discovered through external notification, not internal monitoring.

The AU-02 failure here is the two-year detection gap. A registration clerk accessing hundreds of thousands of records, including records from facilities other than their own, represents an access pattern that basic user activity monitoring should flag.

Security expert Stephen Wu noted publicly that if a user went from accessing a database 30 times a day to thousands of times a day, that’s something that needs review. A software program can set off an alert of unusual activity, but it needs to be followed up.

Florida Hospital had neither the event definitions nor the monitoring infrastructure to detect a registration worker querying records at scale across a multi-site system. Munroe was sentenced to 12 months and one day in federal prison. The case became a reference point for Office for Civil Rights guidance on audit controls in healthcare.

What attackers exploit

• Absent event definitions for data access patterns. Without logged access events, abnormal query volumes go unnoticed for months or years.
• No cross-site correlation of user activity. Logging at individual system boundaries without aggregating across locations lets insiders move laterally without triggering alerts.
• Static logging configurations that are never reviewed. Event types selected during initial deployment become stale as roles, systems, and threats evolve.
• Failure to log privilege usage and role changes. Attackers and insiders escalate access incrementally, and unlogged privilege events make that escalation invisible.
• Logging gaps in authentication events. Failed logons, credential reuse, and off-hours access provide early warning signals that most organizations aren’t capturing.

How to implement

The most common implementation failure for AU-02 is organizational, not technical. Teams deploy a security information and event management (SIEM) platform or log management platform and assume event logging is handled, without ever defining which event types actually need to be captured or why.

For your organization

Step 1: Inventory loggable event types Start by cataloging every event type your systems are capable of logging. This includes authentication events (successful and failed logons, logoffs), privilege usage (administrative access, role escalation), object access (file creation, modification, deletion), security attribute changes, configuration modifications, and account management actions (creation, disabling, removal). Map these against the systems in your environment, including operating systems, databases, applications, network devices, and cloud services.

Step 2: Select and justify your logging subset Not every loggable event needs to be logged continuously. Work with your security operations, privacy, and compliance teams to select the subset that supports incident investigation and meets regulatory requirements. Document the rationale for each inclusion and exclusion, referencing specific risk scenarios rather than generic compliance language.

Step 3: Coordinate across stakeholders AU-02 explicitly requires coordination with other organizational entities that need audit data. This includes your incident response team, privacy office, legal counsel, and any third-party assessors. Each group may have different event type requirements, and your logging configuration needs to account for all of them.

Step 4: Implement and validate Configure logging at the system level to capture your selected event types at the specified frequencies. Validate that events are actually being generated and collected by reviewing sample audit records. Use log management or SIEM tools to aggregate, normalize, and store records centrally.

Step 5: Establish a review cycle Schedule periodic reviews of your event type selections. Trigger ad-hoc reviews when you add new systems, change architectures, or respond to incidents that reveal logging gaps. Document each review and any changes made.

Common mistakes:

• Logging only authentication events while ignoring data access and privilege escalation
• Failing to test whether configured log sources are actually producing records
• Treating the initial event type selection as permanent rather than a living document
• Overlooking privacy implications of logging patterns that reveal personally identifiable information

For your vendors

What to ask in a security questionnaire

• Which event types does your system log by default, and which require additional configuration?
• How do you determine which events to log, and how often do you review those selections?
• Can you provide documentation of your event logging rationale?
• How do you coordinate logging requirements across internal teams and with your customers?
• What is the retention period for audit logs, and how are they protected from tampering?

Evidence to request

• The vendor’s audit and accountability policy with event type definitions
• System configuration documentation showing which event types are enabled
• Records of the most recent event type review, including any changes made
• Sample audit logs demonstrating that the defined event types are being captured

Red flags

• The vendor can’t articulate which events they log or why
• Event type selections haven’t been reviewed or updated in over a year
• Logging is limited to system-level events with no application-layer coverage
• No documented rationale for why the selected events are sufficient for incident investigation
• Audit logs are stored on the same systems they monitor, with no integrity protections

Verification beyond self-attestation Request sample audit records and compare them against the vendor’s documented event type list. Ask for evidence of their most recent review cycle. If possible, test specific scenarios (for example, a failed login attempt) and verify the event appears in their logs.

Evidence examples

Cross-framework mapping

Related controls

• AC-02, Account Management: Account lifecycle events (creation, modification, disabling, removal) are among the most critical event types AU-02 requires you to define and log.
• AC-03, Access Enforcement: Access enforcement decisions generate the authorization events that AU-02’s logging captures, connecting policy enforcement to audit visibility.
• AC-06, Least Privilege: Privilege escalation and administrative access events are key AU-02 logging targets that depend on least privilege being properly scoped.
• AC-07, Unsuccessful Logon Attempts: Failed authentication is one of the most universally required AU-02 event types, feeding directly into lockout and alerting mechanisms.
• AC-08, System Use Notification: System use banners create a legal and procedural foundation for the monitoring activity that AU-02 event logging supports.
• AC-16, Security and Privacy Attributes: Changes to security and privacy attributes are explicitly named in NIST guidance as event types AU-02 should capture.
• AC-17, Remote Access: Remote access sessions generate authentication and session events that AU-02 must include in its logging scope.
• AU-03, Content of Audit Records: While AU-02 defines which events to log, AU-03 specifies what information each audit record must contain.
• AU-04, Audit Log Storage Capacity: The volume of events selected under AU-02 directly determines the storage capacity requirements addressed by AU-04.
• AU-05, Response to Audit Logging Process Failures: When the logging defined by AU-02 fails, AU-05 governs how the organization detects and responds to that failure.

Frequently asked questions

What is NIST SP 800-53 AU-02

AU-02 requires organizations to identify the event types their systems can log, select a justified subset for active logging, coordinate those selections with stakeholders, and review them periodically. The control forces every audit and accountability program to answer a foundational question: which system events are you actually watching, and why?

Your event type selections must include categories like failed authentication attempts, privilege usage, security attribute changes, and data access patterns. Without AU-02, organizations log whatever vendor defaults provide, which rarely aligns with what incident investigators actually need.

What happens if AU-02 is not implemented

Without AU-02, you lose the ability to detect anomalous behavior, investigate incidents after the fact, or demonstrate compliance to auditors. As the Florida Hospital case shows, a registration clerk accessed approximately 760,000 patient records over two years without detection because the organization hadn’t defined event logging requirements that would flag abnormal access volumes.

Auditors assessing your program will look for a documented event type inventory, a written rationale for your logging selections, and evidence that those selections are reviewed on a defined schedule. Missing any of these creates findings that can block certification or trigger regulatory action.

How do you audit AU-02

Auditors verify AU-02 by examining your audit and accountability policy, reviewing the documented list of event types your systems are capable of logging, and comparing that list against the subset you’ve selected for active capture. They check that your event selection rationale explains why the chosen types support incident investigation.

They also look for evidence of stakeholder coordination, typically meeting records or cross-functional sign-offs, and records of periodic reviews showing when event types were last evaluated and updated. Finally, auditors pull sample system audit records to confirm that the specified event types are actually being logged at the documented frequency.

What events should be logged for AU-02 compliance

At minimum, you should log authentication events (successful and failed logons), privilege usage (administrative access, role escalation), account management actions (user creation, modification, disabling), security attribute changes, configuration modifications, and data access events on security-relevant objects. NIST guidance also names personal identity verification credential usage, external credential usage, query parameters, and data action changes as event types to consider. The specific subset you activate depends on your risk assessment, system capabilities, and the coordination process AU-02 requires with privacy, security operations, and compliance stakeholders.