How should I document cloud-account containment?¶
Document containment as a timed change from one known account state to another.
The point is to let somebody later explain what access existed before intervention, what control was applied, and what effect that control actually had.
Record the pre-action state¶
Where operationally possible, capture:
- provider and product;
- tenant and stable account ID;
- active sessions or tokens;
- trusted devices;
- connected applications;
- roles and administrators;
- sharing or forwarding rules;
- recovery methods; and
- relevant audit events.
Use structured exports where available, with screenshots as supporting context rather than the only record.
Record each control separately¶
A containment timeline should not say only “account secured”.
It should show what actually happened:
S-8841 revoked.APP-441 consent removed.For each intervention record:
- exact time and time zone;
- authoriser;
- operator;
- interface or control used;
- expected effect;
- response or error shown; and
- later verification.
Keep the original and post-containment states distinct¶
Containment creates new provider events.
A rule removal, password change or role change may appear in later audit data. If you do not preserve the pre-action state, those responder actions can be confused with the activity you were originally investigating.
Record unavoidable gaps¶
Sometimes harm prevention has to come first.
If an account must be disabled immediately, document:
- why action could not wait;
- what evidence was captured beforehand;
- what could not be captured;
- who made the decision; and
- what later records may explain the intervention.
The practical point is: a good containment record explains both the account and the response. It should show what changed, when, why and with what measured effect.