What should an organisation preserve during an incident?¶

During an incident, an organisation should preserve the systems, records and decision context needed to understand what happened and what was done in response.

Avoid this assumption: Saving a few screenshots or copying obvious files is enough. Relevant evidence may be spread across user devices, servers, cloud platforms, security tools, network systems, email, messaging, backups and third-party providers.

Start by identifying the affected services, accounts, users, devices, applications and time period.

Preserve logs, alerts, audit records, authentication events, network connections, email and messaging records, cloud activity, administrative actions and relevant configuration.

Record which systems are volatile, which logs rotate quickly and which providers may need an urgent preservation request.

Preserve incident tickets, internal chat, decision logs, change records and communications with suppliers or responders.

Do not alter retention settings, clear alerts, rebuild systems or disable accounts without recording the original state and the reason for action.

Where containment is necessary, preserve the before-and-after position and every resulting change.

Identify who owns each system and who can authorise access, preservation or disclosure.

Record time zones, clock differences and the source of each timestamp.

Do not assume that one security platform holds a complete account of the incident.

Where systems are business-critical, coordinate preservation with continuity, legal, HR, safeguarding and incident-response needs.

Maintain continuity for exported material and document the tool, operator, time, source and scope.

Operational takeaway¶

Preserve the incident across systems, providers and decision records, not just the affected device, and document every containment or collection action that changes the original state.