How can you prevent insufficient logging and monitoring? The OWASP A09 gap, an audit checklist and a policy template

Turn on logging for 5 security events today, before anything else: failed logins, successful logins, permission denials, changes to roles or payment details, and every admin action, each with who, when and from where. That is the first answer to how can you prevent insufficient logging and monitoring. The second is an alert a person reads when those events spike.

OWASP A09 in plain words: what “insufficient logging and monitoring” means

Insufficient logging and monitoring means an app does not record security-relevant events, or records them where nobody looks, so attacks go unnoticed and cannot be reconstructed. OWASP has listed it in 3 editions of its Top 10: A10 in 2017, A09 in 2021, and A09 again in 2025 under a new name.

That first sentence is my definition of insufficient logging and monitoring; OWASP defines the category through a list of failures, quoted below. This page is the security layer of logging and monitoring for a small SaaS: which events to record, where the records live, which alerts to set, and the two documents a reviewer will ask you for.

Security logging and monitoring failures were previously known as Insufficient Logging & Monitoring, number 10 in OWASP’s Top 10 of 2017. OWASP’s 2021 introduction says the category “is expanded to include more types of failures”, and in 2021 it became A09, Security Logging and Monitoring Failures. OWASP’s A09:2025 page keeps it at #9, with “a slight name change to emphasize the alerting function needed to induce action on relevant logging events.”

The weaknesses included in security logging and monitoring failures are listed on OWASP’s A09:2021 page, nine in all; among them:

• auditable events, such as logins, failed logins and high-value transactions, are not logged;
• warnings and errors generate no, inadequate or unclear log messages;
• logs of applications and APIs are not monitored for suspicious activity;
• logs are only stored locally;
• appropriate alerting thresholds and response escalation processes are not in place or effective;
• penetration tests and DAST scans do not trigger alerts.

The same page maps four CWEs to the category, with the titles MITRE gives them:

• CWE-778 Insufficient Logging
• CWE-117 Improper Output Neutralization for Logs
• CWE-223 Omission of Security-relevant Information
• CWE-532 Insertion of Sensitive Information into Log File

Two of the four describe logging and monitoring that exists but is insecure: CWE-117 covers log data that is not correctly encoded, which OWASP says leaves you open to “injections or attacks on the logging or monitoring systems”, and CWE-532 covers sensitive data written into the log.

OWASP’s overview says logging and monitoring “can be challenging to test, often involving interviews or asking if attacks were detected during a penetration test,” and “There isn’t much CVE/CVSS data for this category.” That is why a security logging and monitoring failures vulnerability is rarely what a scanner reports and usually what a reviewer asks about, and why the fix for an insufficient logging and monitoring vulnerability is evidence you can show, not a patch (my reading). Where AI-built apps sit on the rest of the list is covered in where AI-built apps land on the OWASP Top 10.

Why are security logging and monitoring failures critical?

Security logging and monitoring failures are critical because they decide how long an attacker stays unnoticed and what you can prove afterwards. Without security logs, 4 questions have no answer: who got in, what they touched, when it started, and who must be told.

The risk associated with security logging and monitoring failures is time and proof: without security logs a breach is found late, its extent cannot be bounded, and the company cannot show a customer what was and was not touched (my reading). Logging and monitoring in cyber security exist to shorten the first and supply the second. The table below is mine.

The audit events behind the second row are designed in audit logging best practices, and whether and when a leak of personal data has to be reported turns on what counts as a GDPR personal data breach.

OWASP’s 2021 page gives three example attack scenarios, and they work as real-life examples of security logging and monitoring failures, in the page’s order:

• A children’s health plan provider’s website operator “couldn’t detect a breach due to a lack of monitoring and logging”; an external party told the provider an attacker had accessed and modified thousands of sensitive health records, and the breach “could have been in progress since 2013, a period of more than seven years.”
• A major Indian airline’s breach of passengers’ personal data “occurred at a third-party cloud hosting provider, who notified the airline of the breach after some time.”
• A major European airline “suffered a GDPR reportable breach”, reportedly through payment application vulnerabilities, with more than 400,000 customer payment records harvested.

In the first two, the company learned of the breach from someone else: an external party in one, its cloud hosting provider, after some time, in the other. Read as insufficient logging and monitoring examples, they show what the vulnerability costs after an attack: the company no longer decides who finds out, or when (my reading).

Across my June and July 2026 audits, 17 of the 21 third-party apps had no error tracking or alerting: when a user hits an error, nothing records it. Those 21 are 11 public vibe-coded apps I audited in depth and 10 more third-party apps I audited blind as a held-out set, a selected set rather than a random sample, so the figure is not a rate for AI-built apps in general.

How can you prevent insufficient logging and monitoring? Five controls, in order

Preventing insufficient logging and monitoring takes 5 controls in order: log the security events with who, when and from where; keep secrets out of the logs; store them where the app cannot rewrite them; alert on five patterns; and trigger each event on purpose to confirm the line and the alert.

What you should put in place against insufficient logging and monitoring, to prevent it rather than discover it after a breach, is this list:

1. 01 Log the security events: ten of them, each line with the same eight fields.
2. 02 Keep passwords, tokens, keys and unneeded personal data out of those lines.
3. 03 Send the lines somewhere the app can write to but cannot delete from, readable by a few named people, kept long enough to investigate.
4. 04 Alert on five patterns, so a person reads the logs while it still matters.
5. 05 Rehearse: trigger each event on purpose and confirm both the log line and the alert.

These are security log monitoring best practices drawn from the “How to Prevent” list on OWASP’s A09:2021 page, which says developers “should implement some or all the following controls, depending on the risk of the application,” and from OWASP’s Logging Cheat Sheet. The order is mine. My working rule is that a small team gets through all five in about a week. Insufficient logging and monitoring prevention starts with the first four, in the sections below; the fifth, the rehearsal, is the audit checklist further down.

Security logging: which events to log, and what a reviewer looks for

Security logging for a small SaaS covers 10 events on my list: logins that succeed and fail, password and email changes, MFA changes, permission denials, role changes, admin actions, exports and bulk deletes, key creation, and payment changes. Each line carries 8 fields, including the actor, the tenant, the source address and the outcome.

The list is my cut, for a small SaaS, of the cheat sheet’s “Which events to log” section, which itself warns that “There is no one size fits all solution.” Some examples of security logs a reviewer asks for are the rows of this table; the “why” column is mine.

The eight fields on every line are: timestamp in UTC, actor id, tenant id, source IP and user agent, the action, the target, the outcome, and a request id. They are my cut of the cheat sheet’s rule that logs “must record ‘when, where, who and what’ for each event,” plus the action, object and result status it suggests recording, and its “interaction identifier” for joining lines. One line, with made-up values:

{ "timestamp": "2026-01-15T09:42:07Z", "actor_id": "usr_1001",
  "tenant_id": "org_2002",
  "source": { "ip": "203.0.113.24", "user_agent": "Mozilla/5.0" },
  "action": "role.changed", "target": "usr_3003",
  "outcome": "success", "request_id": "req_7f3a9c" }

A user access log is rows one, two and five read together for one user: every sign-in, every failure and every refusal. What should be logged in an audit log for role changes, deletions and billing is a design of its own, covered in the audit logging article linked above. The shape of the line itself is in how to do logging in a web app, and the API security checklist has an API-side version of this list as its check 10.

The types of security logs a small app has, sorted by where the security logging happens, are five: the application’s own events, the auth provider’s log, the database’s log, the host’s or CDN’s request log, and the cloud account’s audit trail. On a managed stack most of these exist already, and the work is knowing where each one is and turning on the ones that are off. Supabase’s auth audit logs are one example: they are “automatically captured for all authentication events,” read from external log storage “accessible through the dashboard,” and can also be written to the auth.audit_log_entries table with the “Write audit logs to the database” toggle under Authentication. Supabase’s audit-log page does not say how long they are kept, and its Logs docs say only that retention “depends on your pricing plan” (checked 2026-09-28).

What must never be in a security log

One rule is specific to security events: log that a login failed and for which account id, never what was typed into the password field. The full exclusion list and the redaction method are in error logging best practices, which lists what never goes in a log. MITRE files this failure as CWE-532, listed with the others above.

One of the apps I audited in June and July 2026, a medical-advice app, printed patient vitals and its AI provider key straight into the server logs, making a second, less-guarded copy of both. Tracing copies like these is the job of a GDPR data map.

Where the logs go, so an attacker cannot erase them

Security logs belong outside the thing they describe: a separate log service or bucket the app can write to and cannot delete from, readable by two or three named people (my working rule), timestamped in UTC, and kept long enough to investigate something found months later.

OWASP lists “Logs are only stored locally” as a failure. Among the controls it says to implement some or all of, depending on the risk of the application, is an audit trail for high-value transactions “with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.” For a small app I read that as: ship security events to a separate log service or storage bucket, and give the app a credential that can add lines and cannot remove or overwrite them. If the logs sit in your own database, the cheat sheet prefers “a separate database account that is only used for writing log data.” The read list stays short because logs “may contain personal and other sensitive information.”

Retention and access in general are the “Define retention, access, and failure behavior” section of the error logging article linked above, and the retention windows themselves are a separate question: how long to keep application logs.

Web security monitoring: the five alerts that turn logs into detection

Web security monitoring for a small SaaS is 5 alerts: a burst of failed logins, a burst of permission denials for one user, an admin grant or new API key out of hours, an unusually large export or delete, and the log stream going silent.

Monitoring means someone, or something, reading the logs while the answer still changes what you do. The table is mine.

Two of the five, repeated authorization denials and a log destination that goes quiet, are also on the general alert list in the error logging article linked above. The cheat sheet asks for the same thing as the silence alert in its own words: “Enable processes to detect whether logging has stopped.”

Real-time security monitoring here means minutes, which is my working rule for an app this size, and a log service’s alert rules or an error tracker’s alerts can do that on a plan that includes alert rules and the destination you need. Which destinations each service’s plans include, and who is on call, are Slack alerting questions; the threshold numbers come down to how to alert on error rate spikes; performance signals such as latency are in application monitoring best practices for a small SaaS.

The same five alerts explain the rest of the monitoring vocabulary. Continuous security monitoring, in my words, is these alerts running all the time instead of a quarterly look at the logs; for a small app, that is all continuous monitoring in cyber security needs to mean. Security monitoring software comes in three kinds: a log service’s alert rules, an error tracker’s alerts, and a SIEM, which collects and correlates logs and raises alerts. Of those security monitoring tools, I’d start a small app on the first two. Cyber threat monitoring adds watching for known attacker behavior on top of your own events, and real time threat monitoring means someone doing that around the clock, which in practice is a managed service (my definitions). In my view a small SaaS buys a SIEM or a managed service when a customer contract or a framework asks for one. Information security monitoring for a team of three is these five alerts plus someone who reads them; IT security monitoring of laptops and office networks is a different job, not covered here.

How to check your own app: the logging and monitoring audit checklist

A logging and monitoring audit checklist is 12 lines, each with evidence a reviewer can see: the events produce lines, the lines have the fields, no secrets appear, the logs leave the host and cannot be deleted, the alerts fire, and someone reviews them about once a month (my working rule).

What should be included in an audit checklist is evidence, not intentions: the point is to review complete logging, not whether a logger exists, so each line below names what to show. Run it against staging, never against someone else’s system.

The secrets search in line three is where an empty result can mislead. On Vercel, runtime logs are kept for “1 hour of logs” on Hobby and “1 day of logs” on Pro, and free-text search “is limited to the message and requestPath field,” so a search run after that window, or for a value that sits in another field, finds nothing whether or not the secret was logged. Supabase says of its auth audit logs that “There may be a short delay before logs appear,” which is why line eight waits.

Lines 1, 3, 5 and 8 are the ones to run yourself and keep the output of. Kept together, those outputs are the report, so the list also works as an IT audit checklist for logging, monitoring and reporting. It is a fair audit logging requirements checklist for a small app, though a customer or a framework may add requirements of its own. In the security questionnaire, one row asks all of this at once.

On the Production Hardening Sprint, we verify deliverable 8.1, Structured, sanitized logs, this way: trace a test request across services and check log content for sensitive fields. We verify deliverable 1.10, Sensitive-action audit log, this way: trigger the listed actions and verify accurate, access-controlled audit entries.

The logging and monitoring policy document

A logging and monitoring policy is a one-page document with 9 parts: scope, events, fields, exclusions, storage and access, retention, alerts, review, and owner. It should promise only what the team does, because a reviewer checks the policy against the logs, not against a framework.

The guidelines a logging and monitoring policy sets are those nine parts, and the block below is a security logging and monitoring policy template written for a team of three, free to copy. Parts two and seven make it an audit logging and monitoring policy as well as a security logging policy: it says what is recorded about who did what, and who hears about it. If a customer asks for your audit log policy, this is the document to send. Read it as a logging policy example and replace every bracket with your own systems and names.

LOGGING AND MONITORING POLICY
[Company] · version [date]

Purpose and scope: security logging and alerting for [app], its API,
  its database, its auth provider and its hosting account.
Events logged: sign-ins that succeed and fail, password and email changes,
  MFA changes, permission denials, role changes, admin actions and
  impersonation, exports and bulk deletes, API key changes, payment changes.
Fields: timestamp (UTC), actor id, tenant id, source IP and user agent,
  action, target, outcome, request id.
Never logged: passwords, tokens, API keys, session ids, card data, and
  personal data beyond the fields above. Redaction lives in [file].
Storage and access: logs go to [log service or bucket]. The app can
  write and cannot delete. Read access: [name], [name].
Retention: security events are kept for [period], then deleted by [how].
Alerts: failed-login burst, permission-denial burst, admin grant or new
  key out of hours, large export or delete, silence. They go to
  [channel]; [name] responds in working hours, [name] otherwise.
Review: [name] reviews security events [how often] and records each
  review in [place]. Evidence kept: review notes, test alerts, the
  completed audit checklist.
Owner and date: owner [name]. Approved [date]. Next review [date].

Write it so a team of three can keep every promise in it: a policy that claims daily review nobody does is worse in diligence than one that says monthly (my reading).

Keep what a framework requires apart from good practice. These nine parts are good practice, and logging and monitoring requirements set by a framework or a contract are a separate list you check the document against. An ISO 27001 logging and monitoring policy template is this same document with each part mapped to the standard’s Annex A controls (my reading). The ISO 27001 requirements for logging and monitoring are in the standard’s own text, which is not reproduced here, and this page names no control numbers: take them from the standard itself. Scope, the statement of applicability and certification cost are a separate topic: ISO 27001 for a small SaaS and what certification costs. So is what a SOC 2 report asks of your logs: SOC 2 certification in plain words.

For writing a logging and monitoring standard of your own, NIST SP 800-92, the Guide to Computer Security Log Management, published in September 2006, is the free government reference. Its revision, retitled Cybersecurity Log Management Planning Guide, was released as an initial public draft on October 11, 2023. This page is not legal or compliance advice, and filling in the template does not make anyone compliant or certified.

Where the sprint does this

In the Production Hardening Sprint’s Logging, monitoring & alerting area, we add structured request logs with correlation IDs and appropriate user references and exclude passwords, tokens, and unnecessary personal data (8.1) ; alert on error spikes, latency, connection pressure, and queue backlog (8.3) ; route alerts to the designated Slack or email destination and tune thresholds to reduce noise (8.4) ; and set and document log retention across the application’s services (8.5). Outside that area, we log role changes, deletions, and billing changes with the actor, action, and time and protect access to the log (1.10) , and review the application against the OWASP Top 10 and record findings, fixes, and evidence by category (3.7). How 8.1 and 1.10 are verified is in the paragraph after the checklist above. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Every deliverable and its verify step is listed in the published scope.

Common questions about security logs and alerting

Is there a cheat sheet for OWASP logging guidelines?

Yes. OWASP’s Logging Cheat Sheet is “focused on providing developers with concentrated guidance on building application logging mechanisms, especially related to security logging”: which events to log, what each entry records, what to exclude, and how to protect the logs. Its companion, the Application Logging Vocabulary Cheat Sheet, “proposes a standard vocabulary for logging security events,” so alerts can key on consistent event names.

What are the security considerations for logging?

The cheat sheet’s considerations include keeping secrets out (“Authentication passwords”, “Access tokens” and “Encryption keys and other primary secrets” are on its exclusion list), sanitizing and encoding event data so it cannot inject into the log (“Encode data correctly for the output (logged) format”), and protecting stored logs from “unauthorized access, modification and deletion.” Its full exclusion list, and how to redact before an event leaves the process, is in the error logging article linked above.

What type of security control is log monitoring?

Log monitoring is a detective control, in my reading: it does not stop an attack, it finds what the preventive controls such as authentication and access checks missed, and it starts the response. NIST’s Cybersecurity Framework 2.0 puts continuous monitoring under its Detect function, where “Possible cybersecurity attacks and compromises are found and analyzed” and “Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events.”

What is SIEM vs syslog?

Syslog is a protocol and a SIEM is a system. RFC 5424 describes the syslog protocol as one “which is used to convey event notification messages.” A SIEM (security information and event management) is a product that gathers logs from many sources, links related events and raises alerts (my definition); the Logging Cheat Sheet lists it as a centralized log collection and management system. Syslog is one of the ways logs can reach a SIEM.

What are the five best practices for log analysis?

My five: one consistent format for every line; UTC timestamps; a request id your app sets and passes along, so lines join up; saved searches for the five alert patterns; and a review about once a month with a note kept. For depth, NIST SP 800-92 is the free reference.