Audit and Accountability 3.3.4 (3.3.4)
Alert in the event of an audit logging process failure.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to implement automated alerting mechanisms that notify appropriate personnel when audit logging systems fail, stop working, or encounter errors. The goal is to ensure that security monitoring capabilities are not silently lost due to technical failures, storage capacity issues, or system malfunctions. Organizations must be immediately aware when their ability to capture security events is compromised so they can take corrective action before security incidents go undetected.
Control Intent
To ensure continuous security monitoring capability by providing immediate notification when audit logging systems fail, preventing gaps in security event visibility that could allow malicious activity to go undetected.
Who This Control Applies To
- •All systems and applications that generate audit logs within the CDE or that process, store, or transmit CUI
- •Centralized logging infrastructure including SIEM, log aggregators, and log management platforms
- •Individual system components with local audit logging capabilities
- •Storage repositories where audit records are retained
- •Network devices, security appliances, and infrastructure components that generate security-relevant logs
Not Applicable When
- •Systems that do not process, store, or transmit CUI and are completely outside the assessment scope
- •Standalone systems with no audit logging capability where AC.L2-3.3.1 has been formally accepted as not applicable
- •Systems covered by a formal exception or POA&M that explicitly addresses both audit logging and failure alerting
- •Test or development environments that are completely isolated from production CUI and have no CUI access
Key Objectives
- 1Detect and alert on failures in audit record generation, capture, or storage mechanisms before security visibility is lost.
- 2Ensure appropriate personnel are notified immediately when audit logging capacity limits are approached or exceeded.
- 3Maintain continuous awareness of audit system health to prevent silent failures that could mask security incidents.
- 4Enable rapid response to audit system failures to minimize gaps in security event monitoring.
Sample Self-Assessment Questions (Partial)
Does your organization use any centralized logging or SIEM system that collects logs from multiple sources?
Have you configured alerts or notifications when your logging systems stop receiving logs from critical systems?
Implementation Approaches (High-Level)
SIEM or Log Management Platform with Built-in Health Monitoring
Centralized logging platform with native capabilities to monitor log source health, detect missing logs, and generate alerts when systems stop sending logs or when storage capacity issues arise.
Synthetic Monitoring and Heartbeat Checks
Automated monitoring scripts or agents that periodically verify logging functionality by generating test events and confirming they appear in centralized logs, with alerts triggered when test events are not detected.
Storage Capacity Monitoring and Alerting
Dedicated monitoring of audit log storage repositories with alerts triggered when storage utilization reaches defined thresholds, preventing log loss due to capacity exhaustion.
Application and Service-Level Logging Health Checks
Individual applications and services implement internal health checks that monitor their own audit logging functionality and report failures to centralized monitoring or alerting systems.
Network and Infrastructure Monitoring for Logging Components
Network monitoring tools and infrastructure management platforms monitor the health and connectivity of logging infrastructure components, alerting when log collectors, forwarders, or aggregators fail or become unreachable.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If no alerting is currently implemented, POA&M should include milestones for selecting and deploying monitoring tools, configuring alert rules, and testing alert delivery For organizations with partial alerting coverage, POA&M should identify specific gaps (e.g., missing coverage for certain systems or failure types) and timeline for achieving complete coverage If alerting exists but is not functioning correctly, POA&M should address root causes such as misconfiguration, alert fatigue, or inadequate testing POA&M should specify interim compensating controls such as increased frequency of manual log review or daily health checks until automated alerting is fully operational Implementation timeline should account for complexity of logging architecture - simple environments may achieve compliance in 30-60 days, while complex distributed environments may require 90-180 days POA&M should include specific acceptance criteria such as successful detection of simulated logging failures and documented alert response within defined timeframes For storage capacity alerting, POA&M should include capacity planning activities to ensure adequate storage is available while alerting is being implemented If organizational constraints prevent immediate implementation, POA&M should justify delays and demonstrate that risk is understood and accepted at appropriate management level
Frequently Asked Questions
What types of logging failures must trigger alerts under this control?
This control requires alerts for any failure that prevents audit records from being captured, transmitted, or stored. This includes software errors in logging components, hardware failures affecting log storage, network connectivity issues preventing log transmission, audit record capturing mechanism failures, and storage capacity being reached or exceeded. Both individual system failures and centralized logging infrastructure failures must be detected and alerted.
How quickly must we be alerted when logging fails?
While the control does not specify an exact timeframe, alerts should be timely enough to prevent significant gaps in security monitoring. Industry practice typically requires detection within 15-60 minutes for critical systems. The appropriate timeframe depends on your organization's risk tolerance, the criticality of affected systems, and the volume of security events typically generated. Your alert thresholds should be documented and justified based on these factors.
Do we need separate alerts for each individual system, or is monitoring our SIEM sufficient?
You need both. Monitoring your SIEM or centralized logging platform detects failures in the logging infrastructure itself, but you also need mechanisms to detect when individual systems stop sending logs to that infrastructure. This could be through SIEM features that track expected log sources, synthetic monitoring that verifies end-to-end logging, or application-level health checks. Simply monitoring the SIEM is insufficient if it cannot detect when sources go silent.
What happens if we receive too many false positive alerts and staff start ignoring them?
Alert fatigue is a common challenge but does not excuse non-compliance. You must tune alert thresholds and logic to minimize false positives while still detecting real failures. This may require establishing baselines for normal log volume, implementing grace periods for expected maintenance windows, and using multiple detection methods. If alerts are being ignored, you are not meeting the control's intent of ensuring awareness of logging failures. Document your tuning process and demonstrate that alerts are actionable and acted upon.
Are we required to alert on storage capacity before it is completely full?
Yes. The control specifically mentions storage capacity being reached or exceeded, but best practice and assessor expectations require proactive alerting at threshold levels before capacity is exhausted (typically 70-80% utilization). Waiting until storage is completely full means logs are already being lost. Your alerting should provide sufficient warning time to take corrective action such as expanding storage, archiving old logs, or adjusting retention policies before any log loss occurs.
Who must receive the logging failure alerts?
Alerts must be sent to personnel who have the responsibility and capability to respond to logging failures. This typically includes security operations staff, system administrators responsible for logging infrastructure, or IT operations teams. The specific recipients should be documented in your procedures. Alerts sent to generic email addresses or distribution lists that are not actively monitored do not satisfy this control. You must demonstrate that alerts reach responsible individuals and that they take appropriate action.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.