What should an organisation preserve during an incident?¶
Preserve a time-aligned record of the affected systems, relevant activity and response decisions. The evidence usually extends beyond the device on which the incident was first noticed.
Build an incident-wide evidence map¶
Identify affected services, accounts, users, devices, applications, providers and the likely time window. Relevant sources may include authentication and audit events, security alerts, network records, email and messaging, cloud activity, administrative changes, configuration and backups. Record which sources are volatile, rotate quickly or need provider preservation.
Capture time zones, clock differences, source systems and collection scope. No single security console should be assumed to contain a complete chronology; gaps and different retention periods need to remain visible.
Preserve the response as well as the event¶
Incident tickets, internal communications, decision logs, change records and exchanges with suppliers or responders explain why systems were isolated, accounts disabled or services rebuilt. Record before-and-after states and every containment action that changed the environment.
Assign system owners and authority for preservation or access. Coordinate technical response with continuity, legal, HR and safeguarding needs where relevant. For exported material, document source, tool, operator, time and scope and maintain continuity in approved storage.
Key takeaway
Preserve an incident across systems, providers and decision records, with enough timing and collection detail to distinguish the original activity from changes made during response.
