What should be recorded before containment?¶

Before containment, record the live technical and operational state that the action is likely to change.

Avoid this assumption: The position can be reconstructed later from logs. Some evidence may be volatile, incomplete or altered by the containment itself.

Record the date, time, time zone, affected systems, users, locations and services.

Capture visible alerts, screens, applications, logged-in accounts, active sessions, processes, network connections and remote-access indicators.

Preserve device names, IP addresses, hostnames, usernames, session IDs, ports, protocols and provider references where visible.

Record what harm is active, what evidence supports that assessment and which systems appear affected.

Identify critical dependencies, including servers, cloud services, communications, cameras, authentication and business or public-safety functions.

Record the containment options considered and the expected effect of each.

Note which systems or accounts will remain connected and any alternative access route the attacker may retain.

Do not change filters, acknowledge alerts, close sessions or refresh pages before preserving the original view unless urgent harm requires immediate action.

Record who is making the decision, their authority and any specialist advice received.

Where time is extremely limited, prioritise the most volatile and significant evidence rather than attempting a complete inventory.

Document any evidence that could not be preserved and why.

Record the containment objective in plain terms, including what harm the action is intended to stop and how success will be checked.

Operational takeaway¶

Record the live systems, sessions, connections, alerts, active harm, dependencies and decision rationale before containment changes the evidential and operational state.