Checklist

OWASP logging and monitoring checklist

A checklist based on the OWASP Logging and Monitoring Cheat Sheets. Use this when designing or reviewing application logging, audit trails, and alerting.

36 items
7 sections
Reusable template

Your progress

0 of 36 items complete

complete

Saved in your browser. Sign in to Checksy to share progress with your team.

What to log

All authentication attempts (success and failure)
All access control denials and privilege escalations
All input validation failures on the server
All session lifecycle events (create, renew, expire, logout)
All changes to user roles, permissions, and secrets
All high-value business actions (payment, export, deletion)
All admin actions, especially those affecting other users

What NOT to log

No passwords, even hashed, in normal application logs
No session tokens, API keys, or JWTs
No full payment card numbers (mask all but last 4)
No personal data beyond what is required for the event
No request bodies for endpoints that accept secrets

Log entry content

Each event has a UTC timestamp from a synchronized clock
Each event records who (user/service ID) and from where (IP, user agent)
Each event records what (action) and on which resource
Each event includes an outcome (success/failure) and reason
Each event has a correlation ID linking related requests

Log integrity and storage

Logs are sent to a central system the application cannot delete
Logs are write-once or append-only at rest
Log shipping is monitored for gaps and failures
Log retention matches policy and legal requirements
Logs are encrypted in transit and at rest

Log injection and encoding

User-supplied data in logs is encoded to prevent log forging
Newlines and control characters in user input are escaped
Structured logging (JSON) is preferred over free-form strings
Log viewers render entries safely (no XSS in log dashboards)

Monitoring and alerting

Alerts fire on auth failure spikes and account lockouts
Alerts fire on access control denials in bursts
Alerts fire on changes to critical configuration or roles
Alerts have an owner and a documented response runbook
Alerts are routinely reviewed for false positives and gaps

Incident response

An incident response plan exists and is tested at least yearly
Roles and contact details are kept current
Logs and metrics are sufficient to reconstruct an incident timeline
Post-incident reviews produce concrete follow-up actions
Customers and regulators can be notified within required timeframes

Markdown source

Copy this and paste it into Checksy to import the checklist.

Show markdown Hide markdown

---
template: true
about: A checklist based on the OWASP Logging and Monitoring Cheat Sheets. Use this when designing or reviewing application logging, audit trails, and alerting.
---

# OWASP logging and monitoring checklist

## What to log

- [ ] All authentication attempts (success and failure)
- [ ] All access control denials and privilege escalations
- [ ] All input validation failures on the server
- [ ] All session lifecycle events (create, renew, expire, logout)
- [ ] All changes to user roles, permissions, and secrets
- [ ] All high-value business actions (payment, export, deletion)
- [ ] All admin actions, especially those affecting other users

## What NOT to log

- [ ] No passwords, even hashed, in normal application logs
- [ ] No session tokens, API keys, or JWTs
- [ ] No full payment card numbers (mask all but last 4)
- [ ] No personal data beyond what is required for the event
- [ ] No request bodies for endpoints that accept secrets

## Log entry content

- [ ] Each event has a UTC timestamp from a synchronized clock
- [ ] Each event records who (user/service ID) and from where (IP, user agent)
- [ ] Each event records what (action) and on which resource
- [ ] Each event includes an outcome (success/failure) and reason
- [ ] Each event has a correlation ID linking related requests

## Log integrity and storage

- [ ] Logs are sent to a central system the application cannot delete
- [ ] Logs are write-once or append-only at rest
- [ ] Log shipping is monitored for gaps and failures
- [ ] Log retention matches policy and legal requirements
- [ ] Logs are encrypted in transit and at rest

## Log injection and encoding

- [ ] User-supplied data in logs is encoded to prevent log forging
- [ ] Newlines and control characters in user input are escaped
- [ ] Structured logging (JSON) is preferred over free-form strings
- [ ] Log viewers render entries safely (no XSS in log dashboards)

## Monitoring and alerting

- [ ] Alerts fire on auth failure spikes and account lockouts
- [ ] Alerts fire on access control denials in bursts
- [ ] Alerts fire on changes to critical configuration or roles
- [ ] Alerts have an owner and a documented response runbook
- [ ] Alerts are routinely reviewed for false positives and gaps

## Incident response

- [ ] An incident response plan exists and is tested at least yearly
- [ ] Roles and contact details are kept current
- [ ] Logs and metrics are sufficient to reconstruct an incident timeline
- [ ] Post-incident reviews produce concrete follow-up actions
- [ ] Customers and regulators can be notified within required timeframes

Run this checklist for real

Save your progress, share with your team, and turn this into a reusable template. This helps you track how you improve over time.

Try Checksy More checklists