AU-14(2): Capture and Record Content

The au-14(2): capture and record content requirement is an audit logging enhancement that pushes teams beyond basic “event occurred” logs. For many environments, default logs record timestamps, actors, and a generic action label. That is rarely enough to support incident response, insider threat investigations, or eDiscovery-style fact finding. AU-14(2) closes that gap by requiring content capture for defined event types, so your organization can later answer: what exactly was run, what exactly changed, and what exactly was accessed or transmitted.

This requirement shows up most painfully in modern stacks where the “real action” lives in API payloads, CI/CD pipelines, admin consoles, and SaaS audit feeds. If you do not decide upfront what content matters and how you will store it safely, you will either (a) miss the content during an incident, or (b) over-collect sensitive data and create privacy and retention risk. Your goal is a controlled, documented, and testable design: targeted content capture, protected storage, and repeatable review.

This page gives requirement-level implementation guidance you can hand to engineering, security operations, and system owners, then collect evidence that an assessor can validate against AU-14(2). ¹

Regulatory text

Excerpt: “NIST SP 800-53 control AU-14.2.” ²

Operator interpretation: AU-14(2) expects you to configure your audit logging so that, for a defined set of events, you capture the content necessary to understand the event, not just a summary. The control is typically assessed by verifying: (1) you identified event types that need content capture, (2) systems actually record that content, and (3) records are protected and retrievable for analysis. ¹

Plain-English interpretation (what “capture and record content” means)

For scoped events, your logs must include enough detail to reconstruct the action. Depending on the system, “content” may include:

• Command or query text (example: administrative command strings, database queries, IaC plan/apply content).
• Change details (example: “before” and “after” values for configuration changes, policy edits, access rule updates).
• Object identifiers and critical fields (example: which record was accessed, which file path was read, which role assignment changed).
• Request/response payload elements where the payload is the action (example: API calls that create users, change permissions, or move money).

You do not need to record every byte of every transaction by default. You do need a defensible, documented decision about which content is required for accountability and investigation, and you must show it is captured consistently. ¹

Who it applies to

Entity scope

• Federal information systems and programs assessed against NIST SP 800-53 Rev. 5. ¹
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down via contract, ATO boundary, or agency requirements. ¹

Operational context (where it matters most)

• Privileged access paths (system admins, cloud admins, DBAs).
• CI/CD and infrastructure automation (pipelines, runners, IaC).
• Identity systems (role grants, group membership changes, MFA resets).
• Data access layers (database reads of sensitive tables, bulk exports).
• High-risk business workflows (approvals, payment release, trading, clinical changes), if your system boundary includes them.

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

1) Assign ownership and write a one-page implementation standard

Name a control owner (Security, GRC, or platform security) and a technical owner per logging platform. Your standard should define:

• “Content” for your environment (commands, diffs, payload fields).
• The “must-capture” event categories.
• Where records are stored and who can access them.
• How you avoid collecting secrets unnecessarily.

This becomes the anchor artifact auditors ask for when they see AU-14(2) on the control set. ¹

2) Define the event list that requires content capture

Create an AU-14(2) event/content matrix. Keep it tight and reviewable.

Example matrix fields:

• Event category (e.g., privileged command execution)
• Systems in scope (e.g., Linux servers, Kubernetes control plane, cloud IAM)
• Content to capture (e.g., full command line; Kubernetes audit “requestObject” for specific verbs)
• Exclusions (e.g., redact auth headers; do not log full secret values)
• Logging source (e.g., EDR, cloud audit logs, DB audit, CI logs)
• Storage destination (e.g., SIEM + immutable archive)

If you cannot state what you capture and why, you will not be able to prove AU-14(2) is implemented. ²

3) Engineer the capture path (collection → normalization → storage)

Implement technical controls that reliably record the required content.

Common patterns:

• Cloud control plane logs: enable audit feeds; configure them to include request parameters where supported; ensure coverage for IAM and policy services.
• Kubernetes: configure audit policy rules to include request bodies for high-risk verbs and resources; store audit events centrally.
• Operating systems: ensure privileged command execution is captured by an endpoint/OS audit mechanism; include command line and user context.
• Databases: enable auditing for sensitive operations; capture query text or stored procedure calls where feasible, with safeguards to avoid logging secrets.
• CI/CD: capture pipeline run logs, deployment manifests, and approvals; preserve who approved and what artifact was deployed.

Design requirement: logs must be retrievable and protected from tampering within the system boundary. AU-14(2) is about capture; assessors will still expect it to work with your broader audit log protections in the AU family. ¹

4) Build redaction and minimization rules (so you don’t log secrets)

Content capture can accidentally collect:

• passwords, tokens, API keys
• full PII fields
• proprietary data payloads

Implement a rule set for masking and allowlisting:

• Mask known secret patterns and header fields.
• Record identifiers and deltas rather than full values for sensitive attributes when possible.
• For database queries, consider recording query structure and target objects rather than full parameter values, if parameters contain sensitive content.

Document your decisions in the event/content matrix. Auditors accept constrained capture when it is justified and consistent. ¹

5) Prove completeness with testing and sampling

Run a repeatable test:

• Generate each scoped event type (admin command, permission change, sensitive query, pipeline deploy).
• Confirm the log record contains the required content fields.
• Confirm it lands in the central log store and is searchable.
• Confirm access controls prevent unauthorized modification or deletion.

Store test outputs as evidence. This is where many teams fail: they have logging “enabled” but cannot demonstrate the content is present. ²

6) Operationalize: monitoring, review, and retention alignment

Put AU-14(2) on a cadence:

• Review the event/content matrix when you add new platforms or high-risk workflows.
• Review logging pipeline health (drops, parsing failures, connector errors).
• Confirm retention meets your organization’s requirements and contracts.

Daydream (as a GRC system) fits naturally here by mapping AU-14(2) to a control owner, embedding the procedure, and scheduling recurring evidence requests (config exports, samples, and review sign-offs) so you can stay assessment-ready. ²

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Design artifacts

• AU-14(2) implementation standard (definition of “content,” scope, responsibilities).
• Event/content matrix with systems, event types, content fields, redaction rules.
• Architecture diagram or data flow for logging pipeline (sources → SIEM/archive).

Operational artifacts

• Configuration exports/screenshots from log sources showing content capture settings.
• Sample log records for each scoped event type showing required fields.
• Log pipeline health reports (ingest status, connector status, parsing success).
• Access control evidence for log stores (RBAC, write protections).
• Periodic review records (ticket, checklist, sign-off).

Common exam/audit questions and hangups

Auditors and 3PAOs tend to ask:

• “Show me which events require content capture and where that decision is documented.”
• “Prove a privileged action log includes the executed content (command/query/change).”
• “How do you prevent sensitive values from being recorded in logs?”
• “Can an admin alter or delete the audit records?”
• “How do you know all in-scope systems are sending logs?”

Hangups you can preempt:

• Your policy says “we log admin activity,” but samples only show “login success.”
• You rely on a SaaS audit feed that does not include payload details; you did not implement compensating capture (application-level logs).
• You capture content but cannot search it due to parsing failures or inconsistent schemas.

Frequent implementation mistakes (and how to avoid them)

1. Mistaking metadata for content
   Fix: require “reconstructability” in your matrix. If you cannot replay the change from the record, the content is too thin.

2. Over-collecting sensitive data
   Fix: define redaction and “do-not-log” fields. Test with real payloads that include secrets.

3. No boundary clarity
   Fix: tie the matrix to your system inventory and authorization boundary so you can prove coverage.

4. Logs exist, but nobody owns them
   Fix: assign a control owner and technical owners. Require periodic evidence pulls and sign-off.

5. One-time setup with no drift control
   Fix: monitor connectors and pipeline health; review whenever systems change.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog, so this page does not cite specific actions or outcomes.

Operationally, the risk is straightforward: without content capture, investigations stall. You can identify that “something happened” but cannot prove what changed, what data was accessed, or what command ran. That increases incident duration, complicates root-cause analysis, and weakens accountability for privileged activity. ¹

Practical execution plan (30/60/90)

First 30 days (baseline and scope)

• Assign AU-14(2) control owner and logging platform owners.
• Draft the AU-14(2) implementation standard.
• Build the first version of the event/content matrix for your highest-risk systems.
• Identify gaps where content is not currently captured or is unsafe to capture.

By 60 days (implement and prove)

• Implement content capture configurations for the scoped event list.
• Implement redaction/minimization rules.
• Centralize storage and confirm access controls for audit records.
• Run test events and collect sample logs for each event category.

By 90 days (operationalize and harden)

• Add drift controls: change management hooks, monitoring for pipeline failures, periodic reviews.
• Expand scope to remaining in-boundary systems and key third parties where you ingest audit feeds.
• Build an assessment package in Daydream: procedure, matrix, configs, samples, and recurring evidence tasks mapped to AU-14(2). ²

Frequently Asked Questions

What counts as “content” if we use SaaS products with limited audit logs?

Use the SaaS audit feed where it provides sufficient detail, then add application-level logs or compensating telemetry for actions where the feed lacks payload or change details. Document the gap and the compensating capture in your event/content matrix. ¹

Do we have to record full API request and response bodies?

Only for the event types you scoped for content capture, and only to the extent needed to reconstruct the action. Many teams record selected fields (object IDs, permission deltas, action parameters) and mask secrets to control sensitivity. ¹

How do we handle secrets that might appear in command lines or payloads?

Implement redaction rules and prohibit patterns (tokens, passwords, authorization headers) from being stored in logs. Validate by generating test events that include representative secrets and verifying masking in stored records. ¹

Is a screenshot of a SIEM search enough evidence?

Keep screenshots for quick validation, but also retain raw sample records (exported JSON where possible) and source configuration exports that prove the system is set to capture content. Auditors commonly ask for both configuration proof and sample records. ¹

What if teams argue content capture is too expensive or too noisy?

Narrow scope to the highest-risk event categories first (privileged changes, access control changes, sensitive data exports), then expand as you prove value. A tight matrix with explicit exclusions is easier to defend than broad collection with no plan. ¹

How should we map AU-14(2) into our control library and evidence program?

Map AU-14(2) to a named control owner, a documented implementation procedure, and recurring evidence artifacts (config exports, samples, review sign-offs). Daydream supports this mapping and keeps the evidence requests on a schedule so audits are not a scramble. ²

Footnotes

1. NIST SP 800-53 Rev. 5

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