Logging: What to Log and What Not To
On this page
Effective logging is a balancing act: capture enough to reconstruct an incident, without writing secrets into a file half the company can read. Log too little and an investigation hits a dead end; log the wrong things and your logs become a breach of their own. Knowing what to log — and what never to — is a real security skill, and the foundation of log management.
What to log#
Prioritize security-relevant events that answer “who did what, when, and did it work?”:
| Log | Why |
|---|---|
| Authentication (success + failure) | Detect brute force, account compromise |
| Authorization failures | Spot access-control probing |
| Privilege / account changes | Catch escalation and backdoor accounts |
| Access to sensitive data | Know what was touched |
| Admin actions | Accountability for powerful operations |
| Input validation failures | Early sign of attack attempts |
Each needs the essentials: who, what, when, where, and outcome — with synchronized timestamps.
What never to log#
Logs are widely accessible and long-lived, so anything sensitive in them is effectively leaked:
- Passwords and secrets — in any form.
- Full payment card numbers, and more personal data than necessary.
- Session tokens and API keys — logging them enables impersonation.
Mask or omit these while keeping the surrounding context (log that a login happened, never the password).
Knowing what to log makes detection possible and privacy-safe. More at the Defense & Hardening hub.
Frequently asked questions#
What events should you log for security?
Authentication attempts (success and failure), authorization failures, privilege and account changes, access to sensitive data, administrative actions, input validation failures, and significant application errors. The goal is to capture who did what, when, and whether it succeeded — enough to reconstruct events during an investigation.
What should you never log?
Never log secrets or sensitive data in plaintext: passwords, full payment card numbers, API keys and tokens, session identifiers, and more personal data than you need. Logs are widely accessible and long-lived, so a secret written to a log is a secret leaked. Mask or omit sensitive values while keeping the security-relevant context.