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).
This control aligns closely with AU.L2-3.3.1, which requires creating and retaining audit logs in the first place. Together, they form the backbone of a reliable audit logging infrastructure.
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
That last one is worth emphasizing. If an attacker disables your audit logs before taking action and you have no alert configured to catch it, you lose both the attack evidence and any chance of detecting the compromise in real time. NIST specifically notes that organizations should consider the possibility that an adversary could have caused the audit logging process failure when responding to alerts.
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:
Assessment Objectives
- Personnel or roles to be alerted in the event of an audit logging process failure are identified A
- The types of audit logging process failures for which alerts will be generated are defined B
- Identified personnel or roles are alerted in the event of an audit logging process failure C
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
A common failure pattern is organizations that have alerting partially configured — for example, a SIEM generating alerts but no named individual documented as responsible for receiving them, or alerts routed to a shared inbox that nobody monitors consistently. Both scenarios result in a "Not Met" finding.
Potential Assessment Methods
Examine
Audit and accountability policy; procedures addressing response to audit logging processing failures; system design documentation; system security plan; system configuration settings; list of personnel to be notified; system incident reports; system audit logs.
Interview
Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
Test
Mechanisms implementing system response to audit logging process failures.
Remediation Recommendation
If you are not currently meeting this control, the path forward is straightforward:
Configure your in-scope systems and your SIEM to generate alerts if logs are not received from a given source within an expected timeframe. Also configure alerts if the SIEM itself experiences logging failures. Ensure that key, named personnel are identified as the recipients of these alerts. And critically — ensure there is a documented process for investigating the root cause of every alert, including validating whether the failure was or was not the result of malicious activity.
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.
How ASCERA Helps with AU.L2-3.3.4
Implementing alerting is the hard part. Proving it to an assessor is where ASCERA comes in.
ASCERA tracks each of the three assessment objectives for this control independently, so if you've named the right personnel and defined your failure types but haven't yet documented that alerts actually fire — you'll see that gap before your assessor does.
Evidence uploads attach directly to the control and automatically map across related controls, so your alert configuration screenshots, test records, and notification logs work harder across your entire compliance program, not just here.
Every control in ASCERA comes with built-in written and video guidance covering what to implement, what to document in your SSP, and what a strong evidence package looks like — so you're never starting from scratch.
See ASCERA in Action
Want to see how ASCERA tracks controls, manages evidence, and keeps your compliance program audit-ready?
Schedule a Free Demo