A deploy goes out on Friday afternoon. No approval record. No rollback plan. On Monday, the system is down and the post-incident review reveals that the change bypassed the approval process because 'it was urgent.' The audit finding writes itself.
Change management is the control most frequently cited in SOC 2 and ISO 27001 audits — and the one most frequently executed informally. A Slack message saying 'deploying now' is not an approval. A Jira ticket marked done is not a verification record.
A deploy checklist structures the process into four phases: request with scope and risk assessment, approval by the appropriate role based on change category, execution with rollback plan documented, and post-deploy verification confirming the change behaves as expected.
The critical distinction is between routine and emergency changes. Routine changes follow the full checklist. Emergency changes follow an abbreviated path — but still require a named approver, a rollback plan, and a post-deploy verification within 24 hours. The emergency path does not skip controls; it compresses the timeline.
The audit value is in the immutable record. Every deploy has a request, an approval with approver name and timestamp, a rollback plan, and a verification. When an auditor asks how changes are managed, the answer is not a policy document — it is a run history showing every change in the last cycle with evidence attached.