AU-7(1): Automatic Processing

AU-7(1) is an operational requirement disguised as a tooling requirement. Auditors are not asking whether you have “logs.” They are asking whether your organization can quickly answer concrete questions from audit data: who did what, on which system, from where, when, and with what result. The control’s focus is the ability to process audit records automatically, then sort and search them for defined events of interest using defined fields.

This matters most in moments where time is scarce: incident response, insider investigations, privileged access reviews, and proof of control operation during an assessment. If your team depends on manually pulling local log files, lacks consistent fields across sources, or cannot reproduce searches and results, you will struggle to demonstrate AU-7(1) even if you retain lots of logs.

This page translates AU-7(1) into a requirement you can assign, implement, test, and evidence. It assumes you already have baseline logging (AU-2/AU-12 style practices). Your goal here is to make logs usable at speed, with repeatable searches based on agreed-upon audit record content. ¹

Regulatory text

Requirement excerpt: “Provide and implement the capability to process, sort, and search audit records for events of interest based on the following content: [fields within audit records].” ²

Operator interpretation: You need a functioning capability (people + process + technology) that can:

1. ingest audit records from in-scope systems,
2. normalize them enough that you can reliably filter/sort/search,
3. execute searches for pre-defined “events of interest” using specific audit record fields (for example: user, action, object, time, source, result),
4. reproduce the results later.

This is not satisfied by “logs exist somewhere.” It is satisfied when an assessor can watch your team pull up a system and run searches that answer common audit/security questions using consistent fields, with saved searches/detection rules and documented outcomes.

Plain-English requirement: what AU-7(1) is really asking

AU-7(1) expects automatic processing of audit records. In practice, that means:

• You can search across audit records centrally (or through a federated capability) without bespoke scripting each time.
• You can sort and filter by defined fields (not free-text only).
• You can focus searches on events of interest (the events you care about for security monitoring, investigations, and compliance testing).
• The capability is implemented and used, not shelfware. ²

Think of AU-7(1) as “operational log analytics readiness.” Your audit logs become evidence only when you can retrieve and interpret them on demand.

Who it applies to (entity and operational context)

AU-7(1) is commonly applied in:

• Federal information systems, including agency-operated environments.
• Contractor systems handling federal data, including cloud or managed services environments that support federal missions or process federal information. ²

Operationally, it applies wherever audit records exist and matter:

• Identity platforms (SSO, directory services, PAM)
• Cloud control planes (IAM, KMS, storage access)
• Network/security tooling (firewalls, EDR, IDS)
• Core applications with sensitive workflows (case management, payments, claims, HR)
• Databases and administrative interfaces
• CI/CD and code platforms (builds, deployments, admin actions)

If you have a boundary definition for your system authorization, align AU-7(1) scope to that boundary and explicitly list included log sources.

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

Step 1: Assign ownership and write a control card

Create a short “control card” that an operator can run without interpretation:

• Objective: Enable processing/sorting/searching of audit records for defined events of interest by defined fields.
• Owner: Security Operations (primary), with GRC (oversight) and IT/app owners (log source support).
• In-scope systems/log sources: list them.
• Events of interest: categories and examples.
• Required audit fields: the fields you must be able to search/sort on.
• How it runs: platform used, saved searches, alert rules, dashboards, review cadence.
• Exceptions: what happens when a system cannot produce required fields.

This addresses the common audit failure mode: “We think we do this, but nobody owns it.”

Step 2: Define “events of interest” in a way your tools can implement

Create an “events of interest” register that is precise enough to become queries and detections. Example categories:

• Authentication anomalies (repeated failures, impossible travel where available, new device sign-in where available)
• Privileged access events (role assignment, sudo, policy changes, break-glass usage)
• Data access events (access to sensitive tables/buckets, mass export, permission changes)
• Administrative changes (logging disabled, retention changed, audit policy modified)
• Integrity events (tamper indications, agent stopped)

For each event, define:

• Trigger description (human)
• Log sources that can produce it
• Minimum fields required to investigate (user, timestamp, action, target, outcome, source IP/host, correlation ID/session where available)
• Query/detection logic (tool-specific implementation reference)

AU-7(1) explicitly ties searches to “the following content: [fields within audit records].” Treat that bracket as a required local parameter: you must fill it with your field list. ²

Step 3: Standardize the audit record fields and map each source to the schema

Build a mapping table that shows, per log source:

• What fields the source emits natively
• How they map to your standard field names (normalization)
• Gaps (fields missing)
• Compensating steps (enrich from CMDB/asset inventory, identity provider, EDR, or network telemetry)

A simple mapping table prevents “field drift,” where searches work for one system but fail for another.

Step 4: Implement the technical capability (central search + processing)

You can satisfy AU-7(1) with a SIEM/log analytics platform, or another centralized log management system, as long as it supports:

• Ingest and parsing
• Indexed fields for filtering/sorting
• Saved searches
• Role-based access controls for who can query sensitive logs
• Exportable results for casework and audit evidence

Operational minimum: a reviewer can open the platform and run saved searches that return results based on your defined fields.

Step 5: Build repeatable searches and review routines

Create a small library of:

• Saved searches tied to your events of interest
• Dashboards for high-signal monitoring
• Alert rules where appropriate, with routing and escalation

Then define the review routine:

• Who reviews which saved searches/alerts
• How findings are documented (ticket/case system)
• How false positives are tuned (change control for detection logic)
• How you prove the routine occurred (review attestation, exported report, ticket evidence)

Step 6: Prove it works with a control health check

Run a recurring health check that tests:

• Log ingestion is active for each source
• Required fields are populated (not blank)
• Searches return expected results (use test events where feasible)
• Access to search is controlled and auditable

Track defects to closure with owners and due dates. This is often the difference between “implemented” and “operating.”

Step 7: Manage third-party and managed service dependencies

If a third party hosts part of your stack (managed SIEM, SaaS app logs, MSP-operated infrastructure):

• Contractually require log access, field availability, and retrieval timelines
• Confirm your team can query those logs (or receive structured exports) in time to support investigations and audits
• Document responsibility splits (who runs searches, who retains logs, who responds to requests)

This is where AU-7(1) breaks in practice: logs exist, but you cannot search them without opening a support ticket.

Required evidence and artifacts to retain

Keep an “AU-7(1) evidence bundle” that is easy to hand to an assessor:

Design evidence

• AU-7(1) control card (owner, scope, events of interest, required fields)
• Audit record field schema/standard (field list and definitions)
• Log source-to-field mapping table
• Architecture diagram showing log flow (sources → collector → search platform)

Operational evidence

• Screenshots or exports of saved searches and dashboards tied to events of interest
• Alert rule configurations (where used)
• Samples of query results showing filtering/sorting by required fields
• Review records (tickets/cases) showing investigations and outcomes
• Control health check results and remediation tracking

Access and integrity evidence

• Role-based access to the log search platform (who can query, who can administer)
• Change control records for detection/search logic updates

Store evidence in a named, consistent location with a retention rule aligned to your audit program.

Common exam/audit questions and hangups

Assessors tend to probe the “capability” and the “fields”:

1. “Show me how you search for privileged role changes across the environment.”
   Hangup: logs are split across tools with inconsistent fields.

2. “What are your defined events of interest, and where are they documented?”
   Hangup: “events of interest” exist only in someone’s head or an IR playbook, not mapped to queries.

3. “Which audit record fields do you require, and how do you ensure they are populated?”
   Hangup: no field standard; searches rely on raw message text.

4. “Demonstrate that this is used operationally, not just configured.”
   Hangup: no review evidence, no tickets, no tuning history.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating AU-7(1) as a procurement checkbox (“we bought a SIEM”).
  Fix: require saved searches, event definitions, and operational review evidence.

• Mistake: Searching unstructured message text only.
  Fix: normalize key fields and test that they index correctly.

• Mistake: No explicit “fields within audit records” list.
  Fix: publish a minimum field standard and map every source to it. ²

• Mistake: Log sources added without onboarding to searches.
  Fix: make “logging + field mapping + saved searches” a go-live gate in change management.

• Mistake: Third-party logs are inaccessible during an incident.
  Fix: contract for access and prove retrieval/search during tabletop exercises.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for AU-7(1), so treat this as an assurance and customer diligence risk: failing AU-7(1) usually surfaces as an inability to investigate incidents, prove control operation, or answer assessor questions quickly. The business impact is delayed containment, incomplete root cause analysis, and weaker audit outcomes. ³

Practical 30/60/90-day execution plan

Use phases to avoid calendar commitments you cannot meet, but still drive urgency.

Days 0–30: Stand up the requirement and close the biggest visibility gaps

• Publish the AU-7(1) control card with named owner and in-scope systems.
• Define your minimum audit record fields and “events of interest” register.
• Inventory log sources and identify the highest-risk sources that are not centrally searchable.
• Implement or validate centralized log search access for Security Operations and auditors (read-only as needed).
• Create initial saved searches for a small set of high-signal events (privileged changes, authentication anomalies, logging disabled).

Days 31–60: Normalize fields and make searches repeatable

• Build the source-to-field mapping table and start normalizing ingestion/parsing.
• Turn saved searches into a documented library with owners and change control.
• Establish the review workflow (tickets/cases) and start retaining review evidence.
• Validate third-party log access paths; document who runs searches and who provides exports.

Days 61–90: Prove ongoing operation and harden for assessments

• Run the first formal control health check and track remediation to closure.
• Add coverage for remaining in-scope sources and expand events of interest.
• Conduct an internal “audit-style” demo: a reviewer requests an event, operators run the saved search, export results, and link the case record.
• Package the evidence bundle in a single location for assessments.

Where Daydream fits

Daydream becomes useful once you need AU-7(1) to run like a control, not a project: a single place to store the control card, required evidence bundle definitions, control health check results, and remediation tracking, so you can answer diligence requests without rebuilding the story each time.

Frequently Asked Questions

What counts as “automatic processing” for AU-7(1)?

Automatic processing means your environment has a built capability (typically a centralized log analytics or SIEM-like system) that can filter/sort/search audit records by defined fields without one-off manual parsing. Auditors expect repeatable searches tied to defined events of interest. ²

Do we have to use a SIEM to satisfy AU-7(1)?

NIST does not mandate a specific product in the provided text. You do need a demonstrable capability to process, sort, and search audit records by defined fields, and to show evidence that it works in practice. ²

How do we decide which “fields within audit records” to specify?

Start with fields you need to answer investigation questions: who, what action, what target, when, where/from what system, and result. Then map each in-scope log source to that field list and document gaps with compensating enrichment steps. ²

We have multiple clouds and SaaS tools. Can we keep logs separate?

You can, as long as your team can still search and sort audit records for events of interest using consistent fields and produce results on request. If separation causes slow retrieval or inconsistent fields, assessments will expose it quickly.

What evidence is most persuasive to an auditor for AU-7(1)?

A documented events-of-interest list mapped to saved searches, plus exports/screenshots of queries and results, and tickets showing review and follow-up. Pair that with a log source-to-field mapping table to show the field-based capability is real.

How do we handle a system that cannot emit required fields?

Treat it as an exception with a documented rationale, a compensating control (for example, enrichment from another authoritative source), and a plan to remediate. Keep the exception register with approvals and revisit it during control health checks.

Footnotes

1. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

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

3. NIST SP 800-53 Rev. 5