AU-6(2): Automated Security Alerts

AU-6(2) requires you to generate automated security alerts from audit record review and analysis, route them to the right responders, and prove the alerts are working in day-to-day operations. Operationalize it by defining alert triggers, integrating log sources into a SIEM (or equivalent), establishing response workflows, and retaining repeatable evidence of alerting, triage, and tuning. ¹

Key takeaways:

• Define what events must alert, who receives alerts, and what “actionable” means for your environment. ¹
• Implement automated alert generation from audited events, then connect alerts to an on-call/incident workflow with documented handling steps. ²
• Keep recurring evidence: alert rules, routing, test results, and real alert tickets showing triage and disposition. ²

AU-6(2): Automated Security Alerts is an “audit and accountability” requirement that often fails in practice for a simple reason: teams collect logs but do not reliably convert them into timely, routed, actionable alerts. For a Compliance Officer, CCO, or GRC lead, the goal is not to design a perfect detection program. The goal is to meet the requirement with a defensible, testable implementation that consistently produces security-relevant alerts from audited activity and proves those alerts reach the right people.

This page focuses on how to implement AU-6(2) at requirement level: scope, minimum operating model, step-by-step execution, and the evidence package auditors and assessors expect. You will also see common hangups (for example, “We have a SIEM but no one owns alert tuning”), frequent mistakes (alert floods, missing routing, no tests), and a pragmatic 30/60/90 execution plan you can assign to control owners. References are limited to the NIST SP 800-53 Rev. 5 source material provided. ³

Regulatory text

Control excerpt: “NIST SP 800-53 control AU-6.2.” ¹

What the operator must do: Implement automated alerting tied to audit record review/analysis so that defined security-significant events generate alerts without manual effort, and those alerts are delivered to personnel or roles that can respond. Then, operate the capability consistently and retain evidence that it works (alert logic, routing, and response records). ³

Plain-English interpretation (what AU-6(2) is asking for)

AU-6(2): automated security alerts requirement means your logging program must do more than store logs for later review. Your environment must automatically detect certain audit events or patterns (based on your defined criteria) and raise an alert that reaches a responder in time to act.

A compliant implementation usually has:

• Defined alert conditions tied to audited events (authentication anomalies, privilege changes, audit log tampering indicators, high-risk administrative actions).
• Automated detection and alerting through a SIEM, XDR, cloud-native monitoring, or an equivalent platform.
• Alert routing to an on-call queue, SOC, security operations mailbox, ticketing system, or incident response channel with clear ownership.
• Triage and disposition workflow (acknowledge, investigate, close as benign, or escalate to an incident).
• Ongoing tuning and testing to keep alerts actionable and reduce missed detections and alert fatigue. ²

Who it applies to (entity and operational context)

AU-6(2) commonly applies when you run:

• Federal information systems that must align to NIST SP 800-53 baselines. ²
• Contractor systems handling federal data, including systems operated by third parties where you remain accountable for meeting control expectations through shared responsibility and contract terms. ²

Operationally, it applies anywhere you generate audit records: identity platforms, endpoints, servers, network/security devices, cloud control planes, and key business applications. If the system can produce audit events that indicate compromise or policy violation, AU-6(2) expects automated alerting on the events you designate as security-significant. ²

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

1) Assign ownership and define scope

• Name a control owner (often Security Operations) and a GRC owner accountable for evidence quality.
• Create a scoped system list (in-scope environments and log sources).
• Decide what “security alert” means in your environment (SIEM correlation alert, EDR detection, cloud security finding, etc.). ²

Practical decision: If you have multiple tools, pick one system of record for alerts (or define how you reconcile them) so you can prove end-to-end operation during assessment. ²

2) Define alert triggers (detection requirements)

Document a short list of required alert categories tied to audited events, such as:

• Authentication and access anomalies (e.g., repeated failures, impossible travel signals if available).
• Privileged role or group membership changes.
• Creation of new admin accounts or API keys.
• Changes to logging configuration or audit policy.
• Indicators of audit log tampering or collection failure.

You are not required to detect everything. You are required to define what matters for your risk posture and ensure alerts are automated and actionable. Write the triggers in “auditable” language: event source → event pattern → severity → owner → expected response. ²

3) Implement automated alert generation

• Centralize required audit data into your monitoring platform (SIEM or equivalent).
• Build alert rules/correlation searches for the defined triggers.
• Tag each rule with: severity, mapping to AU-6(2), and runbook link (ticket template or SOP reference).
• Configure alert suppression or deduplication where needed to prevent floods, but document the logic. ²

Example (implementation pattern):

• Source: Identity provider audit logs
• Rule: Privileged role assigned outside approved workflow
• Alert: High severity; notify SOC queue; create ticket; page on-call if after hours
• Response: Validate change request; if unauthorized, disable account and open incident ²

4) Route alerts to responders with an SLA-like expectation

Define routing that matches how your org works:

• SOC tool queue, ticketing system, email distribution, chat channel, and on-call paging.
• Primary and backup roles (to avoid “alert goes to a mailbox nobody monitors”).

Document expected handling steps and time expectations as internal targets (you do not need a sourced metric; you need consistency and evidence). ²

5) Establish triage, escalation, and closure criteria

Create a one-page SOP (or runbook) that tells analysts and on-call staff:

• What data to check first (host, user, IP, change record).
• When to escalate to incident response.
• How to record disposition (true positive, benign, false positive, needs tuning).
• When to tune the rule and who approves changes. ²

6) Test and tune on a schedule you can prove

You need evidence that alerts work end-to-end:

• Perform controlled tests (for example, a non-production admin change that should fire an alert).
• Track false positives and tune rules.
• Validate alert delivery (paging/ticket creation) after tool upgrades or configuration changes.

A simple test log with date, tester, trigger, expected result, actual result, and ticket link is usually enough if you run it consistently. ²

7) Map AU-6(2) to control owner, procedure, and recurring evidence

This is the fastest way to avoid “we do it but can’t prove it” findings:

• Control statement
• Owner and operators
• Tools in scope
• Evidence produced monthly/quarterly (alerts, tickets, test records)
• Exceptions process

Daydream can help here by turning AU-6(2) into an assignable control with an evidence checklist and recurring collection prompts, so audit readiness does not depend on tribal knowledge. ¹

Required evidence and artifacts to retain

Keep evidence that proves design and operating effectiveness:

Design evidence

• AU-6(2) control narrative (what alerts exist, where they run, who responds). ²
• Alert catalog: list of alert rules with descriptions, severity, and owners.
• Data flow diagram or written description of log sources → SIEM → alerting → ticketing/on-call.

Operating evidence

• Samples of alerts generated (screenshots or exports) showing timestamps, rule names, and affected assets.
• Ticket/incident records showing triage steps and disposition.
• Alert test records (planned tests and outcomes).
• Change management records for alert rule updates (what changed, who approved, when). ²

Audit-ready packaging tip: Store evidence by period (for example, “Alert Samples – Qx”) and by alert type so an assessor can trace from requirement → rule → alert instance → response. ²

Common exam/audit questions and hangups

Assessors often probe these points:

• “Show me the alerts.” They will ask for live examples and how they were handled. Have tickets ready. ²
• “How do you know alerts are automated?” If an analyst manually reviews a dashboard once a day, that is review, not automated alerting.
• “Who is on point after hours?” Routing must work outside business hours if your risk profile requires it; if not, document the rationale and compensating controls. ²
• “What happens when logging breaks?” Collection failures should themselves generate alerts, or you need a documented alternative monitoring approach.

Frequent implementation mistakes (and how to avoid them)

1. Alert floods with no tuning loop
   Fix: Track dispositions and create a tuning backlog with an owner and approval path. ²

2. Routing to a shared inbox nobody monitors
   Fix: Route to a ticket queue with named on-call coverage and escalation rules.

3. Rules exist but are undocumented
   Fix: Maintain an alert catalog with rule intent, data source, and runbook references. ²

4. No proof of end-to-end operation
   Fix: Run periodic tests and retain results, plus real alert/ticket samples.

5. Third-party hosted systems treated as “out of scope”
   Fix: Include alerting obligations in third-party contracts and confirm their alerting outputs integrate with your response process, or document shared responsibility boundaries. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list enforcement examples.

Risk-wise, AU-6(2) failures typically show up as delayed detection and poor incident response outcomes. Operationally, a program that “logs everything” but does not alert on high-risk events increases dwell time and weakens accountability during investigations because no one can show who saw what, when, and what they did next. ²

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Assign AU-6(2) control owner and document scope (systems and log sources). ²
• Define an initial list of security-significant alert triggers tied to audited events.
• Confirm tooling: where alerts will be generated and where tickets will be tracked.
• Publish one AU-6(2) procedure/runbook covering triage and escalation.
• Produce first evidence packet: alert catalog + a small set of alert examples + routing configuration screenshots. ²

Days 31–60 (make it reliable and auditable)

• Expand coverage to remaining in-scope log sources.
• Implement alert deduplication/suppression rules with documentation.
• Add controlled alert tests and log the results.
• Start a tuning cadence: review top noisy alerts, tune thresholds, and document changes. ²

Days 61–90 (operational maturity and assessment readiness)

• Validate after-hours routing and escalation.
• Tie alert severities to incident response thresholds (what becomes an incident vs. an investigation).
• Run a tabletop or simulated alert-to-ticket workflow and retain artifacts (ticket trail, analyst notes).
• Move evidence collection into a recurring GRC workflow (Daydream or your existing GRC system) so the control stays current between assessments. ²

Frequently Asked Questions

Do we need a SIEM to meet the au-6(2): automated security alerts requirement?

No specific tool is mandated, but you need automated alert generation from audited events plus reliable routing and response evidence. A SIEM is a common implementation pattern because it centralizes logs and correlation. ²

Are manual daily log reviews enough for AU-6(2)?

Manual review supports audit analysis, but AU-6(2) is about automated alerts. If a critical event depends on a person noticing it later, you will struggle to show compliance with “automated security alerts.” ²

What’s the minimum evidence an auditor will accept?

Expect to provide an alert catalog (rules, owners, routing), samples of real alerts, and corresponding tickets showing triage and disposition. Add test records that prove alerts still work after changes. ²

How do we handle third-party systems that generate their own alerts?

Define shared responsibility in the contract and ensure alerts reach your responders or your designated third party monitors them under an agreed workflow. Retain evidence of alert delivery and handling, not just the third party’s marketing statement. ²

What if we suppress noisy alerts—does that violate AU-6(2)?

Suppression is acceptable if it is documented, approved, and reviewed so you do not miss high-risk events. Keep the suppression logic and tuning history as part of your evidence package. ²

How do we map AU-6(2) into our GRC program without creating busywork?

Treat it as a recurring evidence control: assign an owner, define which artifacts appear every period, and automate reminders and collection. Daydream helps by tracking the procedure, owners, and repeatable evidence artifacts in one place. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5

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