AU.L2-3.3.4 Audit failure alerting: requirements and evidence

What AU.L2-3.3.4 audit failure alerting requires for CMMC Level 2

A defense contractor can have audit logging switched on across every system that handles CUI and still have no idea when that logging stops. A collector service crashes, a disk fills, a forwarder loses its connection, and the logs simply stop arriving. AU.L2-3.3.4 exists for that situation. It requires the organization to alert designated people or roles when an audit logging process fails, so a gap in the record is noticed and fixed rather than discovered months later during an investigation or an assessment. The requirement is the CMMC Level 2 version of requirement 3.3.4 in NIST SP 800-171 Rev. 2, a derived requirement in the Audit and Accountability family, and it is worth 1 point in the CMMC scoring model. The low point value understates the risk. A silent logging failure means that unauthorized activity during the outage leaves no trace, which undermines the other audit requirements that depend on complete records.

Most of the difficulty sits in two decisions the organization has to make and write down. The first is which failure types count: a stopped log source, a full storage volume, a failed forwarder, a rejected write, a time source that drifts, or a logging agent that is removed from a host. NIST SP 800-171A breaks 3.3.4 into three assessment objectives: identifying who is alerted, defining the types of audit logging failures that trigger an alert, and alerting those people or roles when a failure occurs. The second decision is who receives the alert. Designated security personnel, such as the system administrator and security officer, are the roles the CMMC Assessment Guide Level 2 names, and the list must be specific enough that an assessor can trace it to named roles. Many organizations skip both decisions and rely on whatever default alerting their tooling provides, which leaves the assessor with no defined failure list to test against.

Before you plan the technical work, confirm three things with your assessor's expectations and your own documentation: the written list of failure types, the named roles or distribution lists that receive each alert, and the procedure that says what happens after an alert fires. Then run a deliberate test. Stop a log forwarder on a non-production host and confirm that the alert reaches the listed recipients through the channel you documented, such as email or SMS. Keep the incident record, the notification output and the follow-up ticket, since these are the artifacts that show the mechanism works. Because the evidence must be in final form to count, avoid leaving the failure list in draft. Finally, if you cannot meet this requirement on the day of an assessment, understand that AU.L2-3.3.4 is a 1-point requirement that may be eligible for a plan of action under the scoring rules, so treat that as a fallback to confirm with your assessor rather than a plan.

Which systems and teams are in scope for audit failure alerting

AU.L2-3.3.4 applies wherever CUI-handling systems produce audit records, so scoping starts with the systems inside the boundary and then follows their logs through every pipeline stage. Each card below is a decision that changes who must be alerted, what counts as a failure and how the alert is evidenced.

Systems that generate audit records

Start with every asset inside the CUI boundary that writes audit records: servers, endpoints, identity providers, firewalls, databases, business applications and cloud control planes. Each source can fail in its own way, such as a disabled audit policy or a full local log volume, so each one needs a defined failure type. Confirm the list against the system security plan and the audit logging configuration described under AU.L2-3.3.1, not against memory.

Collection and forwarding agents

Agents and forwarders such as log shippers, endpoint agents and syslog relays are the most common point where logging silently stops. An alert should fire when an expected source goes quiet, not only when a source reports an error. Record which agents run on which hosts, who owns each one and how a stopped agent is detected.

Indexers, SIEM and storage

Central indexers, SIEM platforms and log storage can fail through disk exhaustion, ingestion backlogs, certificate expiry or index errors, and those failures can leave every upstream source looking healthy. Scope the central tier as its own component with its own alert conditions. Ask the platform owner which health and ingestion metrics the tool exposes and whether they can be routed to a notification channel.

Named recipients and on-call roles

The CMMC Assessment Guide expects designated security personnel, such as the system administrator and security officer, to learn when audit logging fails, for example by email or SMS. Decide which named roles receive each alert type, document the escalation path when a recipient is unavailable, and confirm that the list is current. Assessors typically compare the list in the procedure with the people who actually received alerts.

Third-party and cloud-hosted logging services

Where a managed logging service, cloud-native audit trail or outsourced SOC stores or processes audit records, the failure alert may depend on the provider's status signals. Confirm with the organization's contracts and provider documentation whether the provider notifies you of ingestion failures, what it commits to, and whether those records fall inside the CUI boundary. Treat this as an open scoping question until it is answered in writing.

How an assessor tests audit failure alerting

This table compares the three SP 800-171A assessment objectives for AU.L2-3.3.4 against what the assessor does, the evidence requested and the findings that most often cause a requirement to fall short. Read each row as a question the assessor asks, then check whether your environment can answer it with final-form evidence.

Assessment objective	What the assessor tests	Evidence the assessor requests	Common finding
Identify who is alerted	Whether the organization has named the personnel or roles that receive audit logging failure alerts, such as the system administrator or security officer.	A current list of notified personnel or roles, the procedure that names them, and confirmation that the list matches the people on the alert distribution.	Alert recipients are a shared mailbox or a former employee, or no list exists at all.
Define failure types that trigger an alert	Whether the organization has defined which audit logging failures produce an alert, such as a stopped log source, a full log storage volume, or a collection agent that goes silent.	A written procedure for responding to audit logging failures that lists the failure types, plus configuration showing which conditions raise alerts.	Failure types are implied rather than written down, so the alert rules cover only some failures.
Alert those people when a failure occurs	Whether the defined alert mechanism actually reaches the named recipients when a defined failure happens, and whether the organization acts on it.	Alert test records (for example, a deliberately stopped log source and the resulting notification), incident reports or tickets from real failures, and audit records showing the event.	Alerts were configured but never tested, or a test was run once years ago and the mechanism has changed since.

How to implement audit failure alerting step by step

This sequence turns AU.L2-3.3.4 from a policy statement into a working alert path: every log source is known, every failure type that matters has a named recipient, and each alert has been triggered and recorded so an assessor can see it work.

Inventory log sources and pipelines
List every system that generates audit records in scope for CUI, including endpoints, servers, network devices, cloud services and any SIEM or log collector that moves records between them. For each source, record the logging agent or native feature, where records are sent, and who administers it. The output is a current log source inventory signed off by the system owner, and it becomes the boundary for every later step. Confirm the inventory against the system security plan so no in-scope component is left out.
Define the audit failure types to detect
Work through each pipeline stage and write down the ways it can fail: an agent or service stops, a host or forwarder becomes unreachable, a disk or index fills, storage returns write errors, or log ingestion falls behind. Give each failure type a short definition and a detection signal, such as a missing heartbeat or a drop in event volume. SP 800-171A treats defining the failure types as its own assessment objective, so the list should be written down and approved, not left in an engineer's head. The output is a failure type register with one row per type.
Name alert recipients by role
Identify the people or roles who must learn about each failure type, typically the system administrator for the affected platform and the security officer for the program. Use role names with named backups, and record how each role is reached during working and off hours. The CMMC Assessment Guide Level 2 gives system administrators and security officers as examples of designated personnel, so match your roles to your actual organization chart. The output is a recipient list mapped to failure types, reviewed whenever staff change.
Configure alert mechanisms and rules
Build the detection and notification path for each failure type. Depending on the stack, this can be a detector or rule in a log analytics platform, a threshold alert in a metrics system, or a health check that feeds an alerting engine. Route notifications to the recipients from the previous step through email, SMS or a chat channel, and confirm the alert text names the source system and failure type. Open-source options such as OpenSearch Security Analytics, Wazuh and Grafana Alerting can all send alerts to email or chat channels, but confirm which channels and delivery guarantees your chosen version supports. The output is exported configuration and a screenshot or record of each rule.
Write the response procedure
Document what each recipient does when an alert fires: who acknowledges it, how the gap in logging is contained, how the source is restored, how the time window without logs is assessed, and when the event is escalated to incident response. Link the procedure to the incident response process so a logging failure can be tracked as an incident where appropriate. SP 800-171A lists procedures for responding to audit logging failures as an assessment object, so the document must exist, be approved and match what staff actually do. The output is an approved response procedure with a version and owner.
Test each failure alert
Trigger each failure type on purpose in a non-production or agreed maintenance window: stop an agent, disconnect a forwarder, fill a test volume, and block a write path. Confirm that the alert fires, reaches every named recipient, and that the recipient follows the response procedure. Record the time of each injected failure, the time of each alert, and any alert that did not arrive. Treat missed or late alerts as defects, fix them, and retest. The output is a dated test record for every failure type, with pass or fail results and remediation notes.
Record outputs and keep evidence current
Collect the artifacts from every step into one evidence folder: the inventory, failure register, recipient list, rule exports, approved procedure, test records and a sample of real alerts with their follow-up tickets. Assessors look for evidence in final form, so store approved versions with dates and owners rather than drafts. Set a review trigger for changes to log sources, recipients or tooling, and rerun the relevant tests after each change. The output is an assessment-ready evidence package that shows the alert path works and is maintained.

How logging failures become alerts in practice

Two different alerts do the work of AU.L2-3.3.4, and teams often build only one of them. The first is an alert that a log source has stopped sending. A firewall, domain controller or cloud audit feed that goes quiet produces no events, so no detection rule can fire on it. The alert has to come from watching the pipeline itself: whether each expected source has reported within a window the organization has chosen. The second is a detection rule that fires on a log event, such as repeated failed logons or a change to audit settings. That rule tells you something happened on a monitored system. It says nothing about whether the monitoring is still working. Assessors will ask for both, because a logging failure is a gap in what you can see, and a silent source looks exactly like a quiet network.

Pipeline health monitoring watches the path between the source and the analyst. In practice this means tracking indicators such as the number of events received per source over time, the age of the newest event from each source, the depth of any queue or buffer between collectors and storage, and whether the collectors, forwarders and storage nodes themselves are up and writing. Prometheus-style metrics, which are collected over HTTP and stored as time series, are one common way to capture these numbers, and Grafana alert rules can evaluate them across data sources. Detection rules, by contrast, run against the content of events. The two are complementary. Health alerts are the ones that catch a stopped or backed-up pipeline, and detection alerts are the ones that catch suspicious activity once logs arrive. Confirm with your platform team which health signals each product exposes before you write the alert design, because the available metrics vary by component.

Before you configure anything, make three decisions and record them. List the log sources that must report, and set a silence threshold for each based on how often it normally produces events. Decide which failure types trigger an alert, such as a source going silent, a collector error, a full queue or a storage write failure. Then name the people or roles who receive each alert and the channel they use, such as email, SMS or a chat channel. Your evidence for the assessment is the rule definitions, the notification routing, a sample alert with its time stamp and recipient, and the record of how the team responded. Test the chain by deliberately stopping a non-production source and confirming the alert arrives at the named recipients, then keep that test result as evidence.

Evidence that passes an audit failure alerting review

An assessor testing AU.L2-3.3.4 needs to see who is alerted, what counts as a failure, and proof that an alert actually reached those people. The cards below cover the documents, configuration records and test results that show this chain works. Every item should be in final form and refreshed before each assessment.

Documented logging failure procedure

This is the written procedure that says what happens when audit logging fails: who is notified, how fast they must act, and who checks that the gap was closed. Assessors use it as the reference point for the other evidence, so each later artifact should match what it describes. Check that the procedure names the roles that receive alerts and that it has an approval date and owner. A draft or an unsigned version will not carry weight on its own.

Current recipient list by role

This list names the roles, such as the system administrator and security officer, that must learn when audit logging fails, along with the notification channel for each. Roles are preferred over named individuals so the list survives staff changes, though each role should still map to a current person. Check that the list matches the alert routing in your tools. A list that names someone who left the organization is a visible gap.

Failure type definitions

Define the specific audit logging failures that trigger an alert, such as a logging service stopping, a log source going silent, disk space running out on the log store, or log forwarding breaking. An assessor tests whether the organization has defined these types at all, so a vague statement that failures will be alerted is not enough. Keep the definitions tied to your actual log sources and review them when you add a system.

Alert configuration exports

Export the current settings from the tools that generate failure alerts, including monitor or rule definitions, notification channels and recipient mappings. In a Wazuh deployment this may mean exported rules and integration settings, and in Grafana Alerting it may mean exported alert rule definitions and contact points. The export should show the failure conditions from your definitions, so a reviewer can trace each type to a working rule. Confirm the export reflects the production configuration, not a test copy.

Sample alert notifications with timestamps

Keep copies of real alert notifications sent to recipients, such as emails, SMS messages or chat messages, with their timestamps and the source system named. These show that alerts left the platform and reached a person or role during normal operation. Store them with the recipient list so a reviewer can match each notification to a designated role. Redact sensitive content, but keep the timestamp and routing information intact.

Test records of simulated failures

Record controlled tests in which a logging failure is deliberately triggered, such as stopping a log forwarder on a test host, and then record the alert that resulted. The record should state the test date, the failure type, the expected recipient, the time the alert arrived and who verified it. Assessors look for evidence that the mechanism works, not just that it was configured. Repeat the test after significant changes to the logging pipeline.

Incident tickets created from alerts

Keep the tickets, cases or records that show an alert was acted on: who picked it up, what the root cause was, and when logging was restored. Linking each ticket back to the originating alert shows that the notification led to a fix rather than being ignored. Include tickets from real failures and note any that were closed without a fix, with the reason. Tickets also support the incident response evidence assessors review alongside this requirement.

What meeting AU.L2-3.3.4 costs in money and effort

This table breaks down the cost and effort components of meeting AU.L2-3.3.4, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are stated because none were supplied; use the drivers to build a written scope and request quotes against it.

Cost component	One-time or recurring	Who is paid or who does the work	What drives it up or down
Alerting platform licenses	Recurring if commercial	Software vendor; often avoided with self-hosted open source such as OpenSearch, Wazuh or Grafana, which carry their own open-source licenses	Commercial tiers scale with data volume or hosts; confirm the license terms of any platform before selecting it
Platform hosting and infrastructure	Recurring	Your cloud or data center team, or the hosting provider you already use	Number of log sources, retention period and alert channel redundancy
Engineering time to configure failure alerts	One-time, with periodic changes	Internal platform engineers or an implementation partner under a written scope	Number of log pipelines, collectors and destinations that can fail silently
Defining failure types and alert recipients	One-time, reviewed periodically	Security officer and system owners, with optional advisory support	Number of systems, staff turnover and how many distinct failure conditions your environment has
Procedure writing for audit logging failures	One-time, updated after changes	Compliance lead or security team; a consultant may draft and review	Depth of the response steps and whether they tie into incident response procedures
Periodic failure testing	Recurring	Internal staff or a testing provider who stops a log source on purpose and records the alert	Frequency you set, number of pipelines tested and whether tests are scripted
Evidence upkeep	Recurring	Internal staff who keep alert records, test results and change tickets current	Alert volume, ticket tooling and how often configurations change
External review or assessment support	Recurring at each assessment cycle	Independent assessor for the assessment itself; consultants may prepare evidence, but assessors issue results	Evidence quality, scope clarity and the number of findings raised during preparation

Who owns audit failure alerting and what can be outsourced

Your organization owns AU.L2-3.3.4 because the requirement turns on decisions only you can make. NIST SP 800-171A breaks the requirement into three assessment objectives: identifying who is alerted, defining which audit logging failures trigger an alert, and alerting those people or roles when a failure occurs. Your security office must name the recipients, approve the failure types and sign off on the response procedure. Those decisions belong to you even when a partner drafts the paperwork.

Recipients: Name the system administrator, security officer or other designated roles who must learn of a logging failure, and keep the list current as staff change.
Failure definitions: Decide which failures count, such as a logging service stopping, a log store filling, or a forwarder losing its connection.
Response procedure: Document what each recipient does after an alert, including who investigates and how a gap is restored.
Alert decisions: Choose the delivery channel, such as email or SMS, and accept the risk of any failure type you choose not to alert on.
Testing: Run or direct the tests that force a logging failure and confirm the alert arrives.

Before an assessment, check that every recipient can produce the alert records and procedure without help from the partner.

Common gaps in audit failure alerting and how to close them

Most audit failure alerting problems are not technical failures of the logging tool. They come from undefined failure types, stale recipients, untested alert paths, and evidence that cannot show when anything happened. Each card below names one gap an assessor is likely to find under AU.L2-3.3.4 and the fix that closes it.

No defined failure types

Teams often alert on a log service being down but never define what else counts as an audit logging failure, such as a full log volume, a stopped forwarder, a dropped connection to the central store, or a disabled audit policy on a host. Assessment objective 2 under NIST SP 800-171A asks the organization to define these types. Write the list in the system security plan or a logging procedure, map each type to a detection rule, and confirm that every host class in scope produces at least one of them.

Alerts routed to a departed employee

An alert that goes to a mailbox or pager owned by someone who has left the organization is a silent failure. Assessment objective 1 requires identifying who is alerted, so the recipient list must be a role-based group, such as the security officer or system administrator on duty, rather than a named individual. Review the list at each personnel change and during offboarding, and ask for the distribution group membership as evidence.

Alerts configured but never tested

A detection rule that has never fired may not work at all. Test the alert path by deliberately stopping a non-production log forwarder or filling a test volume, then confirm the alert reaches the named recipients through email, SMS or chat. Keep the test record with the date, the trigger, the recipient and the result. Assessors look for tests of the mechanisms that respond to logging failures, so a configuration screenshot alone rarely closes this gap.

Failures found only in weekly reviews

If a team learns about a logging gap during a weekly log review, the gap may have lasted for days with no records. AU.L2-3.3.4 calls for alerting when a failure occurs, which is a push notification rather than a periodic check. Configure health and heartbeat monitoring on each log source and forwarder, and use a tool such as Wazuh or a Grafana alert rule to notify the designated roles immediately. Weekly reviews remain useful, but they cannot replace the alert.

Screenshots with no date

A screenshot of an alert rule or a notification email with no timestamp, system name or visible recipient gives an assessor nothing to verify. Evidence should be the alert configuration export, the notification record from the sending system, and the incident or test ticket, all with dates in their native form. Keep these in a repository with access controls, and confirm that the records are final versions rather than drafts, since the CMMC rule accepts only evidence in final form.

Audit failure alerting questions buyers ask before hiring help

How much does outside help for AU.L2-3.3.4 cost?

No supplied fact gives a price for this work, and DeployOpen does not publish a price list. The cost depends on how many logging sources exist, whether alerting already runs in a SIEM or monitoring stack, and how many failure types and recipients must be defined. A fixed-scope quote is built from a written scope, so ask for the scope to list the log sources, the failure conditions, the notification channels and the evidence to be produced. Ask whether the quote separates one-time setup from ongoing support, testing or upgrades, since those recur on different schedules. Compare quotes against the same scope, not against the headline number.

How long does it take to get audit failure alerting in place?

The timeline depends on the state of the logging environment, not on the single requirement. A team with a central log platform and documented notification lists can finish faster than one that must first decide which logs matter and who owns them. The work usually runs in phases: defining failure types and recipients, configuring alerts, testing that alerts fire and reach people, then collecting evidence. Ask any partner to show the phases in the written scope with dates agreed before work starts. Be cautious about any timeline quoted without first reviewing your environment.

What does our team have to provide for this work?

Your team owns the control, so it must supply the decisions and access. Expect to provide a list of systems that generate audit logs, the named roles that must be notified (such as the system administrator and security officer, as the CMMC Assessment Guide Level 2 describes), approved notification channels such as email or SMS, and read access to logging and alerting tools. Someone with authority must approve the failure types and the response procedure. Confirm these owners early, because delays in naming recipients are a common cause of slow progress.

Can we handle AU.L2-3.3.4 in-house instead of hiring a partner?

Yes, many organizations meet this requirement internally if they have engineers who can configure alerting and document the results. Hiring help makes more sense when no one has time, when the logging stack is unfamiliar, or when an outside view is wanted before an assessment. Whichever path you choose, the organization remains responsible for the control. Check whether your team can produce the three things NIST SP 800-171A expects: identification of who is alerted, defined failure types, and proof that alerts reach those people.

What does a partner prepare, and what does the assessor test?

A partner prepares the system and evidence. That typically includes the failure definitions, alert rules and notification configuration, a written response procedure, and test records showing alerts fire. The assessor is a separate party. For Level 2 certification, a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, performs the assessment and issues the result. Assessors check that the listed recipients are the people actually alerted, that failure types are defined, and that the alerting mechanism works. A partner cannot issue a CMMC assessment result.

How does the POA&M rule apply to a 1-point requirement like this one?

Under 32 CFR 170.24, AU.L2-3.3.4 is worth 1 point. Because it is a 1-point requirement not on the exclusion list in 32 CFR 170.21(a)(2)(iii), it may be placed on a plan of action and milestones (POA&M) for Conditional Level 2 status, provided the score is at least 88 of 110 (0.8). The POA&M closeout is due within 180 days. Treat this as a rule to confirm against the current text, since the program schedule has changed, and do not assume a POA&M is a substitute for working alerting. Ask your advisor to confirm how the rule applies to your scoring.

What evidence should we expect to keep after the work is finished?

Keep evidence in final form, because the assessment objectives are met only with final evidence, not drafts (per 32 CFR 170.16, 170.17 and 170.24(b)). Useful records include the approved list of alert recipients, the defined failure types, alert rule exports, screenshots or logs showing a test alert delivered to each recipient, the incident procedure for responding to a logging failure, and tickets showing alerts were acted on. Review these records on a schedule so they remain accurate after system changes.

How the CMMC phase status affects this requirement today

AU.L2-3.3.4 remains a Level 2 requirement under 32 CFR Part 170, and the suspension of Phase II does not remove it. The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start on 10 November 2026 and would have required Level 2 certification assessments by C3PAOs for applicable contracts. The suspension paused the certification timeline and started a 60-day review by a CMMC Reform Task Force. It did not change the Level 2 security requirements themselves, which the CMMC rule still ties to NIST SP 800-171 Rev. 2, or the obligations that already apply to contracts with CUI.

Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in place. In practice, an organization that submits a self-assessment score must still be able to show that its audit failure alerting works and that the evidence behind the score is in final form. A score that counts AU.L2-3.3.4 as met when no one is notified of a logging failure can be challenged later, whether the review comes from a contracting officer, a prime contractor or a future assessor. Organizations should plan as if the requirement will be tested on its merits.

Phase status changes quickly and has already moved more than once, so confirm the current position before making decisions about timing or budget. Check the DoW CIO About CMMC page for the official status of implementation, and compare it with the eCFR text of 32 CFR Part 170 that governs the rule. Record the date you checked and who checked it. Do not treat the suspension as a reason to defer alerting work, because a logging failure that goes unnoticed during a quiet period will still create a gap in the evidence you will need once the requirement is enforced again.

AU.L2-3.3.4 Audit failure alerting