AU-3: Content of Audit Records

What this control requires

AU-03 requires every system to produce audit records containing six data points: event type, timestamp, location, source, outcome, and identity. Without all six fields present in every record, your logs become fragments that can’t reliably reconstruct what happened during an incident or audit.

In practice, this means each log entry must include enough detail to answer the five forensic questions an investigator asks first: what, when, where, who, and whether it succeeded or failed. Event descriptions, timestamps, source and destination addresses, user or process identifiers, success or failure indicators, and filenames all fall within scope. Organizations subject to NIST SP 800-53 often discover their logging infrastructure captures some of these fields but silently drops others, especially source addresses and entity identifiers for automated processes.

The control also flags a privacy dimension that teams frequently overlook. Audit trails that record user inputs or usage patterns can inadvertently expose personally identifiable information. You need to balance forensic completeness against data minimization, ensuring records contain enough to support investigations without becoming a liability if the logs themselves are breached.

Why it matters

Incomplete audit records are one of the most common findings in federal system assessments, and the gap between “we have logging enabled” and “our logs contain the six required fields” is where investigations stall. When a record lacks the source address or the identity of the process that triggered an event, analysts can see that something happened without being able to trace it back to a root cause.

The consequences compound during incident response. Forensic teams rely on correlated timestamps, source identifiers, and outcome codes to reconstruct attack timelines. If your audit records omit even one of these fields, the reconstruction develops blind spots, and attackers learn to operate inside those gaps.

Regulatory auditors reviewing compliance monitoring practices will flag these omissions as material weaknesses.

Failure to maintain AU-03 introduces audit risk across every baseline. Because this control applies at LOW, MODERATE, and HIGH impact levels, there is no system category where incomplete audit content is acceptable. Certification bodies can issue findings that delay or block authorization to operate, and repeat failures may result in system shutdown orders.

What attackers exploit

• Missing identity fields that prevent attribution of privileged actions to specific accounts or service principals
• Absent timestamp granularity that blocks timeline correlation across distributed systems
• Omitted source addresses that allow lateral movement to go undetected across network segments
• Incomplete outcome codes that mask failed authentication attempts or permission escalations
• Lack of filename logging that conceals which files were accessed, modified, or exfiltrated

How to implement

The most common failure mode is not the absence of logging but the assumption that default logging configurations satisfy AU-03. Most operating systems, databases, and cloud platforms ship with audit logging that captures timestamps and event types but omits source addresses, process identifiers, or outcome details. Implementation starts with a gap analysis between what your systems currently log and what AU-03 explicitly requires.

For your organization

Step 1: Inventory your auditable events. Start with the event types defined under AU-02 (Event Logging) and map each one to the six required content fields. For each event type, verify that your current logging configuration captures event type, timestamp, location, source, outcome, and identity. Document gaps in a control assessment worksheet.

Step 2: Configure logging infrastructure. Adjust audit policies at the operating system, application, and network levels. On Windows systems, enable Advanced Audit Policy Configuration to capture logon events with source IP and process ID. On Linux, configure auditd rules to record syscalls with user identity, file paths, and exit codes. For cloud workloads, enable provider-specific audit trails (such as CloudTrail or Activity Log) and verify that all six fields are present in the output schema.

Step 3: Normalize and centralize. Ship logs to a centralized platform, whether a security information and event management (SIEM) tool, a log management service, or a data lake. Normalize field names across sources so that “source IP,” “client_address,” and “remote_host” all map to a single canonical field. This step is critical for meeting AU-08 (Time Stamps) requirements as well, since timestamp formats must be consistent.

Step 4: Validate with sample records. Pull a sample of 10 to 20 audit records from each system category and verify that all six content fields are populated. Pay special attention to automated processes and service accounts, which frequently log without a human identity field.

Step 5: Address privacy considerations. Review audit record content against your privacy plan. If records capture user inputs, screen content, or usage patterns, implement filtering or masking to limit PII exposure while preserving forensic value. Document these decisions in your system security plan.

Common mistakes:

• Relying on default logging without validating field completeness
• Logging human users but not service accounts or automated processes
• Using inconsistent timestamp formats across systems, breaking correlation
• Capturing events without outcome codes, making it impossible to distinguish successful actions from failed attempts

For your vendors

What to ask in a security questionnaire. Request that vendors describe the specific fields included in their audit records. Ask whether records capture event type, timestamp, source address, process or user identity, and outcome for every auditable event. A NIST 800-53 security questionnaire should include AU-03-specific questions rather than generic “do you have logging?” items.

What evidence to request. Ask for sample audit records (redacted if necessary) that demonstrate all six content fields. Request the vendor’s audit and accountability policy, their list of auditable events, and system configuration documentation showing how logging is configured. Compliance certificates alone do not prove field-level completeness.

Red flags. Be cautious if a vendor cannot produce sample records or if their samples lack source addresses or identity fields. Another warning sign is when the vendor claims “we log everything” but cannot describe specific field mappings. Vendors managing third-party risk requirements under NIST 800-53 should be able to articulate exactly which fields their audit records contain.

How to verify beyond self-attestation. If you have access to the vendor’s environment, pull a sample of audit records and check field completeness yourself. If access is not available, request a third-party assessment report (such as a SOC 2 Type II) that specifically addresses audit record content, not just the existence of logging.

Evidence examples

Cross-framework mapping

Related controls

• AU-02 — Event Logging: Defines which events to log. AU-03 specifies what each log entry for those events must contain.
• AU-08 — Time Stamps: Requires reliable, synchronized timestamps. AU-03 depends on accurate timestamps as one of its six mandatory content fields.
• AU-12 — Audit Record Generation: Governs the mechanisms that produce audit records. AU-03 defines the content those mechanisms must capture.
• AU-14 — Session Audit: Extends logging to capture entire user sessions, building on the per-event content requirements of AU-03.
• MA-04 — Nonlocal Maintenance: Requires audit trails for remote maintenance sessions, where AU-03 content fields are essential for accountability.
• PL-09 — Central Management: Supports centralized configuration of audit content requirements across distributed systems.
• SA-08 — Security and Privacy Engineering Principles: Guides system design to ensure audit record content is architecturally supported from the start.
• SI-07 — Software, Firmware, and Information Integrity: Protects the integrity of systems that generate and store audit records.
• SI-11 — Error Handling: Ensures error conditions are logged with sufficient content to support forensic analysis under AU-03.

Frequently asked questions

What is NIST SP 800-53 AU-03

AU-03 requires every system audit record to contain six specific data points: event type, timestamp, location, source, outcome, and identity of associated individuals or entities. This control ensures logs are forensically useful rather than just voluminous. Unlike AU-02, which determines which events get logged, AU-03 governs the specific fields each record must include, such as source and destination addresses, user or process identifiers, and success or failure indicators drawn from your organization-defined auditable events list.

What happens if AU-03 is not implemented

Without AU-03 compliance, your audit records will lack the content needed to reconstruct security events during investigations. Incomplete log fields, particularly missing source addresses or entity identifiers, create forensic blind spots that delay incident response and may allow attackers to operate undetected. Auditors assessing your system security plan will flag missing content fields as a control failure, potentially blocking your authorization to operate across LOW, MODERATE, and HIGH baselines.

How do you audit AU-03

Auditors assess AU-03 by examining your audit and accountability policy, reviewing system configuration settings that define log field capture, and pulling sample audit records from production systems to verify all six content fields are populated. They check that records establish event type, timestamp, location, source, outcome, and identity for each auditable event. Auditors also review your procedures addressing content of audit records and interview system administrators to confirm that automated processes and service accounts produce records with the same field completeness as human-initiated events.

What is the difference between AU-02 and AU-03

AU-02 defines which events your system must log, while AU-03 specifies what information each log entry must contain. You can satisfy AU-02 by identifying and enabling logging for the right event types, but if those log entries lack source addresses, process identifiers, or outcome indicators, you fail AU-03. Practitioners often configure event logging under AU-02 without verifying that each record contains AU-03’s six mandatory fields, which is why auditors check both controls together using your NIST 800-53 compliance checklist.