What can a log entry not prove?¶

A log entry should not be treated as proof of everything that appears to be implied by it.

Avoid this assumption: That because a system recorded an account, device, address, action and timestamp, the entry proves who acted, why they acted and what ultimately happened. Those conclusions usually require additional evidence. A log entry does not automatically prove that the named account holder performed the activity. Credentials may have been shared, stolen or used by an automated process. An existing authenticated session may have been used without the password being entered again. A service account, script, application, administrator or scheduled task may also have generated the event.

It does not necessarily prove that the recorded device name identifies one unique physical device. Names can be changed, duplicated, reused or assigned automatically. Nor does an IP address identify a particular person. It may represent a router, proxy, VPN, mobile network, cloud service or shared connection.

A timestamp does not by itself prove the precise real-world time of the activity. The system clock may be wrong, the time zone may be unclear, or the displayed time may reflect collection or ingestion rather than the original event.

The entry may not prove that an action completed. A success code might mean that a request was accepted, while a failure could relate only to one stage of a wider process. The record may also have been filtered, normalised, summarised or enriched before it reached the investigator.

Investigators should therefore preserve the source record, obtain surrounding entries and understand the field definitions, system configuration and relevant time zone. Corroborate attribution and outcome through related logs, device evidence, provider records, communications, access-control information and witness evidence.

Operational takeaway¶

Treat a log entry as evidence of what one system recorded, not as automatic proof of the person, motive, precise time or final outcome.