How should a log entry be described in an investigative report?¶

A log entry should be described by stating what the system recorded, where the record came from and what limitations affect its interpretation.

The report should separate direct observation from investigator inference.

Avoid the dangerous assumption¶

The dangerous assumption is that technical shorthand can be converted directly into a statement about what a person did.

It cannot.

A safer structure is to identify the source system, event type, account or device fields, timestamp, result and any relevant identifiers. Then explain what the entry supports and what it does not establish.

For example, it may be accurate to say that an identity platform recorded successful authentication for account X from source address Y at a stated time. It may not be accurate to say that the named account holder personally logged in.

Where the record was exported, normalised, enriched or displayed through a SIEM, say so. Record whether the time shown is source time, local time, UTC or ingestion time.

Avoid overstating words such as success, user, device, location or ownership. Use the provider or vendor definitions where available.

If the entry forms part of a wider sequence, explain how it was linked to other records. Refer to session, request, transaction or correlation identifiers rather than relying only on approximate time.

Preserve the original wording and evidence reference so another person can trace the statement back to the source. If an interpretation required specialist assistance, identify that clearly.

Operational takeaway¶

Describe a log entry as a system-recorded event with its source, fields, time and limitations, and keep any conclusion about person, intent or outcome separate and proportionate.