Audit logging is only useful if the logs themselves are trustworthy. The moment an attacker can disable logging or logs stop flowing due to a system failure, your visibility breaks. AU.L2-3.3.4 requires you to detect that break immediately and alert the people who can fix it.
This is straightforward in concept. Complex in practice. SIEM systems fail. Log collectors crash. Network paths break. Disk space fills up. If none of these failures trigger an alert, you won’t know that logging has stopped until an incident investigation later reveals gaps in your records. That’s unacceptable for CMMC. The logs you create under AU.L2-3.3.1 are only valuable if they’re continuously flowing. This practice is the safety net that keeps that flowing.
What the assessor is actually evaluating
The assessor is checking three things. First: “Do you monitor for audit system failures?” They’ll ask for your alert configuration. What failures trigger notifications? Common ones include log collector disconnection, SIEM disk space threshold, authentication system down, email gateway logging failure, antivirus or endpoint detection system offline.
Second: “Who gets notified when failures occur?” Your answer needs to be specific. “The security team” is too vague. “The SIEM administrator at [email] and the IT operations manager at [email], with escalation to the security director if not resolved within one hour” is what they want to hear.
Third, the killer: “Show me the evidence that this actually works.” They want to see alert logs or historical records showing that when logging failed in the past 12 months, you detected it and responded. If you can’t show a recent example of an alert firing and triggering action, the assessor assumes the alerting is misconfigured or ignored.
What a realistic SSP definition looks like
- Log collector failure (no data received from endpoint, network, or identity system for 15 minutes)
- SIEM storage capacity exceeds 85 percent
- Failed authentication to identity provider directory (indicates logging system may have lost connectivity)
- Email gateway logs not received for 30 minutes
- Firewall device offline or unreachable
- Any audit log is deleted or modified (flagged by file integrity monitoring)
Alerts are sent to the SIEM administrator ([name/role]) and the network operations manager ([name/role]) immediately upon detection. Critical alerts (logging completely offline) also trigger escalation to the IT director and information security officer if the issue is not resolved within 30 minutes. All alerts are logged in [alerting platform] with response time and remediation actions recorded. Alerts are reviewed as part of our monthly audit log review process to identify patterns and systemic issues."
The specificity matters. Named people, clear conditions, response timelines, and documentation requirements all demonstrate you’ve thought through the failure scenarios.
How to present your evidence
- Alert configuration documentation with specific failure conditions
- Escalation procedures showing who gets alerts and timelines
- Alert logs showing failures were detected and triggered action
- Alert testing records demonstrating the alerting works
Build a package showing three elements:
Alert configuration documentation. Screenshot or export from your SIEM, antivirus platform, network monitoring tool, or alerting system showing the specific conditions you monitor for. Include thresholds. For example: “Alert when storage exceeds 85 percent” or “Alert if no logs received for 15 minutes.”
Escalation procedures. A written procedure (email distribution list, runbook, or security operations manual) showing who gets alerts, how, and what they’re supposed to do.
Historical evidence of alerts firing and being acted upon. This is critical. Pull your alert logs or SIEM notification history from the past 12 months. Find at least one or two examples where an alert fired, personnel were notified, and the issue was investigated and resolved. Include the alert record, the notification sent, and the remediation record.
If you’ve had zero audit system failures in 12 months, that’s credible but requires some care. You need to demonstrate that the monitoring is active. Show alert configuration, show that alerts are being generated for non-critical conditions (storage at 60 percent, for example), and explain your testing process.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
If you use an MSSP
Your MSSP owns monitoring their own audit system for failures. They maintain alerting for log collector failure, SIEM health, connectivity issues, and other logging infrastructure problems. When a failure occurs, they alert you immediately so you can respond. Your role is to acknowledge the alert, investigate if needed, and coordinate any remediation on your side.
A good MSSP contract explicitly covers monitoring for logging failures and includes defined alert conditions, notification procedures, and response expectations. Their infrastructure should include redundancy so that if a primary log collector fails, a backup engages automatically. Your MSSP should provide evidence (alert logs, tickets, or summary reports) showing that this monitoring happens and is effective.
Work with your MSSP to define which logging failures trigger alerts, who at your organization gets notified, and response timelines. Get this in writing in your contract or SLA. For evidence, keep records of alerts your MSSP has sent and your responses. This documentation proves the alerting is real, not theoretical.
Disclaimer: This guide is educational and not official CMMC documentation. Always refer to NIST SP 800-171 and the official CMMC Assessment Guide for authoritative requirements. Individual assessment results depend on implementation details specific to your organization.