Security logging and alerting failures is the category that doesn't show up in scanner reports, doesn't generate CVEs in large numbers, and often isn't noticed until a breach is already over. But when it does show up, it's usually the difference between catching an attack in progress and finding out about it on the news.
The 2025 edition renamed this category slightly. Previously "Security Logging and Monitoring Failures." Now "Security Logging and Alerting Failures." The word change matters. Monitoring implies dashboards you look at. Alerting implies signals that reach you. Logs that exist but nobody watches are useless. The category is not about whether data is collected. It's about whether anyone notices when something is wrong.
Three real-world examples to show what's at stake.
A children's health plan provider was breached. Someone had accessed and modified sensitive health records for more than three and a half million children. The provider didn't notice. They found out when an external party informed them. Post-incident review found the breach could have been ongoing since 2013. That's over seven years of undetected access. The root cause was simple: no logging, no monitoring, no way for anyone inside the organization to see what was happening.
A major Indian airline suffered a data breach affecting ten years of personal data for millions of passengers, including passport numbers and credit card information. The breach occurred at a third-party cloud hosting provider, who notified the airline only after significant delay. The airline had no independent way to detect the exposure.
A major European airline had a GDPR-reportable breach after attackers exploited vulnerabilities in their payment application and exfiltrated over four hundred thousand customer payment records. The regulator fined them twenty million British pounds. Investigation found the breach was not detected in anything close to reasonable time. Insufficient logging and monitoring was named as a contributing factor.
These are not obscure companies or unusual circumstances. They are large, well-resourced organizations, and the common thread is the same: data was taken, and no one noticed.
So what does it look like when logging and alerting fails?
Missing audit logs. Logins, failed logins, high-value transactions either not logged or logged inconsistently.
Poor log quality. Warnings and errors that generate no useful message, or message text that doesn't include the context needed to investigate.
Logs stored only locally, without backup, so an attacker who breaks in can delete the evidence of how they got there.
Alerting thresholds that generate too many false positives. When every alert is noise, real alerts get ignored.
Alerting thresholds that generate no signal. Penetration tests and automated scanning tools don't trigger any alerts, so real attackers probing the same endpoints go unnoticed.
Information leakage in logs themselves. Sensitive data written to log files where it can be exposed via log aggregation tools, or PII logged in a way that creates its own compliance problem.
So how do you defend against this category?
First, log comprehensively. All authentication events, both success and failure. All access control decisions. All input validation failures. Include enough user context to identify suspicious behavior. Retain logs long enough for forensic analysis after a delayed discovery. Seven years of gap is extreme, but even six months is often too short.
Second, centralize. Local log files on individual servers are a starting point, not an endpoint. Ship everything to a log aggregator like the ELK stack, Datadog, Splunk, or CloudWatch. Centralization enables both protection from tampering and real-time analysis across sources.
Third, alert on specific events, not error rates. "High error rate" is not an alert. "Ten authentication failures from the same IP in one minute" is. Define what the attack patterns look like in your environment, and write alerts that match those patterns.
Fourth, test your alerting. If a penetration test against your application doesn't trigger any alerts, that's a critical gap. Your detection controls are as important as your prevention controls, and they need to be exercised.
Fifth, have an incident response playbook before you need one. NIST 800-61 is the standard reference. Teach developers what attacks look like, so they can recognize them in the logs they're reading.
Logs without alerts are paperwork. Alerts without context are noise. Get both right, and you have the visibility that turns a seven-year silent breach into a thirty-minute incident.