Change management
Change management requires a formalized process for requesting, reviewing, testing, and approving modifications to systems, software, or infrastructure before they are deployed to production. The goal is to ensure that changes do not introduce security vulnerabilities or cause unplanned system instability.
What it means
In practice, change management is about creating a verifiable audit trail for every modification made to your production environment. It ensures that no single person can unilaterally alter the live system without oversight and that all changes are vetted against technical and business requirements.
The scope typically includes software code updates, configuration changes to cloud infrastructure (IaC), database schema modifications, and network setting adjustments. It applies to both planned feature releases and urgent patches.
The intent is risk mitigation. By requiring a separation of duties—where the person implementing the change is different from the person approving it—the organization reduces the likelihood of malicious inserts or accidental outages.
How to meet it
- Define a formal Change Management Policy that outlines what constitutes a "change" and the required steps for approval and deployment.
- Use a ticketing system (e.g., Jira, GitHub Issues) to document every change request, including the purpose of the change and the risk level.
- Implement a peer-review process via Pull Requests (PRs), requiring at least one qualified reviewer to approve code before it is merged.
- Maintain separate environments for development, testing/staging, and production to ensure changes are validated outside of the live environment.
- Require documented evidence of successful testing (e.g., QA sign-off or automated test suite results) prior to production deployment.
- Enforce technical restrictions that prevent developers from pushing code directly to production without passing through the established CI/CD pipeline and approval gates.
Evidence an auditor asks for
- The Change Management Policy document approved by management.
- A complete list of all changes made during the audit period (the "population") to be used for sampling.
- Sampled change tickets showing a clear link between the initial request, the testing results, and the final approval.
- Version control logs (e.g., GitHub/GitLab) proving that peer reviews occurred and were completed before merging.
- Evidence of separation of duties, such as system permissions showing that those who write code cannot unilaterally deploy to production without a second party's approval.
Common pitfalls
- "Emergency" changes: Failing to document urgent hotfixes or bypassing the process during an incident without performing a retrospective review and documentation.
- Lack of testing evidence: Stating that a change was tested but failing to provide logs, screenshots, or test reports as proof.
- Rubber-stamping: Having approvals in place where the reviewer simply clicks "approve" without actual verification, which can be spotted by auditors via timestamps (e.g., approval occurring seconds after the PR was opened).
- Inconsistency: Applying the process to major software releases but ignoring configuration changes made directly in a cloud console (AWS/Azure/GCP).