What should I include in a cloud-evidence decision log?¶
Use the decision log to explain why the cloud line was opened, how its scope was chosen, what actions followed and why it was continued, changed or stopped. Technical files show system events; they do not preserve the reasoning around them.
Capture the decision inputs¶
Record the investigative question, provider or organisation, account and tenant identifiers, relevant services, time scope, record types and expected evidential value. Identify immediate retention or preservation risk, alternative evidence routes and assumptions about provider behaviour.
For each material decision, distinguish:
- verified facts and source records;
- provider or organisational statements;
- specialist interpretation;
- investigator inference and competing explanations; and
- proportionality, procedural and operational considerations.
Record the source and date of information about retention or product behaviour because it can change after the event.
Maintain the action history¶
Log contacts, requests, collections, containment, live-system interactions, responses and unavailable material. State who owned each action and when responsibility changed across teams or organisations.
Update the rationale when evidence changes scope or value. If a line is not pursued or is closed, explain whether the reason was expiry, unreliable account identification, logging limits, provider response, stronger evidence elsewhere or disproportionate further work.
Keep the log focused on judgement points rather than duplicating the complete chronology.
The point to remember
A cloud decision log makes the question, assumptions, actions and reasons traceable, including why evidence was preserved, pursued, narrowed or left unavailable.