A record is useful when it answers a question

When investigating an incident, a log should show who performed an action, which object it concerned and its outcome. OWASP recommends recording when, where, who and what. Fields are chosen for the questions the team will need to investigate.

Imagine a changed delivery address

Imagine a fictional online shop. A customer says they entered another address, while an operator sees an updated record. The log says the order was saved but omits the change's origin. It could have come from the customer, an employee or automatic directory correction. One line cannot justify choosing an explanation.

The investigation would benefit from an order number, operation type, work account or service, timestamp and outcome. The full address need not appear in every technical log. Decide beforehand where important change history lives and what information is available to someone investigating a particular request.

One operation crosses several systems

A button press can trigger a database write, a queued task and a call to a delivery service. A shared operation identifier connects these transitions into one story. Without it, specialists compare similar timestamps and guess whether messages concern the same order.

Distinguish the event, an execution attempt and the final outcome. Retrying delivery after a temporary error does not necessarily mean another order. Giving all three the same label creates misleading conclusions. Mark explicitly where a new step starts and where an existing one repeats.

Time can be ambiguous too

An event may occur on a device and reach a central collector later. Action time and record-receipt time answer different questions. With transmission delays, a sorted log may suggest a convincing but incorrect sequence. A timezone and consistent time representation reduce confusion.

For a practice investigation, choose a queue or unreliable-connection scenario. Establish whether the records reveal waiting time and actual execution time. If only log-arrival time is visible, it cannot measure the user's service speed.

Excess data creates another problem

OWASP warns against unjustified logging of secrets and sensitive information. A password, connection token or complete document does not become safe because it appears in a technical section. Define log access, retention and deletion alongside its purpose.

Check collection itself too: do records still arrive after an application update, remain available during failure and trigger attention when a source falls silent? No logged error may mean logging stopped. Distinguish that from uneventful operation.

Test one investigation

Take an anonymised example of an authorised change and ask a colleague to reconstruct its history using available records alone. Have them separate verified facts from assumptions. Record visible transitions, proven outcomes and broken connections.

Sources