Could containment affect timestamps and timelines?¶

Yes. Containment can affect timestamps, event order and the way later timelines are interpreted.

Avoid this assumption: Every recorded time directly reflects the original incident. Response actions may create new login times, file access times, service restarts, clock synchronisation events and audit records.

A disconnected device may stop synchronising its clock.

A restarted system may reset uptime and generate a new sequence of events.

Cloud and provider records may use different time zones or record receipt time rather than action time.

Before containment, record the visible system time, time zone and any known clock difference.

Preserve original timestamps in context rather than copying only the displayed value.

During containment, record each action with a trusted reference time.

Note when systems are isolated, restarted, reconnected or moved between networks.

Record whether logs use local time, UTC, provider time or another standard.

Do not alter clocks to make systems match.

Where a clock is clearly wrong, record the observed difference and preserve the original setting.

After containment, identify responder-created events and any gaps caused by service interruption or log rotation.

Do not force uncertain records into an exact sequence unsupported by the evidence.

Use ranges and explain limitations where necessary.

Record any time correction, daylight-saving change, virtual-machine clock difference or provider delay identified during the response.

Preserve the original settings.

Operational takeaway¶

Preserve system time, time zone, clock differences and responder actions before containment, because isolation, restart and reconnection can create misleading timestamps and gaps in the incident timeline.