Logging for Incidents, Not for Dashboards
Most logging strategies get built to answer “what does normal look like” — the questions a dashboard needs. Incident response needs the opposite: enough detail to reconstruct exactly what an attacker did, in order, across systems that don’t share a clock or a request ID. Those are different design goals, and optimizing for one quietly starves the other.
Correlation IDs matter more than log volume
Teams often respond to “we couldn’t reconstruct the incident” by logging more of everything, which mostly adds noise. The actual gap is usually that a request touching five services produces five sets of logs with no shared identifier linking them. A consistent correlation ID propagated through every service call turns a volume problem into a query problem — you can pull the full story in one search instead of manually time-correlating timestamps across systems that drift by seconds.
Log the auth decision, not just the auth attempt
Most systems log “login succeeded” or “login failed” but not why an authorization check passed or failed for a specific resource — which role, which policy, which condition matched. During an incident, “did this account have access to this resource, and under what policy” is one of the first questions asked, and without decision-level logging, answering it means reverse-engineering the access control logic from scratch under time pressure.
Retention matters more than most teams budget for
Attackers increasingly wait weeks or months between initial access and objective — meaning the logs you need to reconstruct the intrusion may have already rolled off retention by the time you’re investigating. Check your actual log retention against your industry’s typical dwell time, not against your storage budget’s comfort zone; a shorter retention window than your realistic detection lag means some incidents are unreconstructable by design, regardless of how good your logging schema is.