security-logginglisted

# Security Logging When something goes wrong, logs are how you find out what happened, who did it, and whether it's still happening. Yet logging is easy to get wrong in two opposite directions: too little (you can't reconstruct an incident) or too much (the logs themselves become a data leak). This skill gets the balance right. Two rules run through it: **log enough to answer "who did what, when" for anything sensitive** — and **never log the sensitive thing itself** (passwords, tokens, full card numbers, personal data beyond what's needed). ## When to reach for this skill Use it when adding logging to authentication events, data mutations, admin actions, or permission changes; when building an audit trail; when setting up monitoring or alerts; or when investigating an incident and asking what to look for. Also when reviewing existing logging for gaps or for accidental leakage of secrets. ## What to do ### 1. Decide what to log Security-relevant events worth recording (the "who/what/when"): - **Authentication**: login success and failure, logout, password change/reset, MFA events. Failed logins especially — they're the signal for brute-force. - **Authorization**: access denied events, privilege changes, role assignments. - **Sensitive data actions**: creation/modification/deletion of important records, exports, bulk operations. - **Admin actions**: anything an administrator does that affects others. Each entry should capture: timestamp, actor (user id — not full P