Skip to content
ControlVerdict
Sign in
AU.L2-3.3.4CMMC Level 2Level 2

Audit Failure Alerting

Submit your own example

Practice statement

Alert in the event of an audit logging process failure.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.3.4.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(3)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    personnel or roles to be alerted in the event of an audit logging process failure are identified;

    1 example covers this

  2. [b]

    types of audit logging process failures for which alert will be generated are defined; and

    1 example covers this

  3. [c]

    identified personnel or roles are alerted in the event of an audit logging process failure.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    AU.L2-3.3.4Audit Failure Alerting
    Alert in the event of an audit logging process failure.

    • [a]

      personnel or roles to be alerted in the event of an audit logging process failure are identified;

    • [b]

      types of audit logging process failures for which alert will be generated are defined; and

    • [c]

      identified personnel or roles are alerted in the event of an audit logging process failure.

    Logging failures page the on-call instead of landing in an unread inbox

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses all three Audit Failure Alerting objectives: who is alerted, which failure types generate an alert, and that the alert actually reaches those people.

    Who is alerted [a]. Primary is the security on-call rotation; secondary escalation after 30 minutes is the infrastructure lead. The enclave owner is notified for any failure lasting more than four hours. These roles are named in the runbook, not left as a distribution list nobody owns.

    Defined failure types [b]. Agent or forwarder process stopped or unreachable for more than 15 minutes; local spool disk above 80% or spool age beyond one hour; ingest rejected for quota or license reasons; connector credential or certificate expiry; clock skew beyond tolerance on a collector; archive write failure; and expected-source silence for more than 24 hours.

    Delivery [c]. Alerts go to the paging service, not email, because the two silent failures we had were both sitting in an inbox. Each alert carries the affected source and the runbook link. Paging is exercised by a monthly synthetic failure — the agent is deliberately stopped on one test host and the page must land within the SLA.

    Local resilience. Forwarders spool to local disk when the upstream is unreachable and drain on recovery, so a short outage is a delay rather than a gap. Spool depth is itself a monitored signal.

    Maintenance. Monthly synthetic failure test with the page timestamp recorded. Quarterly review of alert volume to keep the rotation from tuning the alert out. Patch runbooks include a post-patch confirmation that each forwarder resumed sending.

    Accepted gap. One SaaS source gives no failure signal of its own; we can only detect that its events stopped arriving. Detection there is the 24-hour silence rule, so the worst-case blind window is a day. Documented on the exception register.

    What the evidence looks like

    • Runbook naming the alerted roles and the escalation path
    • Alert rule definitions for each defined failure type
    • Paging service configuration and a monthly synthetic-failure page record
    • Ticket from the last real forwarder failure showing detection and recovery times
    • Spool configuration showing local buffering and drain behavior

    Environment

    Log pipeline with an on-prem forwarder tier feeding a cloud analytics workspace. The forwarders failed silently twice during patch windows before this was built.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.