it-incident-command

Start by recording detection time and impact scope, set provisional severity, name an incident commander and scribe, and open an authoritative incident record. Then split bounded workstreams with single owners, establish a communication cadence, and evaluate restoration options by blast radius and rollback.

A major incident typically needs an incident commander, technical lead, communications lead, scribe, workstream leads, a business liaison, and security/privacy/legal liaisons. Roles should only be assigned with confirmation, and unfilled roles must be marked explicitly.

Every update should state the current service state, confirmed user and business impact, what changed since the last update, active workstreams, any verified workaround, and the next update time. Speculative root causes should never be published; label gaps as investigating.

Resolution requires validated service through synthetic checks, telemetry, and representative user transactions, plus confirmation that backlogs, replication, data integrity, and security controls are normal. Cleared alerts alone are insufficient; the user path and data state must be verified.

Use absolute timestamps with timezone, separate observation time from event time, and label entries as observed, reported, inferred, decision, action, or result. Failed actions and reversals must be preserved rather than rewritten into a success narrative.

It coordinates response but does not grant system access or perform remediation itself; actual execution depends on available tools, permissions, and authorized operators. Permanent root-cause analysis is deferred to separate problem management after service is stable.