Insufficient Logging and Monitoring
detect, understand, remediate
Insufficient logging and monitoring (OWASP A09:2021) leaves authentication failures, access control violations, and exploit attempts invisible to defenders. Without an audit trail and active alerting, breaches go undetected long enough for attackers to pivot, persist, and exfiltrate.
No credit card required. Free plan available forever.
What is insufficient logging and monitoring?
Insufficient logging and monitoring is the absence (or inadequacy) of audit logs, security event records, and active alerting that defenders rely on to detect and respond to attacks. The category was promoted from A10 in OWASP Top 10 (2017) to A09 in the 2021 list under the title Security Logging and Monitoring Failures, reflecting how often visibility gaps are the difference between a contained incident and a long-dwell breach. The vulnerability is mapped most commonly to CWE-778 (Insufficient Logging), with related weaknesses CWE-223 (Omission of Security-relevant Information) and CWE-532 (Insertion of Sensitive Information into Log File).
Unlike an injection or access control flaw, insufficient logging is not directly exploitable on its own. The damage is indirect: when an attacker chains a separate vulnerability (a credential stuffing attempt, an authentication failure, an unauthorised access attempt against an IDOR-prone endpoint), the absence of logging means defenders never see the activity. The dwell time extends, the blast radius grows, and the post-incident investigation has nothing to reconstruct from.
For pentesters and AppSec teams, this is one of the highest-leverage findings to write up because the remediation is operational rather than code-bound, and the impact statement reaches stakeholders well beyond engineering. For internal security teams and vCISOs, it is also a recurring control gap in ISO 27001 (Annex A.8.15, A.8.16), SOC 2 (CC7.2, CC7.3), PCI DSS v4 (Requirement 10), and the EU NIS2 Directive (Article 21 incident handling and detection).
How attackers exploit the visibility gap
Reconnoitre without alerting
Attackers probe authentication endpoints, enumerate user IDs, and fingerprint the technology stack. Without rate-limited login logging or 401/403 alerting, the activity blends into normal traffic.
Exploit a paired vulnerability
A separate flaw is exploited (credential stuffing, IDOR, server-side request forgery, command injection). The application returns the attacker output but writes nothing useful to logs the SOC actually reviews.
Persist and escalate
With no detection signal, the attacker installs persistence, escalates privileges, or pivots laterally. Mean time to detect (MTTD) stretches from hours to weeks, multiplying the data exposure window.
Disrupt the audit trail
When the breach is finally discovered, the missing logs prevent reconstruction of the attack path. Notification timelines under GDPR Article 33 and NIS2 Article 23 become difficult to meet defensibly.
Common causes
Auditable events not logged
Login successes, login failures, password changes, MFA challenges, role changes, privileged actions, and access denials are not written to a durable, queryable log store.
Logs trapped on the host
Application logs live only on the local file system or container ephemeral storage. They rotate or vanish on redeploy, and never reach a SIEM, log aggregator, or cloud-native logging service.
No alerting on security signals
Logs exist but no rules fire. Brute force patterns, impossible travel, privilege escalation events, and known-bad payloads enter the log stream and stay there until someone runs a manual query.
Sensitive data in logs (CWE-532)
Passwords, session tokens, API keys, full payment card numbers, or PII are written to logs in cleartext. The logging that does exist becomes a secondary breach risk rather than a defensive control.
No log integrity protection
Logs are mutable on the writing host and are not shipped to a write-once or hash-chained store. An attacker who reaches the host can edit or delete the only record of their activity.
No incident response runbook
Even when a high-severity log event fires, no runbook tells responders how to triage, escalate, or contain. The platform has data, but no operational response is wired to it.
How to detect it during testing
Active testing
- Generate a series of failed authentication attempts (10 to 50 invalid logins against a known account) and confirm with the defender whether an alert fired and which log entries were created
- Send a small set of safe but anomalous payloads (path traversal probes, suspicious user-agents, payloads that match common WAF rules) and verify whether they produced log lines and whether anyone was alerted
- Trigger administrative actions (privilege change, MFA reset, API key rotation) under test accounts and check that each event reaches the audit log with actor, action, target, source IP, and timestamp
- Pair this with a missing rate limiting check; see missing rate limiting for the abuse pattern that most exposes the logging gap
Interview and review
- Ask the engineering owner to demonstrate where authentication failures, access control denials, and privileged actions are logged, and how long those logs are retained in queryable storage
- Request the alerting rule list from the SIEM or detection platform and check whether at least the OWASP A09 baseline (auth failures, privilege changes, known-bad payloads, server errors) is covered
- Inspect a sample of recent logs for sensitive data leakage (passwords, session cookies, full PAN, API keys) that would create a CWE-532 exposure on top of the missing detection
- Walk the incident response runbook end-to-end with the on-call engineer; if no runbook exists, treat that as a separate finding alongside the logging gap
How to fix it
Define the security event baseline
Document the minimum set of events that must be logged: authentication success and failure, MFA challenges, password and credential changes, role and permission changes, access denials, server-side errors, input validation failures, and administrative API calls. Use OWASP ASVS V7 (Logging) and NIST SP 800-92 as references.
Capture the right context per event
Each event should record an actor identity, the action attempted, the target object, the source IP, the user-agent, the timestamp in UTC, and a correlation ID. Without context, an event line is a metric rather than an investigative artefact.
Ship logs off the host immediately
Forward logs to a centralised store (SIEM, log aggregator, or cloud-native logging service) over an authenticated channel. Logs that live only on the application host are lost on redeploy and editable by an attacker who reaches the host.
Wire alerts to security signals
At minimum, alert on repeated authentication failures from the same source, privilege escalation events, server-side errors that match exploit signatures, and unusual administrative actions. Tune for noise so that when an alert fires, the on-call responds.
Protect log integrity and retention
Use append-only storage, hash-chained logs, or write-once buckets so an attacker on the host cannot rewrite the audit trail. Set retention against the most demanding obligation in scope (PCI DSS v4 Req 10.5.1 sets 12 months online or readily available).
Strip sensitive data before logging
Mask or omit passwords, session tokens, API keys, full payment card numbers, and personal data fields before they reach the log writer. Add automated tests that fail the build when known-sensitive fields appear in log fixtures.
Wire logs to an incident response runbook
Pair every alert class to a runbook step (triage owner, escalation path, containment action). Without an operational response, the logging programme is a data exhaust rather than a control.
Reporting insufficient logging as a finding
Pentesters often under-write A09 because the impact is indirect. The strongest writeups separate the control gap from the demonstrated impact. State the missing event coverage explicitly (which events, which assets), tie the gap to a paired finding from the same engagement (an authentication weakness that should have produced an alert, an IDOR that should have logged the access denial), and recommend remediation in the order a defender would action it: define the event baseline first, then ship logs off-host, then alerting, then retention and integrity controls.
On retest, verify that each item in the original gap list now produces a log line with the expected context fields, and that at least one alert rule fires when the test scenario is replayed. SecPortal lets you pair the retest result to the original finding, so the verification evidence (the log query, the alert screenshot, the runbook step) lives next to the original gap on a single record. See the retesting workflow for the full pairing pattern.
For engagements that produce many A09-adjacent findings (missing auth event coverage, missing privileged action logging, missing alert rules), keep them as separate records rather than one umbrella finding. The remediation owners and SLAs are usually different per gap, and the remediation tracking workflow gives stakeholders a clearer picture when each gap closes independently.
Compliance impact
OWASP Top 10
A09:2021 – Security Logging and Monitoring Failures
ISO 27001
A.8.15 Logging, A.8.16 Monitoring activities
SOC 2
CC7.2 System monitoring, CC7.3 Incident response
PCI DSS v4
Requirement 10 – Log and monitor all access
NIS2 Directive
Article 21 risk measures, Article 23 incident reporting
NIST CSF
DE.AE Anomalies and events, DE.CM Continuous monitoring
Related vulnerabilities
Make logging and monitoring a tracked finding
SecPortal lets you log A09 detection gaps as findings, map them to OWASP, ISO 27001, SOC 2, and PCI DSS, and track remediation through to verified close. Start free.
No credit card required. Free plan available forever.