Recover the workflow and preserve the facts.

Keep a timestamped decision record

Record observations separately from hypotheses. Note who changed what and why so responders do not repeat failed actions or lose the recovery context.

Define the next update

Tell stakeholders what is affected, what is being done and when the next update is expected. Avoid promising a recovery time before the evidence supports it.

Establish impact and preserve the timeline

Start with the affected task, the users or records involved and the time the problem was first observed. Record the environment and distinguish confirmed facts from suspected causes. A concise timeline helps responders understand what changed without repeatedly asking the same questions.

Preserve relevant logs and identifiers using the organisation's approved access and retention arrangements. Avoid copying confidential records into broad chat channels. Identify the person coordinating the response and the route for decisions that affect customers or production data. Existing support and incident procedures take precedence over this general resource. A public website form should not be assumed to provide an emergency response channel.

Contain the problem without losing recoverability

Consider whether work should be paused, a feature disabled or an earlier configuration restored. Evaluate the effect of each action on data already in flight. Stopping a worker may prevent new errors while leaving uncertain writes that still require reconciliation. Restarting everything can obscure evidence or repeat operations that already completed.

Before replaying records, establish their current state in the authoritative system. Record which operations are safe to repeat and which require review. Use an agreed change process appropriate to the incident's urgency. Keep a record of the person making each decision and the observed result. Containment is successful when it reduces harm while preserving a controlled route to recovery.

Verify restoration and learn from the event

Recovery should finish with a verified business workflow. Confirm that users can perform the affected task and that pending or inconsistent records have an owner. A process returning to a green infrastructure state is only part of that evidence. Communicate remaining limitations clearly through the agreed channels.

After the immediate response, review contributing conditions without reducing the event to individual blame. Identify gaps in validation, observability, access, change control or recovery documentation. Create a small number of corrective actions with owners and verification criteria. Add representative failures to tests or rehearsals where useful. Close the incident when the operating state and follow-up responsibilities are understood, not merely when an alert stops firing.