Audit and Accountability (AU)¶
Domain: Audit and Accountability (AU)
Requirements in this domain: 9
Assessment Objectives in this domain: 29
AU.L2-3.3.1¶
AU.L2-3.3.1[a]¶
Assessment Objective
audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified.
Collection Approach: Document
Potential Evidence Examples
SSP, Audit and Accountability Policy, or logging SOP that lists the specific event types to be logged (e.g., logon/logoff, privilege use, account changes, file access to CUI) across the in-scope systems.
AU.L2-3.3.1[b]¶
Assessment Objective
the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined.
Collection Approach: Document
Potential Evidence Examples
SSP or logging SOP defining the required content/fields for each audit record (e.g., timestamp, source, event outcome, user/subject identity, event type) consistent with NIST SP 800-53 AU-3.
AU.L2-3.3.1[c]¶
Assessment Objective
audit records are created (generated).
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the logging tool/SIEM (or native OS/application log source) showing audit records are actively being generated for each in-scope system defined in the policy.
AU.L2-3.3.1[d]¶
Assessment Objective
audit records, once created, contain the defined content.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of a sample audit record (from the SIEM or native log) showing all of the required content fields defined in the policy are actually populated (timestamp, user, event type, outcome, etc.).
AU.L2-3.3.1[e]¶
Assessment Objective
retention requirements for audit records are defined.
Collection Approach: Document
Potential Evidence Examples
SSP, Audit Policy, or logging SOP that states the defined audit-log retention period and the rationale tying it to the system's risk level (e.g., 12 months online/searchable, plus archive).
Assessment Guide – Further Discussion
Are audit log retention requirements appropriate to the system and its associated level of risk [e]?
AU.L2-3.3.1[f]¶
Assessment Objective
audit records are retained as defined.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the SIEM/log-retention configuration (e.g., retention policy settings, storage/archive index) showing logs are retained for at least the defined period, with the oldest available records confirming actual retention.
AU.L2-3.3.2¶
AU.L2-3.3.2[a]¶
Assessment Objective
the content of the audit records needed to support the ability to uniquely trace users to their actions is defined.
Collection Approach: Document
Potential Evidence Examples
SSP or logging SOP defining the audit-record content needed to trace an action to a specific individual (e.g., unique user ID captured in every log entry rather than shared/generic accounts).
Assessment Guide – Further Discussion
Are users uniquely traced and held responsible for unauthorized actions [a]?
AU.L2-3.3.2[b]¶
Assessment Objective
audit records, once created, contain the defined content.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the SIEM/log source showing sample audit records where actions are tied to unique, individually-attributable accounts (not shared logins), demonstrating non-repudiation.
Assessment Guide – Further Discussion
Does the system protect against an individual denying having performed an action (non-repudiation) [b]?
AU.L2-3.3.3¶
AU.L2-3.3.3[a]¶
Assessment Objective
a process for determining when to review logged events is defined.
Collection Approach: Document
Potential Evidence Examples
SSP or logging SOP describing the process and cadence for deciding which event types should be logged/reviewed (e.g., annually, after an incident, or after a major system change).
Assessment Guide – Further Discussion
Do documented processes include methods for determining when to review logged event types (i.e., regular frequency, after incidents, after major system changes) [a]?
AU.L2-3.3.3[b]¶
Assessment Objective
event types being logged are reviewed in accordance with the defined review process.
Collection Approach: Artifact
Potential Evidence Examples
Evidence the review actually occurred at the defined cadence — e.g., meeting minutes, a Change Advisory Board (CAB) record, or a documented log-source review showing which event types/sources were evaluated.
Assessment Guide – Further Discussion
Do documented processes include methods for reviewing event types being logged (i.e., based on specific threat, use case, retention capacity, current utilization, and/or newly added system component or functionality) [b]?
AU.L2-3.3.3[c]¶
Assessment Objective
event types being logged are updated based on the review.
Collection Approach: Artifact
Potential Evidence Examples
Evidence of a resulting change based on the review — e.g., a ticket, change record, or SIEM configuration change log showing log sources or event types were added, removed, or tuned as a direct result of the review.
AU.L2-3.3.4¶
AU.L2-3.3.4[a]¶
Assessment Objective
personnel or roles to be alerted in the event of an audit logging process failure are identified.
Collection Approach: Document
Potential Evidence Examples
SSP or logging SOP naming the personnel/roles (e.g., ISSO, SOC analyst) to be alerted when the audit-logging process fails.
Assessment Guide – Further Discussion
Will the system alert personnel with security responsibilities in the event of an audit processing failure [a,b,c]?
AU.L2-3.3.4[b]¶
Assessment Objective
types of audit logging process failures for which alert will be generated are defined.
Collection Approach: Document
Potential Evidence Examples
SSP or logging SOP defining what constitutes an audit-logging process failure that triggers an alert (e.g., log-forwarding agent stops, log storage reaches capacity, SIEM ingestion halts).
Assessment Guide – Further Discussion
Will the system alert personnel with security responsibilities in the event of an audit processing failure [a,b,c]?
AU.L2-3.3.4[c]¶
Assessment Objective
identified personnel or roles are alerted in the event of an audit logging process failure.
Collection Approach: Artifact
Potential Evidence Examples
Sample alert artifact (email, ticket, or SIEM notification) showing the defined personnel were actually notified of a real or test audit-logging failure event.
Assessment Guide – Further Discussion
Will the system alert personnel with security responsibilities in the event of an audit processing failure [a,b,c]?
AU.L2-3.3.5¶
AU.L2-3.3.5[a]¶
Assessment Objective
audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined.
Collection Approach: Document
Potential Evidence Examples
SSP or Audit/Monitoring SOP describing the process for reviewing, analyzing, and reporting audit records to investigate suspicious or unauthorized activity, including who performs the review and how findings are escalated.
AU.L2-3.3.5[b]¶
Assessment Objective
defined audit record review, analysis, and reporting processes are correlated.
Collection Approach: Artifact
Potential Evidence Examples
Sampled example showing correlation across log sources led to a documented action — e.g., a SIEM correlation-rule alert tied to a help-desk ticket, CAB item, or incident record showing the triggering event and the resulting response.
Assessment Guide – Further Discussion
Are mechanisms used across different repositories to integrate audit review, analysis, correlation, and reporting processes [b]?
AU.L2-3.3.6¶
AU.L2-3.3.6[a]¶
Assessment Objective
an audit record reduction capability that supports on-demand analysis is provided.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the SIEM/log-analysis tool demonstrating an audit-record reduction/filtering capability — e.g., isolating and tracing a specific event back to a source device or account on demand — supporting ad hoc investigation.
AU.L2-3.3.6[b]¶
Assessment Objective
a report generation capability that supports on-demand reporting is provided.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the SIEM/reporting tool generating an on-demand audit report (e.g., a filtered report of privileged-account activity over a selected date range), demonstrating the reporting capability exists and works.
Assessment Guide – Further Discussion
Does the system support on-demand audit review, analysis, and reporting requirements and after-the-fact security investigations [b]?
AU.L2-3.3.7¶
AU.L2-3.3.7[a]¶
Assessment Objective
internal system clocks are used to generate time stamps for audit records.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of NTP client configuration on representative Windows, Linux/Unix, and network devices confirming each system uses its internal clock, synchronized via NTP, to generate audit-record timestamps.
AU.L2-3.3.7[b]¶
Assessment Objective
an authoritative source with which to compare and synchronize internal system clocks is specified.
Collection Approach: Document
Potential Evidence Examples
SSP or policy naming the authoritative time source (e.g., an internal NTP server that itself synchronizes to a DoD/US Naval Observatory or other authoritative external time source) used to synchronize all internal clocks.
AU.L2-3.3.7[c]¶
Assessment Objective
internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of NTP status/configuration on the logging infrastructure (SIEM, domain controllers, network appliances) confirming synchronization to the authoritative time source, ideally showing time drift within tolerance (ordinarily ≤1 second, per NIST guidance) and mapping to UTC.
Assessment Guide – Further Discussion
- Can the records’ time stamps map to Coordinated Universal Time (UTC), compare system clocks with authoritative Network Time Protocol (NTP) servers, and synchronize system clocks when the time difference is greater than 1 second [c]?
- Does the system synchronize internal system clocks on a defined frequency [c]?
AU.L2-3.3.8¶
AU.L2-3.3.8[a]¶
Assessment Objective
audit information is protected from unauthorized access.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of file-system/OS permissions on the audit-log storage location, or SIEM role-based access settings, showing only an authorized list of individuals can view/access audit information.
Assessment Guide – Further Discussion
Is there a list of authorized users for audit systems and tools [a]?
AU.L2-3.3.8[b]¶
Assessment Objective
audit information is protected from unauthorized modification.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of file-system/SIEM permissions showing write/modify access to audit records is restricted to the same authorized, limited group (i.e., audit data cannot be altered by unauthorized users).
AU.L2-3.3.8[c]¶
Assessment Objective
audit information is protected from unauthorized deletion.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of file-system/SIEM permissions showing delete access to audit records is restricted to the same authorized, limited group, preventing unauthorized destruction of log data.
AU.L2-3.3.8[d]¶
Assessment Objective
audit logging tools are protected from unauthorized access.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of SIEM/logging-tool administrative access controls (e.g., role-based access to the console itself) showing only authorized administrators can access the audit logging tool.
AU.L2-3.3.8[e]¶
Assessment Objective
audit logging tools are protected from unauthorized modification.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of SIEM/logging-tool permissions showing configuration/modification rights to the tool are restricted to authorized administrators only.
AU.L2-3.3.8[f]¶
Assessment Objective
audit logging tools are protected from unauthorized deletion.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of SIEM/logging-tool permissions showing delete rights within the tool (e.g., ability to purge logs or disable collectors) are restricted to authorized administrators only.
AU.L2-3.3.9¶
AU.L2-3.3.9[a]¶
Assessment Objective
a subset of privileged users granted access to manage audit logging functionality is defined.
Collection Approach: Document
Potential Evidence Examples
SSP or Audit Management Policy naming the specific privileged subset of users (e.g., "SIEM Administrators" group) authorized to manage audit-logging functionality (configure sources, retention, alerting).
AU.L2-3.3.9[b]¶
Assessment Objective
management of audit logging functionality is limited to the defined subset of privileged users.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the SIEM console or OS folder permissions confirming audit-logging management rights are limited to only the named privileged subset, with no additional accounts holding that access.
Assessment Guide – Further Discussion
Are audit records of nonlocal accesses to privileged accounts and the execution of privileged functions protected [b]?