1Overview
AU.L2-3.3.4 protects the auditing itself. It requires that the organization be alerted when the audit logging process fails, so that a lapse in logging is noticed rather than leaving a silent gap in the record. It is a one-point requirement and may be deferred on a plan of action.
Auditing has a blind spot of its own: if logging stops, nothing records the fact that it stopped. A disk fills, a logging service crashes, a collector loses its feed, and from that moment the system generates no record, so an attacker operating during the gap leaves no trace and the organization may not know until it goes looking and finds nothing. This control closes that blind spot by requiring an alert when the logging process fails, so the gap is caught and addressed rather than discovered too late. It asks the organization to decide who should be alerted, to define what counts as a logging failure, and to actually alert those people when one occurs.
Alert in the event of an audit logging process failure.
The requirement is about knowing when the eyes have closed. A logging failure is any condition that stops or degrades the recording of audit events, from storage exhaustion to a stopped service. The control expects that such a failure triggers an alert to identified people, so that logging can be restored quickly and the gap kept short. The organization defines both the failure conditions and the recipients, and the control is met when a real failure produces a real alert.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.3.4 into three objectives: identify who is alerted, define the failure types, and alert on failure.
Personnel or roles to be alerted in the event of an audit logging process failure are identified. The organization has decided who hears about a logging failure.
Types of audit logging process failures for which alert will be generated are defined. The organization has decided what conditions count as a failure.
Identified personnel or roles are alerted in the event of an audit logging process failure. A real failure actually reaches the identified people.
The three objectives move from who and what to the alert itself. The common gap is at objective [c], where the mechanism to detect and alert on a logging failure was never configured, so a failure goes unnoticed. The assessor looks for a working alert path, not just a policy naming recipients.
3Failure Patterns
The failures are about silent logging failures and alerts that never reach anyone.
The silent gap
When logging stops and nothing announces it, the organization keeps operating as if it is being recorded while it is not. This is the exact failure the control exists to prevent, and it is resolved by monitoring the logging process and alerting when it fails.
Storage exhaustion
A common cause of logging failure is full log storage, after which new events are dropped. Alerting on storage nearing capacity, and on the failure itself, keeps a full disk from quietly ending the audit trail.
Alerts configured but unrouted
An alert that fires into an unmonitored console or mailbox satisfies nothing, because the identified people never see it. Objective [c] requires the alert to actually reach the recipients, so the routing has to end somewhere a person watches.
No definition of failure
Without defined failure conditions, there is no clear trigger for an alert, and marginal states go unhandled. Objective [b] asks the organization to decide what counts as a failure so the alert has a definite basis.
4Ownership
This is an IT-owned technical control, and its work is monitoring the logging process and routing failure alerts to people who will act.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Defines the failure conditions, configures the alerting, and ensures alerts reach the identified recipients. Owns the technical evidence. |
| Security or compliance lead | Identifies who should be alerted and confirms the alert path is monitored and acted on. |
| Program lead | Includes logging-failure alerting in periodic checks and retains the configuration and any alert records. |
5Tooling
The control is delivered by monitoring the logging process and generating alerts on failure, usually through the same platform that collects the logs.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Alert recipient configuration | The identified people or roles that receive logging-failure alerts. |
| [b] | Defined failure conditions, storage thresholds | The conditions, such as service stopped or storage full, that trigger an alert. |
| [c] | SIEM or monitoring alerting, health checks on log agents | Detection of logging failures and delivery of the alert to the recipients. |
| Prevention | Log rotation and capacity management | Keeping storage from filling, reducing the most common failure cause. |
The caveat is that the alert has to reach a person who acts. An alert generated into an unwatched place is as good as none, so the routing and the monitoring behind it are the real substance. The assessor confirms the control by examining whether a logging failure would produce an alert to the identified people, so the path has to be demonstrably live.
6Evidence
The satisfied version of 3.3.4 shows defined recipients and failures and a working alert path.
| Evidence | What it demonstrates |
|---|---|
| Alert recipient designation | Objective [a]. The people or roles to be alerted. |
| Defined failure conditions | Objective [b]. The conditions that trigger an alert. |
| Alert configuration | Objective [c]. The configured detection and delivery of failure alerts. |
| Sample alert or test record | Objective [c]. Evidence that a failure would reach the recipients. |
The evidence should show that a logging failure produces an alert that reaches identified people, which a configuration plus a test or sample alert demonstrates. Definitions of the recipients and failure conditions, paired with a live alert path, are the clearest demonstration of the control.
Nothing records the moment recording stops
A logging failure is silent, so an attacker operating during the gap leaves no trace and the lapse is found only when someone looks for records that were never made. Building an alert that catches a logging failure and reaches someone who will act is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.3.4. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.3.4[a] through 3.3.4[c]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov