APP-009 Change Management
Description
All changes to production systems, applications, infrastructure, and configuration are subject to a formal change management process. Changes are documented, risk-assessed, tested, and approved before deployment. Emergency changes follow an expedited but documented process. Changes are logged with the initiator, approver, and timestamp. Rollback procedures are defined.
Rationale
Uncontrolled changes are a primary cause of outages and security incidents. Formal change management ensures changes are reviewed for impact and traceable to authorised individuals.
Framework Mappings (6)
| CCC-01 | Change Management Policy and Procedures | full |
| CCC-03 | Change Management Technology | full |
| 8.32 | Change management | full |
| CM-3 | Configuration Change Control | full |
| CM-4 | Impact Analyses | full |
| CC8.1 | Change Management | full |
Evidence (2)
Change request and approval records for recent production changes, showing that each change was documented, risk-assessed, and approved before deployment.
Example: ServiceNow, Jira, or equivalent change management ticket export for production changes in the last 30 days, each showing: change description, risk assessment, approver(s), approval timestamp, deployment timestamp, and rollback plan.
Test: Request a 30-day sample of production change records (aim for ≥ 10 tickets). For each change, verify: (1) a change request ticket exists before the deployment timestamp, (2) an approver distinct from the change initiator approved the change, (3) a risk assessment or impact analysis is present, (4) a rollback procedure is documented, (5) emergency changes have an expedited approval record (not zero approvals).
Deployment pipeline and infrastructure audit logs confirming that production changes were made only through approved, traceable change paths.
Example: AWS CloudTrail, GitHub deployment event log, or CI/CD platform deployment history for the last 30 days showing each production deployment with the initiating actor, pipeline run ID, and timestamp. Any out-of-band changes (direct console access) should appear in CloudTrail with an explanation.
Test: Cross-reference the CI/CD deployment log against the change management ticket list for the last 30 days. Verify: (1) every production deployment in the log has a corresponding approved change record, (2) no ad-hoc or out-of-band production changes are present in CloudTrail without a corresponding emergency change ticket, (3) the initiating actor for each deployment is traceable to a named individual.
Questions (2)
Are all changes to production systems, applications, infrastructure, and configuration subject to a formal change management process including documentation, risk assessment, approval, and rollback procedures?
Every production change — including infrastructure and configuration changes — must have a traceable record. Emergency changes require an expedited but still documented approval, not zero oversight.
How are production changes authorised and deployed in your organisation?
Every production deployment should be traceable to an approved change record. The ability to audit who approved what change, and when, is a key audit expectation.