Vulnerability

Security Logging and Monitoring Failures
detect, prioritise, remediate

Security logging and monitoring failures (OWASP A09:2021) is the parent category for every situation in which an application, platform, or programme fails to capture, transport, store, monitor, alert on, or retain the security-relevant events the defender needs. It covers missing events, incomplete context, host-bound logs that never reach the central store, monitoring without detection rules, alerts without runbooks, sensitive data in log lines, and retention that falls short of the audit obligation.

Get Started Free

No credit card required. Free plan available forever.

Severity

High

CWE ID

CWE-693

OWASP Top 10

A09:2021 - Security Logging and Monitoring Failures

CVSS 3.1 Score

6.5

What are security logging and monitoring failures?

Security logging and monitoring failures is the OWASP Top 10 category that covers every situation in which an application, platform, or programme fails to capture, transport, store, monitor, alert on, or retain the security-relevant events the defender needs to detect, investigate, and report an incident. OWASP renamed the category as A09:2021 (it was previously A10:2017 Insufficient Logging and Monitoring) and broadened it from logging gaps in code to the full operational chain across the production stack. The canonical parent CWE is CWE-693 (Protection Mechanism Failure), with the A09 mapping spanning CWE-117 (improper output neutralisation for logs), CWE-223 (omission of security-relevant information), CWE-532 (insertion of sensitive information into log file), CWE-778 (insufficient logging), CWE-779 (logging of excessive data), CWE-1295 (debug messages revealing unnecessary information), and CWE-285 (improper authorization) where access decisions never reach the audit chain.

The category is a parent, not a single bug. A finding falls inside A09:2021 when authentication failures, access denials, privilege changes, administrative actions, or server-side errors are never written to a queryable log, when logs are written but stripped of the actor identity, timestamp, source address, request path, response status, or correlation identifier required to reconstruct the event, when logs are captured on the host but never shipped off the application surface and disappear at redeploy, when logs reach the central store but no alert rule reads the security signals inside them, when alerts fire but no runbook routes the on-call response, when the log retention window is shorter than the audit obligation in scope, when integrity protection is absent so an attacker on the host can edit or delete the only record of their activity, or when sensitive content (passwords, tokens, API keys, PAN, PII) is written to logs in cleartext creating a CWE-532 secondary exposure on top of the missing detection.

A09:2021 is mechanistically broader than the per-finding entries it produces. The category is the operating chain, and the entries usually seen on an engagement record are the specific findings underneath it: insufficient logging and monitoring for the most common per-application sub-pattern, information disclosure when verbose error logs and debug responses leak internal state, broken authentication where credential-stuffing and brute-force activity never trips a detection rule, and security misconfiguration when default log levels suppress security events. SecPortal records the programme view through activity log with CSV export for every workspace decision and through findings management so logging-gap findings carry the same lifecycle as any other vulnerability across detect, triage, prioritise, route, remediate, and verify.

Where A09 failures live in the operating chain

A09 reaches across every layer of the detection and response chain, and a programme that fixes only one layer surfaces only one slice of the category. The six layers below carry distinct decisions, each with its own owner, evidence trail, and audit citation.

Event capture

Which events the application, identity provider, gateway, and infrastructure write to the log stream. Authentication success and failure, MFA challenges, password and credential changes, role and permission changes, access denials, server-side errors, input validation failures, administrative API calls, and privileged data access. Events absent here cannot be detected downstream regardless of how good the SIEM is.

Context per event

What each event captures alongside the action. Actor identity, action attempted, target object, source address, user agent, timestamp in UTC, request path, response status, and a correlation identifier that ties the line to the surrounding session. A line missing the actor is a metric, not an investigative artefact.

Transport and storage

Logs forwarded from the host to a centralised, append-only store over an authenticated channel. Logs that live only on the host or container ephemeral storage rotate on redeploy and are editable by an attacker who reaches the host. The store must be queryable across services, retention windows, and incident scopes.

Monitoring and correlation

Active rules and correlation logic that read the log stream for security signals. Brute force patterns, impossible travel, privilege escalation, repeated denials, anomalous administrative actions, exploit signature matches. Logs without monitoring are data exhaust, not a control.

Alerting and runbook routing

Each security signal pairs to an alert class with a runbook step (triage owner, escalation path, containment action, communication template). Without an operational response, the alert is noise. Without tuning, the noise teaches the on-call to ignore the alert when it matters.

Retention and integrity

Append-only or hash-chained storage so an attacker cannot rewrite the audit trail, integrity verification on retrieval, and a retention window set against the most demanding obligation in scope. PCI DSS v4 Requirement 10.5.1 expects twelve months online or readily available. SOC 2 expects continuity across the audit period. NIS2 expects evidence sufficient to meet Article 23 notification timelines.

How A09 surfaces in production

OWASP names A09 as a category because the same risk shape arrives through several distinct failure modes. The four patterns below are the most common entry points for an A09 finding on an enterprise engagement record.

Missing logging

Security-relevant events are never written. Login failures, MFA challenges, role changes, denied requests, server errors, and administrative actions either default to off, write only to a console that nobody collects, or are suppressed by an overly aggressive log level filter. The chain has no first link.

Incomplete logging

Events are written but the line is missing the context needed to investigate. No actor identity, no source address, no correlation identifier, no timestamp in a standard format, or no target object. The log proves an event happened and proves nothing else.

Missing monitoring

Logs reach the central store but no rule reads the security signals inside them. Brute force, privilege escalation, repeated denials, and exploit signatures accumulate in the stream until a manual query catches up. Mean time to detect stretches into weeks.

Missing alerting and response

Detection rules fire but the alert routes nowhere actionable, or it routes to a queue where alerts sit unread, or the on-call lacks a runbook to act on the signal. The detection exists and the response does not.

Common causes

No event baseline catalogue

The programme has no documented list of events that must be logged across applications, identity providers, gateways, and infrastructure. Each team picks its own baseline at build time, and the audit reads a portfolio of inconsistent coverage rather than a single artefact.

Logging treated as developer telemetry

The logging story was designed for engineering observability (latency, throughput, error rates) without a parallel security-event channel. Security signals share the same stream as application chatter and never get the structured fields the SIEM needs.

No central log store ownership

Application teams forward logs to a store nobody owns or to multiple stores with overlapping coverage and incompatible schemas. When an incident demands a cross-service query, the responder discovers the store mid-incident.

No detection engineering function

Logs flow in and no team owns writing the rules that read them. Detection coverage grows by accident or as a reactive response to the previous incident, not as a designed posture against the threat model.

Alert volume managed by suppression

When alerts produce too much noise the team responds by widening thresholds or silencing rule classes rather than tuning detection logic. Coverage shrinks silently until the next incident reveals which signals were turned off.

No retention policy paired to obligation

Log retention is set by storage cost optimisation rather than by audit obligation, regulatory requirement, or incident-response need. The shortest retention window in the stack becomes the limit the breach investigation reads against.

How to detect A09 failures

Detection is layered. Active testing produces signals a scanner can read (a verbose error, a leaked stack trace, a missing security header that breaks alerting context), and programme-stage review surfaces the gaps a scanner cannot see (a missing event baseline, an unowned central store, an absent runbook). A defensible A09 posture runs both halves and lands the gaps on a record that distinguishes a per-application logging finding from a programme-level governance gap.

Active testing signals

SecPortal authenticated scanning generates a controlled series of failed authentication attempts, role-switch probes, denied-resource access attempts, and administrative API calls behind login, then asks the defender to confirm which events reached the central log store and which alert rules fired against the activity.
External scanning probes for verbose error pages, leaked stack traces, debug responses (CWE-1295), and information disclosure that should have been suppressed and logged. The presence of the leak on the external surface implies the absence of the corresponding internal log line.
Code scanning runs Semgrep rule packs against connected repositories for missing-logging patterns (auth flows without audit calls, admin endpoints without privilege-change logging, exception handlers that swallow the security event), CWE-117 log-injection patterns where user input flows directly into the log writer without neutralisation, and CWE-532 sensitive-data-in-logs patterns where credentials, tokens, or PII reach the log channel.
Findings management captures CWE-693, CWE-117, CWE-223, CWE-532, CWE-778, the affected component, the missing event class, the detection layer the gap sits in, and a CVSS 3.1 vector calibrated for the asset tier the missing detection runs in rather than the generic base score.

Programme-stage review

Maintain an event baseline catalogue that enumerates the minimum security events for application, identity, gateway, infrastructure, and operations layers. Tie the catalogue to OWASP ASVS V7 (Logging), NIST SP 800-92, ISO 27001 Annex A.8.15, and PCI DSS v4 Requirement 10. Without the baseline, the logging-required decision is made one feature at a time.
Own a central log store with a documented schema, an authenticated forwarding channel from every service, a query interface the responder can use during an incident, and integrity protection that survives an attacker on the writing host. Pair store ownership with the event baseline so the audit reads one coherent story.
Run a periodic detection coverage review (quarterly for regulated estates, annually at minimum) that walks the event baseline, the alert rule list, the runbook portfolio, and the recent incident retrospectives. Coverage gaps from the review land on the engagement record alongside scanner findings.
Pair every alert class to a runbook with named triage owner, escalation path, containment action, and communication template. Walk the runbook against the most recent incident drill output. If the drill exposed a missing runbook, treat it as a separate A09 finding alongside the original detection gap.

How to fix A09 failures

Define the event baseline catalogue before the logging code

Enumerate the minimum security events across application, identity, gateway, and infrastructure layers. Authentication success and failure, MFA challenges, password and credential changes, role and permission changes, access denials, server-side errors, input validation failures, administrative API calls, and privileged data access. Cite OWASP ASVS V7, NIST SP 800-92, ISO 27001 Annex A.8.15, and PCI DSS v4 Requirement 10. The catalogue is the input the logging code keys off; without it, the decision is improvised per feature.

Capture the structured context per event

Each event line should record an actor identity, the action attempted, the target object, the source address, the user agent, the request path, the response status, the timestamp in UTC ISO-8601, and a correlation identifier that ties the line to the surrounding session. Adopt a structured log format (JSON, OpenTelemetry, common event format) so every field reaches the SIEM as a named field rather than a free-text fragment.

Ship logs off the host immediately and authenticate the channel

Forward logs from every service to the central store over a mutually authenticated channel. Drop the assumption that the host-local file is the durable copy. Treat host-side rotation as an operational convenience, not as the audit record. The audit reads the central store; the host reads the recent buffer.

Strip sensitive content 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. Neutralise user-controlled content per CWE-117 to prevent log injection that corrupts downstream parsing.

Wire detection rules to the event baseline

For every event class in the baseline, write a detection rule that reads it. Brute force on the auth event, impossible travel on the location-tagged events, privilege escalation on the role-change events, repeated denials on the access-control events, anomalous administrative actions on the admin events. Tune for noise so the on-call responds when an alert fires.

Pair every alert to a runbook step

Detection without response is not a control. Each alert class names the triage owner, the escalation path, the containment action, and the communication template. Walk the runbook against tabletop drills and against the recent incident postmortems; if the runbook does not match the response the team actually performs, update the runbook.

Set retention against the most demanding obligation

PCI DSS v4 Requirement 10.5.1 expects twelve months online or readily available. SOC 2 expects continuity across the audit period. NIS2 Article 23 expects evidence sufficient to meet notification timelines. HIPAA expects six years for technical safeguards. Set the retention window against the most demanding obligation in scope and pair retention with integrity protection so the audit trail is durable.

Verify closure with a follow-up exercise

A logging or monitoring finding moves to closed only when a fresh test scenario (a controlled brute force, a denied-access probe, a privileged action) produces the expected log line, fires the expected alert, and the on-call responds per the documented runbook. Closure on documentation alone accumulates into reopen rate; closure on demonstrated detection produces durable closures.

How SecPortal records and tracks A09 findings

SecPortal is not a SIEM, is not a log aggregator, is not a SOAR platform, and does not host an alert rule engine. It is the workspace where every A09 finding lands on the engagement record alongside source-level findings, external attack-surface findings, and authenticated DAST findings so severity, ownership, evidence, fix, and retest stay on one canonical record per logging or detection gap. The flow for an A09 finding looks like this on the platform.

Run authenticated scanning behind login

Authenticated scanning generates controlled failed-login series, role-switch probes, denied-resource access attempts, and administrative API calls behind the login boundary. The defender confirms which events reached the central store and which alerts fired. Gaps land on the engagement record with the missing event class, the affected component, and the evidence captured.

Run external scanning across the verified perimeter

External scanning probes for verbose errors, leaked stack traces, debug responses, and information disclosure that suggest a missing or misconfigured log channel. The presence of the leak on the external surface implies the absence of the corresponding internal log line. Findings land with the SSL Checker, Headers Checker, and path-probe module evidence on the engagement record.

Run code scanning across connected repositories

Code scanning executes Semgrep rule packs against connected GitHub, GitLab, and Bitbucket repositories for missing-audit-call patterns, CWE-117 log-injection patterns where user input flows unsanitised into the log writer, CWE-532 sensitive-data-in-logs patterns, and exception handlers that swallow the security event. Findings carry the file path, line number, and matched rule on the engagement record.

Record findings with the A09 mapping

Findings management captures the OWASP A09:2021 category, the matching CWE family (CWE-693, CWE-117, CWE-223, CWE-532, CWE-778, CWE-779), the affected component, the missing detection layer, the evidence (test scenario, expected event, observed result), and a CVSS 3.1 vector calibrated for the asset tier the missing detection runs in rather than the generic base score.

Capture the activity log as the workspace audit chain

Activity log records every workspace decision (engagement scope, finding triage, severity override, status transition, exception approval, retest closure) with the acting user and timestamp, exports to CSV, and gives the GRC team an audit-grade record of how A09 findings moved through the programme without rebuilding the trail from spreadsheets.

Run continuous monitoring on a schedule

Continuous monitoring runs the authenticated scan, the external scan, and the code scan on daily, weekly, biweekly, or monthly cadences so detection drift, suppressed alert classes, and library upgrades that change the logging defaults surface on the canonical record without anyone re-triggering a manual scan.

Map findings against multi-framework compliance

Compliance tracking maps A09 findings against PCI DSS v4 Requirement 10 (log and monitor all access), ISO 27001 Annex A.8.15 (logging) and A.8.16 (monitoring activities), SOC 2 CC7.2 (system monitoring) and CC7.3 (incident response), NIST SP 800-53 AU family (audit and accountability) and SI-4 (information system monitoring), NIS2 Articles 21 and 23, and NIST CSF 2.0 DE.AE and DE.CM in parallel.

Capture logging-gap exceptions on the finding record

When a logging gap cannot be remediated immediately (a third-party SaaS without the expected log API, a legacy integration with no event channel, a regulated workflow with a longer migration path), the exception lives on the finding through the override pattern with named owner, compensating controls, residual-risk rationale, review cadence, and expiry rather than in a meeting note.

Verify closure through retesting workflows

The retesting workflow pairs the retest to the original finding so closure means the test scenario produces the expected log line, fires the expected alert, and the on-call responds per the documented runbook. The verified_at and resolved_at timestamps preserve the audit chain of when the change shipped and who confirmed it.

What SecPortal does not do

Honesty on capability matters when the topic is detection and response. SecPortal is not a SIEM (Splunk, Sentinel, QRadar, Chronicle, Sumo Logic, Datadog Security, Elastic Security), is not a log aggregator (Loki, Datadog Logs, Sumo Logic, CloudWatch Logs, Stackdriver), is not a SOAR platform (Tines, Torq, Palo Alto XSOAR), is not an extended detection and response platform, does not host an alert rule engine, does not ingest the live security event stream from your applications, does not federate against your identity provider for sign-in monitoring, does not parse SIEM correlation output, does not maintain an alert tuning calendar inside the workspace, does not run the on-call runbook on your behalf, does not integrate with Jira, ServiceNow, Slack, PagerDuty, Opsgenie, or any ticketing or paging system through a packaged API surface, and does not host a managed-detection-and-response (MDR) service. Programmes that need real-time event ingestion, real-time alerting, automated containment, or 24/7 SOC operations typically run a dedicated SIEM and SOAR or contract an external MDR provider and land the resulting detection-gap findings on the SecPortal engagement record through bulk finding import. The platform value is the consolidated record where every A09 finding (whether it came from native authenticated scanning, external scanning, code scanning, bulk import from an outside detection engineering review, a tabletop exercise after-action, or a manual finding entry against a runbook gap) lives alongside the rest of the security backlog with the same lifecycle, the same role-based access control, the same activity log, and the same evidence trail.

Compliance impact

OWASP ASVS

V7 Error Handling and Logging

PCI DSS

Req. 10 Log and monitor all access

ISO/IEC 27001

A.8.15 Logging, A.8.16 Monitoring activities

SOC 2

CC7.2 System Monitoring, CC7.3 Incident Response

NIST 800-53

AU Audit and Accountability, SI-4 Monitoring

NIST CSF 2.0

DE.AE Events, DE.CM Continuous Monitoring

NIS2 Directive

Article 21 Measures, Article 23 Reporting

CIS Controls

Control 8 Audit Log Management

Related vulnerabilities

Insufficient Logging and Monitoring

Information Disclosure

Broken Authentication

Security Misconfiguration

Insecure Design

Missing Rate Limiting

Sensitive Data Exposure

Hardcoded Secrets

Related features

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Vulnerability management software that tracks every finding

Every action recorded across the workspace

Monitor continuously catch regressions early

Compliance tracking without a full GRC platform

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Run A09 detection-gap findings on one engagement record

SecPortal pairs the authenticated scan, the external scan, and the code scanner with one findings record per logging or detection gap, with CVSS 3.1 severity, framework mapping, retest pairing, and an append-only activity log. Start scanning for free.