How should an incident timeline be built?¶

Build an incident timeline from source events and preserved timestamps, not from the attack story investigators expect to find. Every entry should retain enough source and time context to be checked later.

One product's display is only one view of the incident and may mix event, collection, processing and alert times.

Normalise time without losing the original¶

For important entries, record:

• the original timestamp and time zone;
• the source system and event identifier;
• whether the time represents action, receipt, processing or display;
• known clock source, offset or drift;
• collection method; and
• any conversion applied for the working timeline.

Preserve the source value even when events are normalised to a common time zone. Where clocks conflict, show the conflict and explain any correction rather than silently forcing alignment.

Separate actions from their later effects¶

A command can be issued, queued and then executed on several devices at different times. A cloud workflow or management job may produce many downstream records from one initiating decision. Place the initiating event and its automated consequences separately so repetition is not mistaken for repeated human action.

Also distinguish first supported activity, first detection, analyst review, operational impact, containment and recovery. Events close together may belong to different sessions or actors, and gaps need not be filled with an inferred continuous narrative.

A defensible timeline can contain uncertainty. Label inferred ordering and unresolved conflicts rather than presenting them as original events.