AU-7(2): Automatic Sort and Search

Compliance teams rarely fail AU-7(2) because they lack logs. They fail because they cannot produce the right slice of audit data fast, with consistent filters, and with evidence that the capability works in production. AU-7(2) is a reporting enhancement: it expects your audit reporting tooling (SIEM, log analytics platform, cloud-native logging, or a managed detection platform) to automatically sort and search audit records across the systems in scope.

For a CCO or GRC lead, the fastest path is to define what “audit record” means in your environment (which sources, what fields, what retention location), then standardize searchability. That means indexing, field normalization, time synchronization alignment (at least from an analysis perspective), and a small library of saved searches that map to real audit questions: privileged activity, authentication failures, configuration changes, access to sensitive data, and log tampering indicators.

This page focuses on requirement-level execution. You will leave with a concrete build plan, an evidence bundle checklist, and the audit questions that commonly expose gaps.

Regulatory text

AU-7(2): Automatic Sort and Search is captured in your source material as: “NIST SP 800-53 control AU-7.2.” (NIST SP 800-53 Rev. 5 OSCAL JSON). The control enhancement title clarifies the operator intent: your audit reporting must support automatic sorting and searching.

Operator interpretation of the text:
You must implement audit reporting mechanisms that let authorized users rapidly:

• Search audit records by relevant attributes (for example: user, host, application, event type, outcome, time range).
• Sort results (for example: by timestamp, severity, user, system, event category) without exporting to spreadsheets or manual parsing.
• Do this consistently across in-scope systems, not only for one log source.

Reference: NIST SP 800-53 Rev. 5 (NIST SP 800-53 Rev. 5); NIST SP 800-53 Rev. 5 DOI (NIST SP 800-53 Rev. 5 DOI).

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

AU-7(2) expects a working “audit evidence retrieval” capability. If an auditor asks, “Show me all privileged role grants in the last period,” you can answer by running a saved query, sorting the results, and exporting a report from your audit reporting system. You are not hunting through server directories, grepping raw files, or stitching results together manually.

A practical test: if your incident response lead can’t pull targeted audit records quickly during a live investigation, you probably don’t meet the spirit of AU-7(2), even if logs exist.

Who it applies to

Entities: Federal information systems and contractor systems handling federal data ¹ (NIST SP 800-53 Rev. 5 OSCAL JSON).

Operational context where AU-7(2) becomes “real”:

• SIEM/log analytics used for security monitoring and compliance evidence.
• Cloud logging (AWS CloudTrail/CloudWatch, Azure Monitor, Google Cloud Logging) feeding a central store.
• Managed security service providers where you still must demonstrate capability and access pathways.
• Regulated environments where audit evidence requests are time-bound (internal audit, external assessors, customer due diligence).

Systems typically in scope (define yours explicitly):

• Identity systems (SSO/IdP), privileged access management, directory services.
• Core applications handling federal data.
• Databases and data access layers.
• Administrative consoles and configuration management systems.
• Network/security tooling that generates audit-relevant events.

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

1) Assign ownership and write a control card (runbook-level)

Create a one-page “AU-7(2) control card” with:

• Owner: Security Operations (build) + GRC (oversight).
• In-scope log sources: list systems and what “audit record” means for each.
• Tooling: where logs are aggregated and searched.
• Execution triggers: audit request, incident, monthly control check.
• Exception rules: what happens when a source is down or fields are missing.

This addresses a common failure mode: “Teams cannot show who owns this requirement, how often it runs, or which evidence proves it is operating.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

2) Centralize audit records into a searchable platform

Pick the system of record for audit search and reporting (often your SIEM). Then:

• Ensure in-scope sources forward logs reliably.
• Confirm logs land with timestamps, source identifiers, and event categories.
• Set retention and access boundaries so the platform can act as audit evidence storage, not only monitoring.

You do not need every event from every system. You do need the events you claim you can retrieve, and you need them in one place where search and sort work.

3) Normalize and index fields so “automatic search” is real

Define a minimal schema for audit searchability. For each source, map native fields into a consistent set such as:

• event_time
• actor (user/service account)
• action (create/delete/modify/authenticate)
• object (role, group, record, configuration item)
• result (success/failure)
• system (hostname/app/environment)
• privileged (true/false where possible)

Then configure your platform to index those fields. If the data is only in unstructured message blobs, searches will be brittle and slow, and auditors will treat results as unreliable.

4) Build saved searches and sorting views for your top audit questions

Create a small “audit query library” and store it in a controlled location (SIEM saved searches + exported text definitions). Minimum set:

• Privileged access changes (role grants/revocations)
• Authentication anomalies (repeated failures, impossible travel if available, disabled account use)
• Administrative configuration changes (logging disabled, retention changes, IAM policy edits)
• Data access to sensitive repositories (read/export actions where logged)
• Log pipeline health (ingestion failures, agent offline, parsing errors)

Each search should have:

• Purpose
• Data sources
• Filters
• Sort order (usually descending time)
• Output fields included in the report

5) Lock down who can search, export, and change queries

AU-7(2) is a reporting requirement, but it sits in audit. If too many people can edit saved searches or delete logs, your evidence loses credibility.

• Restrict write access to parsers, indices, saved searches, and retention settings.
• Log access to the audit reporting platform itself (admin actions, query execution if supported).
• Require change management tickets for query logic changes that are used for compliance reporting.

6) Prove the capability with repeatable retrieval drills

Run a recurring “audit retrieval drill” where you:

• Receive a test request (for example: “all admin logins to production in a defined window”).
• Execute the saved search.
• Sort results.
• Export a report.
• Store the output and the query definition as evidence.

Tie this to control health checks and track remediation to closure (NIST SP 800-53 Rev. 5 OSCAL JSON).

Required evidence and artifacts to retain

Use an evidence bundle that an auditor can understand without a live tool demo:

Design evidence (static)

• AU-7(2) control card (owner, scope, cadence, tools, exceptions)
• Log source inventory with mapping to schema fields
• Role-based access matrix for the logging/SIEM platform
• Procedure for maintaining saved searches (change control)

Operating evidence (recurring)

• Screenshots or exports showing saved searches exist (names, last modified, owner)
• Sample query outputs (exported reports) with:
  • time range
  • filters
  • sort order visible
  • key fields included
• Retrieval drill records (request, execution steps, result location)
• Control health check tickets: ingestion failures, parsing fixes, missing sources, and closure proof

Retention evidence

• Where evidence is stored (GRC repository, ticketing system, secure file store)
• Retention settings for the audit reporting platform (policy/config extract where available)

Common exam/audit questions and hangups

Auditors and assessors tend to probe these areas:

1. “Show me” capability: Can you demonstrate search and sort live, or provide recent exports?
2. Field consistency: Are the same questions answerable across systems, or only for one platform?
3. Completeness of sources: Do your “in-scope” systems actually feed logs, end-to-end?
4. Access control: Who can alter queries, disable logging, or delete data?
5. Repeatability: Are queries documented and reusable, or dependent on one analyst?

Hangup to expect: teams confuse AU-7(2) with “we have a SIEM.” The requirement is about operational reporting capability, not tool ownership.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Better approach
Storing raw logs with no normalized fields	Searches become manual string matching; results are inconsistent	Define a minimal schema and map sources into it; index critical fields
Relying on ad hoc analyst knowledge	Knowledge walks out the door; cannot prove repeatability	Build a saved search library with owners and change control
No evidence of operation	You can demo once but cannot prove sustained control	Run retrieval drills and store outputs as evidence bundles
Too-broad admin access in SIEM/log platform	Audit evidence integrity becomes questionable	Enforce RBAC and log admin actions in the platform
Ignoring ingestion and parsing health	Searches return partial data; you won’t know	Monitor ingestion failures and treat them as control-impacting incidents

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AU-7(2) primarily as an assessment and contractual compliance risk driver in federal contexts (NIST SP 800-53 Rev. 5 OSCAL JSON). The practical risk is operational: if you cannot sort and search audit records reliably, you slow incident response, fail evidence requests, and increase the chance that material security events go uninvestigated or unprovable.

Practical execution plan (30/60/90-day)

Time-boxing helps, but exact timing depends on log source count, tooling maturity, and data quality. Use phases rather than promises.

First 30 days (Immediate)

• Publish the AU-7(2) control card: owner, scope, tools, evidence location.
• Identify in-scope systems and confirm which audit events you need from each.
• Choose the audit reporting system of record and document access roles.
• Draft the minimal searchable field list and confirm each source can populate it.

Days 31–60 (Near-term build)

• Onboard missing log sources and fix basic ingestion gaps.
• Implement parsing/field mapping for the minimal schema; index key fields.
• Create the first set of saved searches tied to real audit questions.
• Define evidence bundle templates in your GRC system (inputs, outputs, approvals, storage path).

Days 61–90 (Operationalize and prove)

• Run retrieval drills on a recurring cadence; store exports and query definitions.
• Add control health checks: ingestion monitoring, parser error review, access review for SIEM admins.
• Close gaps with tracked remediation (tickets, change records, validation notes).
• Prepare an “assessor packet”: control card, query library, sample exports, and a walk-through script.

Where Daydream fits (naturally)

If your issue is not tooling but repeatability and evidence, Daydream can store the AU-7(2) control card, standardize the evidence bundle, and track control health checks to closure. That keeps audit reporting capability from turning into a set of scattered screenshots across email and chat.

Frequently Asked Questions

Does AU-7(2) require a SIEM?

AU-7(2) requires an audit reporting capability that can automatically sort and search audit records (NIST SP 800-53 Rev. 5 OSCAL JSON). A SIEM is a common way to meet it, but a centralized log analytics platform can also work if it supports indexed search, sorting, and controlled reporting.

What does “automatic” mean in practice?

“Automatic” means the platform supports built-in searching and sorting without manual log parsing or custom one-off scripts per request. You should be able to run saved searches and produce consistent outputs on demand.

How do we scope which logs are “audit records” for AU-7(2)?

Define audit records as the event types you rely on for security monitoring, investigations, and compliance evidence for in-scope systems. Document the sources and events in your control card so you can defend why the scope is complete for your environment.

Can we meet AU-7(2) if some systems only produce unstructured logs?

Yes, but expect more audit friction. Map critical fields into a normalized schema where possible; where you cannot, document compensating query patterns and prioritize structured logging for high-risk sources.

What evidence is strongest for an assessor?

A small set of saved searches tied to common audit questions, plus recent exported reports showing filters and sort order, plus retrieval drill records. Pair those with RBAC evidence for the reporting platform and a clear owner/runbook.

How often should we test AU-7(2)?

Test on a recurring basis and after material changes (new systems, SIEM migrations, parser changes, logging policy changes). The goal is to prove the capability stays functional, not that it once worked during implementation.

Footnotes

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