SOC2-CC8-CHANGE-MGMT
Change Management Process
What this control does
Formal process for requesting, approving, testing, and documenting changes to production infrastructure and systems.
Implementation guidance
Require all production changes to go through a tracked change process (GitHub PR, Jira ticket, etc.). Emergency changes require post-hoc approval and documentation within 24 hours. Maintain a change log. For infrastructure, all changes must be via IaC — no manual console edits in production.
Requirements satisfied
Why it matters
Uncontrolled production changes are the #1 source of security incidents and compliance violations — unauthorized or poorly tested modifications can introduce vulnerabilities, cause data loss, or enable lateral movement. Without a formal change log, you have no audit trail to prove compliance or investigate incidents. Change management is your detective control that catches mistakes before they go live and your forensic control that proves what changed and who approved it.
Evidence to collect
- Change log or audit trail from version control system (Git) or change tracking tool (Jira, ServiceNow) showing at least 20 recent changes with timestamps, approvers, and descriptions
- GitHub/GitLab PR records for infrastructure changes, including approvals and CI/CD pipeline logs confirming successful deployment
- Emergency change approval documentation showing post-hoc approval within 24 hours and business justification
- Infrastructure-as-Code (Terraform, CloudFormation, Helm) Git history with diffs for all production infrastructure changes from the past 90 days
Testing procedure
Auditor selects 10–15 recent production changes from the change log and verifies: (1) each has a tracked request with clear business justification, (2) documented approval from an authorized approver (and post-hoc approval within 24 hours for emergency changes), (3) evidence of testing or risk assessment before deployment, and (4) infrastructure changes deployed via IaC with a Git commit hash. Spot-check 2–3 infrastructure deployments in AWS/GCP/Azure console to confirm no manual changes exist since last documented change.
Common gotchas
Teams often skip the formal process for "quick fixes" and document them later, breaking the audit trail — enforce a hard rule that *all* production changes, no matter size, go through the process or fail deployment gates. Another trap: keeping the change log separate from Git or IaC means it drifts out of sync with reality; anchor your source of truth to version control with automated tracking (e.g., GitHub releases, merged PRs) rather than spreadsheets.