Log events that help you detect abuse and reconstruct an incident: authentication results, authorization failures, input validation failures, changes to sensitive objects, key and token operations and unexpected network failures. Record who, what, when, from where and the outcome, and keep secrets out.
Where the list comes from
The OWASP Logging Cheat Sheet says the level of security monitoring should be set during requirements and design and be proportionate to risk. Its list of events worth logging includes access to sensitive data, encryption activities such as key use or rotation, creation and deletion of system level objects, data import and export, submission of user generated content such as file uploads, deserialization failures, and network connection failures including backend TLS and certificate validation failures. It also mentions requests with an unexpected HTTP verb.
Add to that the classic authentication and authorization events, since they are the first things responders ask about.
A practical event list
| Category | Examples |
|---|---|
| Authentication | Login success and failure, MFA challenge, password or token reset |
| Authorization | Access denied, role or permission change, privilege use |
| Input handling | Validation failures, rejected uploads, deserialization errors |
| Data access | Reads of sensitive records, exports, bulk downloads |
| Configuration | Changes to settings, feature flags, secrets references |
| Cryptography | Key creation, rotation, failed signature or certificate checks |
| Service to service | Unexpected caller, failed mutual TLS, unexpected verb or path |
| Lifecycle | Startup, shutdown, version, config load result |
Fields that make a log line useful
- A timestamp in a consistent time zone with synchronized clocks. OWASP lists time synchronization across servers as a requirement.
- An event type from a fixed vocabulary.
- The actor: user, service identity or token ID, never the token itself.
- The target: resource type and identifier.
- The outcome: success, failure and a reason code.
- The source: IP address or calling service, noting that forwarded headers can be forged; see the first hop in X-Forwarded-For is attacker controlled.
- A correlation or trace ID so you can follow a request across services; see correlation ID vs trace ID.
Practical rules
- Encode and sanitize log data so users cannot inject line breaks or delimiters. OWASP calls for this explicitly, and our guide on log injection covers it.
- Make sure a failure in logging does not stop the app or leak data, which OWASP also lists.
- Write to stdout in a structured format and let the platform route it, as twelve-factor suggests; see stdout or files.
- Decide retention and who can read logs, since they may contain personal data.
Avoid the two extremes
Logging nothing leaves you blind. Logging everything buries signal, costs money and increases the chance you record something sensitive. Start with the table, test it with an incident scenario and add events when you find gaps. A good test: if an account was taken over yesterday, can your logs show when, from where and what it touched?
Quick check
Should I log every request?
Not necessarily in detail. Log security relevant events with enough context, and keep full request bodies out because they often contain sensitive data.
Do I log failed logins or successful ones?
Both. Failures show attacks in progress, and successes after many failures show a likely compromise.
Where should microservice logs go?
The app should write an event stream to stdout, and the platform should collect and route it to storage you control with access limits.
Where Safeguard fits
Safeguard's compliance and evidence automation helps you keep records that show logging and monitoring controls operating, which supports audit conversations without claiming a certification. See the free scan for the code and dependency side.
Sources
Last reviewed: 19 October 2026.
