AU-3: Content of Audit Records

AU-3 is one of the controls that separates “we collect logs” from “our logs can support an investigation.” A Security team can have terabytes of events and still fail AU-3 if records don’t contain the minimum details needed to establish what occurred. The operational work is less about buying tools and more about standardizing audit record content, making it consistent across systems, and showing repeatable evidence that it stays consistent.

This requirement commonly fails in real programs for predictable reasons: logs are enabled but missing user identity; timestamps differ by system and aren’t normalized; key admin actions aren’t audited; cloud control-plane logs exist but aren’t forwarded; or the SIEM strips fields during parsing. AU-3 forces you to treat audit records as structured evidence, not exhaust.

This page gives you requirement-level implementation guidance you can execute quickly: scope the systems that matter, define the minimum audit fields, implement collection and normalization, validate with tests, and retain artifacts that make an assessor’s job easy. The source requirement comes from NIST SP 800-53 Rev. 5. ¹

Regulatory text

Control requirement (excerpt): “Ensure that audit records contain information that establishes the following:” ²

Operator interpretation: AU-3 expects you to define and implement a minimum set of audit record elements so the organization can determine the essential facts of an event (who/what/when/where/what happened/outcome) from the audit record itself. You operationalize AU-3 by (1) specifying required fields, (2) configuring each log source to emit those fields, (3) preserving them through pipelines (agents, forwarders, parsers, SIEM), and (4) testing and documenting that the required fields are present for in-scope event types. ²

Plain-English requirement: what AU-3 is asking for

AU-3 is a content completeness rule for audit logs. Your audit records must contain enough information to:

• Identify the actor (human, service account, process, or third party)
• Identify the action/event (what was attempted)
• Identify the time (with consistent time source/format)
• Identify the target/resource (system, dataset, object, account, configuration item)
• Indicate the outcome (success/failure)
• Support correlation (request IDs, session IDs, source IP/device identifiers)

NIST does not give you a single universal field list in the excerpt provided here, so your job is to define a defensible, program-wide “minimum audit record schema” and apply it consistently to priority systems. Anchor your schema to investigation needs: incident response, insider threat review, change accountability, and regulatory inquiries. ¹

Who it applies to (entity and operational context)

AU-3 applies when you are implementing NIST SP 800-53 controls for:

• Federal information systems
• Contractor systems handling federal data ²

Operationally, the control applies to any environment where audit records are relied on for accountability and security monitoring, including: identity platforms, endpoints, servers, network/security appliances, databases, applications, CI/CD tooling, and cloud control planes. It also applies to third parties when their systems perform or administer in-scope processing and you need their logs (or log-derived reports) to support your monitoring and investigations.

What you actually need to do (step-by-step)

1) Set scope: systems and event classes that must meet AU-3

Create an AU-3 scope list tied to your authorization boundary or system inventory. Minimum recommended categories:

• Identity and access management (SSO, directory, PAM)
• Admin control plane for cloud and key SaaS
• Operating systems and endpoints
• Network/security controls (firewalls, WAF, IDS/IPS)
• Data platforms with sensitive data access paths
• Applications that enforce authorization decisions

Deliverable: “AU-3 Logging Scope Register” with system owner, log source, and where logs land (SIEM/data lake).

2) Define a minimum audit record schema (your “AU-3 field standard”)

Write a one-page standard that lists required fields and acceptable formats. Example schema (adapt to your tooling):

Field	Purpose	Example / Notes
event_time	Timeline reconstruction	UTC preferred; define format and time sync expectation
actor_id	Accountability	User ID, service account, role, or API key identifier
actor_type	Disambiguation	human/service/process/third-party
action	What happened	“create_user”, “delete_bucket_policy”, “read_record”
target	What was affected	resource ID, hostname, database/table/object
outcome	Result	success/fail + reason code when available
source	Where it originated	source IP, device ID, user agent, workload identity
correlation_id	Link related events	request ID, session ID, trace ID
system	Log source	product/system name + environment
privilege_context	Admin vs user	role, group, elevation indicator

Keep this standard short. Auditors reward clarity and consistent application more than ambition.

3) Map the schema to each log source (field-by-field)

For each in-scope system, build a “Log Source AU-3 Mapping” that answers:

• Which native event types are in scope (auth, admin changes, data access, policy changes)?
• Which fields exist natively?
• Which fields must be added via enrichment (directory lookup, asset inventory, CMDB tags)?
• Which fields are currently lost during parsing/forwarding?

Practical tip: include a “field preservation” check for pipelines. Many teams meet AU-3 at the source but fail it in the SIEM because parsing drops actor identifiers or overwrites timestamps.

4) Configure logging, forwarding, parsing, and normalization

Implement in the places that control content:

• At the source: enable the right audit log categories and include identity/context fields.
• In collectors/agents: ensure structured formats (JSON) where possible.
• In the SIEM pipeline: parse into normalized fields and retain raw events.
• In enrichment: add asset owner, environment tags, and identity resolution where needed.

Document the “golden configuration” for each platform (screenshots, exported configs, infrastructure-as-code snippets).

5) Validate with tests (and schedule re-validation)

Create a repeatable test script per log source: generate a known action and confirm the resulting audit record includes every required AU-3 field. Examples:

• Log in with a test account, fail login once, then succeed
• Create and delete a test object/resource
• Change a test policy and revert it

Record: the action performed, the log event ID(s), and a screenshot or exported JSON showing required fields present. This becomes your strongest AU-3 evidence because it demonstrates operational effectiveness, not intent.

6) Assign ownership and build recurring evidence

AU-3 fails when nobody owns log content quality. Assign:

• Control owner (often Security Engineering / SOC platform)
• System owners accountable for source settings
• GRC owner accountable for evidence and testing cadence

Daydream fits cleanly here as the system to map AU-3 to an owner, implementation procedure, and recurring evidence artifacts, so evidence doesn’t live in scattered tickets and screenshots. ²

Required evidence and artifacts to retain

Aim for artifacts that answer “what is required” and “prove it works.”

Design evidence (what you intended):

• AU-3 minimum audit record schema (version-controlled)
• AU-3 scope register (systems + owners)
• Log source AU-3 mappings (field-by-field)
• Logging standard / engineering runbook for onboarding new sources

Operating evidence (proof it works):

• Exported sample audit records per source showing required fields
• Test scripts and test results (date, tester, event IDs)
• SIEM parsing rules / pipelines and change history
• Screenshots or config exports showing audit categories enabled

Governance evidence (stays working):

• Change management records for logging pipeline changes
• Exceptions register for sources that cannot emit certain fields, with compensating controls

Common exam/audit questions and hangups

Assessors and auditors commonly ask:

• “Show me an audit record for an admin change. Where is the user identity and outcome?”
• “Can you correlate an event across systems with a request/session ID?”
• “Do logs show object/resource identifiers, or only generic messages?”
• “Are timestamps consistent and attributable to a trusted time source?”
• “How do you know parsing didn’t drop fields after ingestion?”

Hangups: teams show a logging policy but cannot produce field-complete sample records across representative systems, or they produce records where identity is ambiguous (shared admin accounts, untracked service principals).

Frequent implementation mistakes (and how to avoid them)

1. Relying on “logging enabled” toggles.
   Fix: require field-level validation evidence for each source and event class.

2. Losing critical fields in the pipeline.
   Fix: retain raw logs, test post-ingestion content, and lock parser changes behind review.

3. No standard for service accounts and third-party actions.
   Fix: include service principal identifiers, API key IDs, and “actor_type” in your schema; document naming conventions.

4. Inconsistent timestamps and time zones.
   Fix: standardize to UTC in the SIEM and document time normalization.

5. Over-scoping on day one.
   Fix: prioritize systems that govern access and administrative change, then expand.

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement, so you should treat AU-3 primarily as an assessment and investigation-readiness control rather than a standalone enforcement trigger.

Risk-wise, weak AU-3 implementation shows up during incident response: you cannot prove what happened, cannot attribute actions, and cannot bound impact. It also increases audit friction because assessors must infer event context from multiple partial records instead of reading one complete record.

A practical 30/60/90-day execution plan

Days 1–30: Get to a defensible standard and initial coverage

• Name AU-3 control owner and backup; document RACI.
• Build the minimum audit record schema (one page) and approve it.
• Produce the AU-3 scope register for your highest-risk systems.
• For the top log sources, create log source mappings and collect sample events that demonstrate field completeness.

Days 31–60: Close gaps and harden the pipeline

• Fix missing fields at the source (enable audit categories, include identity context).
• Fix parsing gaps (normalization rules, field preservation, raw log retention).
• Add enrichment where required (asset tags, identity resolution).
• Write test scripts per log source and run them, storing results as evidence.

Days 61–90: Operationalize and make it repeatable

• Bake AU-3 checks into onboarding for new systems and third parties.
• Add change controls for SIEM parsers and log pipelines.
• Establish recurring reviews of log content quality and exceptions.
• Centralize evidence collection and mapping (for example, in Daydream) so AU-3 stays audit-ready between formal assessments. ²

Frequently Asked Questions

Does AU-3 require a SIEM?

AU-3 requires complete audit record content, not a specific tool. A SIEM helps you normalize and preserve fields across sources, but you can meet AU-3 with other centralized logging approaches if you can prove content completeness post-ingestion.

How do we handle systems that cannot log all required fields?

Document the gap as an exception, record what fields are missing, and add compensating controls like enrichment (identity/asset context) or tighter access controls. Keep the exception register and show a roadmap or vendor plan for closing the gap.

Do we need to keep raw logs as well as parsed logs?

Keeping raw logs makes AU-3 easier to defend because you can prove what the source emitted and show that parsing did not remove fields. If you cannot keep raw logs, document how you preserve integrity and completeness through the pipeline.

What’s the minimum set of events we should test for AU-3 evidence?

Test events that represent your highest audit value: authentication (success/fail), privilege changes, configuration/admin changes, and sensitive data access paths. Pick events that produce unambiguous records and can be repeated on demand.

How does AU-3 interact with third parties?

If a third party operates or administers in-scope systems, your contracts and oversight should require audit records with the fields you need and a method to access them. Treat third-party logs as first-class evidence and test them like internal sources.

What does “mapped to owner, procedure, and evidence” look like in practice?

A single control record ties AU-3 to a named owner, a step-by-step runbook, and a checklist of recurring artifacts (schemas, mappings, sample records, test results). Daydream is useful because it keeps that mapping current and reduces scramble work during assessments. ²

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON