AU-6(2): Automated Security Alerts

AU-6(2) requires you to generate automated security alerts from audit/log analysis so the right responders are notified fast, consistently, and with enough context to act. To operationalize it, define alert triggers, wire log sources into a monitoring stack, route alerts to an on-call function, and retain evidence that alerts fired and were handled per your process. ¹

Key takeaways:

• Treat AU-6(2) as an “automated detection + automated notification” requirement, not a policy statement. ¹
• Scope comes from your audit/log sources and “events of interest”; your control fails if critical systems are not feeding alerts. ²
• Audit readiness hinges on provable operation: alert rules, routing, test results, and incident/ticket trails that map alert → triage → outcome. ³

AU-6 is the NIST 800-53 audit review, analysis, and reporting control family. The (2) enhancement focuses on one practical expectation: your environment should not depend on humans manually reading logs to discover security-relevant events. Instead, your systems should detect defined conditions and automatically alert designated personnel or systems so investigation and response can start promptly. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to “operationalized” is to translate AU-6(2) into a small set of concrete decisions: (1) what events matter (use cases), (2) what telemetry supports those events (log sources), (3) what constitutes an alert (conditions and thresholds), (4) who gets notified and how (routing and escalation), and (5) what proof you retain (evidence bundle). Your audit narrative should read like a runbook, not like an abstract control statement. ²

This page gives requirement-level guidance you can hand to security operations and still audit against later: scope, roles, step-by-step implementation, evidence, and common examiner questions for AU-6(2): Automated Security Alerts. ³

Regulatory text

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

What the operator must do (how to read this in practice): Because the excerpt is provided at the control identifier level, you should implement AU-6(2) as a requirement that your audit/log analysis capability produces automated security alerts when defined security-relevant conditions occur, and that those alerts are delivered to appropriate personnel/systems through a managed notification path. Your control design should show: defined triggers, automated detection, automated notification, and operational follow-through (triage/response), backed by retained evidence. ²

Plain-English interpretation (requirement intent)

AU-6(2) expects you to:

• Detect security-relevant events from audit/log data without manual log reading.
• Notify the right people automatically (or a response system that pages people) with enough context to make a decision.
• Operate it continuously: alerts should fire, route, and get handled; you should be able to prove this happened. ¹

A clean mental model: AU-6(2) is the bridge between “we collect logs” and “we respond to what logs tell us.” If you have log retention but no reliable alerting, AU-6(2) will be hard to defend. ²

Who it applies to (entity + operational context)

AU-6(2) commonly applies to:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data (for example, in regulated federal contracting contexts where NIST 800-53 is the baseline or inherited requirement set). ²

Operationally, it applies wherever you have:

• Centralized logging (or a plan to centralize it)
• A monitoring function (SOC, on-call security, SRE with security duty)
• Production systems where authentication, authorization, admin activity, endpoint/network telemetry, and key application events can be logged and analyzed ³

Third-party reality: if key telemetry comes from a third party (cloud provider logs, managed SIEM, MDR, IDP), AU-6(2) still lands on you. You can delegate operations, but you must retain evidence and assurance that automated alerting exists and works for your defined use cases. ²

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

Step 1: Create a control card for AU-6(2)

Write a one-page “control card” your operators can execute:

• Objective: automated security alerts are generated from audit/log analysis for defined events
• Owner: named role (SOC lead, SecOps manager)
• In-scope systems: log sources list (see Step 2)
• Trigger events: your alert use cases (see Step 3)
• Execution steps: how alerts are created, routed, triaged, and closed
• Exceptions: when alerting is not feasible and what compensating control exists
• Cadence: how you validate alerting health (see Step 7) ¹

If you use Daydream, store the AU-6(2) control card alongside your evidence bundle requirements so audits do not depend on tribal knowledge.

Step 2: Define minimum log sources (your “can we even alert?” checklist)

Build a scoped list of telemetry sources that can produce security alerts. Keep it short but defensible:

• Identity provider (sign-in and admin changes)
• Privileged access management or admin consoles
• Endpoint detection/AV (if used)
• Network/security devices (firewall, WAF, DNS security, proxy, VPN)
• Cloud control plane logs (for example, API calls and IAM changes)
• Key application audit logs (admin actions, auth events, data export actions)
• CI/CD and secrets tooling logs (if they can affect production) ²

Deliverable: a “log source inventory” table with columns: source, owner, ingestion method, parsing status, retention location, and whether it is alert-enabled.

Step 3: Define alert use cases and triggers

Write alert requirements as short “if/then” statements, not generic categories. Examples:

• If a privileged role is assigned, alert security on-call.
• If MFA is disabled for an admin, alert security on-call.
• If repeated authentication failures exceed your defined threshold, alert service owner and security.
• If audit logging is disabled or log ingestion stops, alert the platform/on-call team. ²

For each use case, document:

• Data source(s)
• Detection logic (rule or query)
• Severity and priority
• Notification target(s)
• Expected responder action (triage steps)
• Link to an incident playbook (or a short inline runbook)

Step 4: Implement automated detection in a monitoring stack

Technically, AU-6(2) is satisfied by any reliable pipeline that can:

1. ingest logs, 2) analyze against rules, 3) generate alerts automatically. Common patterns:

• SIEM with correlation rules
• Cloud-native monitoring + security hub alerts
• EDR-managed alerting
• MDR provider generating alerts from your telemetry ²

Your job as GRC lead: require security engineering to map each alert use case to an implemented rule and show where it lives (rule name/ID, repository link, change control reference).

Step 5: Implement automated notification, routing, and escalation

Alerting fails in practice when the notification path is informal. Define:

• Primary channel (paging, ticketing, SOC console)
• Backup channel (email is fine as a secondary)
• On-call rota ownership (who receives after-hours)
• Escalation timing rules (what happens if unacknowledged)
• Required alert payload fields (system, time, actor, action, correlation ID, link to raw logs) ²

If your SOC is a third party, require contractual clarity on alert delivery, SLAs, and evidence access. Treat it as third-party due diligence: you need proof, not promises.

Step 6: Tie alerts to case management and documented outcomes

You need a closed loop:

• Alert → ticket/incident → triage notes → disposition (true positive/benign/false positive) → remediation or tuning change.
• Ensure tickets are searchable and retainable for audit. ³

A practical control test: pick an alert type and show the full chain for a recent example, including timestamps and who acted.

Step 7: Prove the control works (control health checks)

Set a recurring health check that answers:

• Are log sources still ingesting?
• Are alert rules enabled?
• Did paging/ticket integrations break?
• Are responders acknowledging and closing alerts?
• Are high-noise alerts being tuned with change control? ¹

Retain outputs from health checks as part of your evidence bundle.

Required evidence and artifacts to retain

Auditors rarely fail you for missing technology; they fail you for missing proof. Build a minimum AU-6(2) evidence bundle:

Design evidence

• AU-6(2) control card (owner, scope, triggers, workflow)
• Log source inventory with in-scope designation
• Alert use case catalog (rules list) mapped to sources and responders
• Alert routing diagram (SIEM/monitoring → paging/ticketing → on-call) ²

Operating evidence

• Screenshots/exports showing alert rules enabled (with rule IDs and last modified)
• Sample alerts (redacted) showing payload + timestamp + destination
• Ticket/incident records showing triage and closure
• Health check results and remediation tracking to closure ¹

Change control evidence

• Approved changes for rule tuning (noise reduction, threshold updates)
• Exceptions register for systems that cannot emit required logs, with compensating measures ³

Common exam/audit questions and hangups

Expect these, and pre-answer them in your control narrative:

1. “Which events generate automated alerts?” Provide the use case catalog and rule mapping. ²
2. “How do you know alerts are delivered and acted on?” Show ticket linkage and acknowledgment/closure trail. ²
3. “What happens if logging stops?” Show ingestion-gap alerting and responder runbook. ²
4. “Who owns this control and reviews effectiveness?” Show named owner and health check cadence plus results. ¹
5. “How do you handle third-party monitoring?” Show contracts/SLAs, alert examples, and access to evidence. ²

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AU-6(2) in practice	What to do instead
“We have logs in S3/Splunk, so we’re compliant.”	Log collection without automated alerting does not create notifications.	Build explicit alert rules tied to use cases and route to on-call. 2
Alerts exist but route to a dead inbox or shared channel	No accountable acknowledgment and escalation.	Use paging/ticketing with on-call ownership and escalation rules. 2
No evidence retained	You can’t prove operation or timeliness.	Store sample alerts, tickets, health checks, and rule inventories in a controlled repository. 3
Alert noise overwhelms responders	Responders ignore alerts, breaking the response loop.	Treat tuning as controlled change with documented rationale and testing. 2
Scope gaps: critical systems not emitting telemetry	High-impact events never trigger alerts.	Maintain a log source inventory and require onboarding for new systems. 2

Enforcement context and risk implications

No public enforcement case references were provided for this requirement in the supplied source catalog. Practically, AU-6(2) gaps tend to surface during incident response, customer due diligence, and independent assessments because “no automated alerting” correlates with delayed detection and incomplete incident narratives. Keep your risk statement precise: the control reduces the risk of delayed identification of security-relevant activity and supports timely response. ²

A practical 30/60/90-day execution plan

First 30 days (establish control ownership + minimum viable alerting)

• Assign AU-6(2) owner and publish the control card (scope, triggers, workflow). ¹
• Build the log source inventory for your highest-risk systems first (identity, cloud control plane, endpoints if applicable). ²
• Define a first-pass alert use case catalog with clear responders and routing.
• Stand up ticketing integration for alerts, even if rules are basic.

Days 31–60 (expand coverage + evidence discipline)

• Map each use case to an implemented rule/query and document rule IDs and locations.
• Implement ingestion failure alerts and validate notification paths end-to-end.
• Start retaining the AU-6(2) evidence bundle in one repository with consistent naming.
• Run a tabletop test: generate test events to confirm alerts fire and create tickets. ²

Days 61–90 (operational maturity + audit-ready proof)

• Add tuning workflow (noise reduction) with change approvals and rollback steps.
• Implement recurring control health checks and track remediation items to closure. ¹
• Review third-party dependencies (MDR/SIEM providers) and confirm you can export alerts and case records for audit.
• Prepare an “audit walkthrough” packet: one alert type traced from detection to closure with redactions. ³

If you need speed, Daydream can act as the system of record for the control card, the minimum evidence bundle definition, and recurring health check attestations, so you can demonstrate sustained operation without rebuilding proof during audits.

Frequently Asked Questions

Does AU-6(2) require a SIEM?

No specific technology is mandated in the provided control excerpt, but you must achieve automated alert generation and automated notification from audit/log analysis. A SIEM is one common way to do that. ¹

What counts as an “automated security alert” for audit purposes?

An alert that is generated by system logic (rule/query/correlation) and automatically delivered to responders or a response system (paging or tickets). You should be able to show a sample alert and the resulting triage record. ²

How do we handle AU-6(2) if a third party runs our monitoring (MDR/SOC)?

Treat the third party as operating part of your control. Require evidence access (alert exports, case records) and document routing, escalation, and ownership so you can prove operation without relying on verbal confirmation. ²

Do we need 24/7 on-call coverage to satisfy AU-6(2)?

NIST SP 800-53 control AU-6.2 is provided here at the identifier level and does not specify hours of coverage. Document your routing and escalation model, align it to your risk, and prove that alerts reach accountable responders during your defined coverage windows. ²

What evidence is most persuasive to an auditor for AU-6(2)?

A rule inventory mapped to use cases, a redacted sample of alert notifications, and tickets/incidents showing acknowledgment, investigation notes, and closure. Add health check records to prove the control stays operational over time. ³

How do we prevent alert fatigue without weakening compliance?

Use a controlled tuning process: document why a rule changed, what impact is expected, and validate the rule still detects the intended condition. Keep the change record and test output as evidence. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5 DOI