What should be recorded during containment?¶

Containment should be recorded as a sequence of decisions, actions and observed results.

Avoid this assumption: The technical team can reconstruct what happened later from system logs. Logs may be incomplete, altered by the response or held across several systems.

Record the date, time, time zone, person, role and authority for each action.

Describe the specific risk being addressed, such as exfiltration, malware spread, remote access, account abuse or destructive activity.

Record the system, device, account, service, network segment or interface affected.

Document the exact action taken, including isolation, session revocation, password change, process termination, rule change, shutdown or provider request.

Preserve the visible state immediately before and after the action where practicable.

Record every resulting alert, session loss, service interruption, address change, file movement, account notification or system failure.

Note which systems, accounts or routes remained active.

Document any deviation from the agreed containment plan and why it was necessary.

Record specialist advice, organisational approvals and any legal, safeguarding or continuity consideration.

Do not summarise several actions as one event if their timing or effect differed.

Preserve incident tickets, responder notes, internal communications and change-management records.

Where an action failed or produced an unexpected result, record that directly.

Do not claim containment succeeded until the intended effect has been checked.

Record whether the action was manual, automated or provider-initiated, because that may affect both the audit trail and the ability to reproduce what happened.

Operational takeaway¶

Record containment action by action, with purpose, authority, timing, target and result, so the evidential and operational consequences can be reconstructed accurately.