Logs and telemetry

Know what the record represents

Logs are records of events generated by systems or applications. Telemetry is a broader term for information collected about system behavior and state, including events, measurements, traces, and sensor observations. Security teams use these sources to detect suspicious activity, investigate incidents, and understand whether controls are operating.

A record is useful only when its meaning is understood. A firewall may record an allowed connection attempt, an application may record a completed transaction, and an identity service may record a failed authentication. Those events answer different questions even if they share an address and a timestamp.

Plan around an investigation question

Consider a fictional learning platform. The team wants to determine whether a staff account exported a class list. Web-server logs may show a request to an export endpoint, but application events can indicate whether authorization succeeded and whether the job completed. Worker events may identify the resulting export artifact.

Collecting more infrastructure logs does not automatically fill that business-level gap. Application security logging should capture the action, actor, relevant object, and outcome without copying sensitive content unnecessarily.

The team also needs a record dictionary: what each event means, when it is generated, which fields are stable, and which settings affect collection. This documentation is part of the evidence system, not an optional convenience.

Protect the collection path

Useful events can disappear through disabled logging, full storage, expired retention, broken forwarding, or failed permissions. Monitor the collection pipeline and distinguish an empty result from a source that stopped reporting. A quiet dashboard during an outage may indicate missing visibility rather than the absence of suspicious activity.

Central storage can reduce dependence on a single compromised device, but access and retention still require deliberate control. Logs may contain personal information, internal architecture details, and operationally sensitive identifiers. Limit access to the people and processes that need it.

Avoid logging secrets such as passwords and raw access tokens. Where identifiers or request details are necessary, use minimization and safe handling appropriate to the source. Test error paths because failures may reveal more sensitive information than normal operation.

Understand the limits of absence

“No matching event was found” is a search result. “The action never occurred” is a stronger conclusion requiring reliable coverage of that action, the correct scope, sufficient retention, and a trustworthy search. Document gaps explicitly rather than turning them into reassurance.

For practice, perform one harmless authorized action and locate it across the relevant sources. Record delivery delay, timestamp interpretation, and missing fields. Then disable a test collector and observe how monitoring distinguishes the failure from normal quiet operation. Log correlation and Incident reporting and handover depend on this foundation.

Related concepts

• Security information and event management
• Cloud audit logs
• Incident timelines