CMMC Controls Explained: AU.L2-3.3.4 – Audit Failure Reporting

Audit logging is only as valuable as its reliability. If your logs quietly stop working and nobody notices, you've lost your visibility, your evidence trail, and potentially your compliance status — all at the same time.

Control AU.L2-3.3.4 exists for exactly that reason. It's one of the more underestimated controls in the Audit and Accountability domain, but it consistently appears on lists of the most commonly failed NIST 800-171 requirements. The good news: it's also one of the more straightforward controls to implement once you understand what it actually requires.

This guide breaks down what AU.L2-3.3.4 means in plain language, and then walks through what implementation and evidence collection look like inside ASCERA step-by-step.

What is Control AU.L2-3.3.4 – Audit Failure Alerting?

Control AU.L2-3.3.4 states that organizations must alert in the event of an audit logging process failure.

The purpose of this control is to ensure that your organization is immediately notified if something goes wrong with your audit logging system. Logging failures don't always announce themselves — a misconfiguration, a full storage volume, or a crashed logging service can silently take your audit trail offline while everything else appears to be running normally. This control closes that blind spot by requiring active, automated alerting so that the right people know about a failure fast enough to act on it.

This control applies to every system within your CMMC assessment scope that is required to generate audit logs — which includes any system that stores, processes, or transmits Controlled Unclassified Information (CUI).

Understanding "Audit Logging Process Failure"

The phrase "audit logging process failure" covers more ground than most organizations initially expect. Under NIST SP 800-171, the following all qualify:

• Software errors — A logging service crashes or stops running unexpectedly
• Hardware errors — A drive failure or system malfunction that disrupts log capture
• Failures in audit record capturing mechanisms — A misconfiguration that causes events to stop being recorded even though the system appears operational
• Audit record storage capacity being reached or exceeded — Log storage fills up, causing new events to be dropped or overwritten
• Intentional tampering — An adversary disabling or corrupting your logging system as part of an attack

It is also worth noting that NIST specifies this requirement applies both to each individual audit record data storage repository and to the total audit record storage capacity of your organization. That means you need alerting coverage at the individual system level and at the aggregate level — not just one or the other.

AU.L2-3.3.4 Assessment Objectives

When assessing this control, the following must be determinable:

All three objectives must be met. A single unmet objective fails the entire control. Simply having a monitoring tool in place is not enough if it has not been configured to send alerts to the right people for the right failure types — and "the right people" must be documented, not assumed.

Spirit of the Control

This control ensures that organizations can detect and respond to failures in audit logging systems before critical security events go unnoticed. Logging failures may result from system crashes, storage limitations, misconfigurations, or intentional tampering. By alerting administrators when logging processes fail, organizations can restore functionality quickly, mitigate security risks, and maintain compliance with both audit and incident response requirements.

If security personnel are unaware that audit logging has failed, they will also be unaware of any suspicious activity occurring during that window. The two failures compound each other.

Discussion from NIST 800-171 R2

NIST emphasizes that audit logs must always be available and functional. The company's designated security personnel — such as the system administrator and security officer — need to be aware when the audit log process fails or becomes unavailable. Notifications (via email, SMS, or similar) should be sent immediately so that appropriate action can be taken.

NIST also notes that the response to an audit logging process failure should account for:

• The extent of the failure (a single component's logging versus the entire centralized logging solution)
• The risks involved in the loss of audit logging during that period
• Other contextual factors, including the possibility that the failure was caused by an adversary

Common Ways to Meet Control AU.L2-3.3.4

Organizations can satisfy this control if they:

• Enable system-level audit logging alerts: Configure SIEM tools, log management systems, or operating system event logs to trigger alerts when audit logging processes fail. Alerts must be automated — you cannot rely on someone manually checking whether logs are still coming in.
• Monitor log storage capacity: Set up automated alerts for disk space thresholds to prevent logging failures due to insufficient storage. A system that hits its storage limit will silently stop capturing new events unless you have a threshold alert configured to warn you before that happens.
• Use redundant log storage locations: Ensure that logs are written to secondary or backup locations in case of primary logging failures. Redundancy reduces the risk of losing log data during a failure and provides continuity while the primary system is restored.
• Deploy SIEM or centralized log management: Use a Security Information and Event Management (SIEM) system to aggregate logs and detect failures across multiple sources. A centralized platform makes it far easier to maintain consistent alerting coverage across your entire environment.
• Configure alerts to the right people: Set up automated notifications — email, SMS, or dashboard alerts — to named security personnel when logging processes fail. An alert going to a general inbox that nobody actively monitors does not satisfy objective [a].
• Implement log integrity monitoring: Use file integrity monitoring (FIM) tools to detect and alert on log corruption, deletion, or modification. This is particularly important for catching tampering-based failures.
• Regularly test your alerting: Configuring an alert is not the same as having a functioning alert. Periodically simulate a failure condition and verify that the alert fires and reaches the right person. Test results are strong evidence for assessors.
• Integrate logging alerts into incident response procedures: Ensure that audit logging failures trigger your incident response workflows, not just a one-off notification. The failure itself may be a security event that requires investigation.
• Restrict unauthorized access to log files: Enforce role-based access controls (RBAC) on log storage to prevent tampering or unauthorized deletion.
• Train IT personnel on log failure response: Ensure system administrators and security teams know how to respond when a log failure alert arrives — including how to investigate whether the failure was caused by a malicious actor.

What Assessors Look For

Assessors typically review:

• Documented audit logging policies, specifying how failures are detected, who is notified, and how alerts are addressed
• System configurations demonstrating active alert mechanisms — such as SIEM rules, operating system event monitoring, or automated notification settings — not just policy descriptions
• Audit log failure test results, verifying that alerts actually trigger when logging processes fail
• Incident response procedures for audit log failures, showing that failures are investigated and mitigated, not just acknowledged
• System administrator logs and ticketing system records, proving that alerts are received and acted upon by the identified personnel
• Security monitoring reports, confirming that audit log integrity is actively monitored on an ongoing basis
• Training records for IT personnel, confirming that the people responsible for responding to alerts understand what to do when they receive one

Potential Assessment Methods

Remediation Recommendation

If you are not currently meeting this control, the path forward is straightforward:

How AU.L2-3.3.4 Connects to Other Controls

AU.L2-3.3.4 does not stand alone. It is tightly connected to several neighboring controls:

Think of AU.L2-3.3.4 as the safety net under your entire logging program. Without it, every control that depends on your audit logs is at risk the moment something goes wrong.