Application teams often retain everything or almost nothing. Both extremes hurt security event analytics. When every debug line sits beside authentication failures, analysts drown in volume. When only infrastructure metrics remain, application-layer abuse stays invisible.
Start by listing decisions the application already makes: login success or failure, permission denials, password resets, admin role changes, payment state transitions, and API key creation. Each of those decisions produces a natural security event candidate.
Next, ask whether a reviewer could reconstruct abuse without that message. If a stolen session token leaves no trail in your application events, anomaly analytics later has nothing to grip. Prefer structured fields — actor, action, resource, outcome, and request context — over free-text paragraphs.
Finally, separate operational noise from security-relevant outcomes. A slow database query may matter for reliability; a burst of permission denials from one client identity matters for security. Keep both if you must, but tag them so anomaly reviews can filter deliberately.
Teams we advise in Korea often begin with ten event types tied to authentication and authorization. That small set already supports meaningful anomaly questions without waiting for a perfect telemetry platform.