DDailyWF

Change vs Incident

Distinguish planned change from unplanned service disruption.

Purpose

Incident work needs fast classification, clear communication, containment decisions, impact tracking, and follow-up ownership. A small team can stay lightweight while still preserving a timeline and decision trail.

Plain meaning

Change vs Incident is included as a practical term because teams often use it inconsistently. Before a workflow or policy can work, the people using it need the same operating definition.

How to use this term

  • Use the term in decisions, not as decoration.
  • Pair it with an owner, evidence source, or review trigger when possible.
  • If people disagree about meaning, add a short local definition to the relevant template or policy.

When to use

  • When the work repeats often enough that memory is no longer reliable.
  • When more than one person may request, perform, review, or inherit the work.
  • When risk, approval, evidence, or handoff needs to be visible later.

Common failure modes

  • Response starts before impact is understood.
  • Containment decisions are not recorded.
  • Follow-up actions remain informal after service is restored.
  • Rollback is assumed but not practical.

Review guidance

Review this page after a material incident, after a role or system change, and on a normal cadence appropriate to its risk. During review, check whether the owner is still correct, whether inputs are still complete, whether the output is still useful, and whether related pages need updates.

External guidance

These resources are references for terminology, control thinking, or review design. DailyWF adapts the ideas into lightweight operating pages rather than reproducing full standards.