AU-2 Event logging
What the standard requires
a. Identify the types of events that the system is capable of logging in support of the audit function: [event types]; b. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged; c. Specify the following event types for logging within the system: [organization-defined event types (subset of the event types defined in [AU-2a.](#au-2_smt.a)) along with the frequency of (or situation requiring) logging for each identified event type]; d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and e. Review and update the event types selected for logging [frequency].
Quoted verbatim from NIST SP 800-53 Rev 5 (OSCAL catalog), which is in the public domain.
Maps to 3 controls in 3 other frameworks
Mappings are CMDash’s own, seeded with the product and shown on both frameworks they connect. In the product they mean evidence you attach here also counts against the controls listed above.
Integrations that carry evidence for this family
These connectors produce data relevant to FedRAMP Moderate’s Audit & Accountability family, which is the granularity CMDash publishes — there is no pre-built per-control mapping, and claiming one would be inventing it. You decide which evidence answers which control.
In CMDash this control is a row with an owner, a status, uploaded evidence kept with its full history, and an export an assessor can read.