Change Management Audit: Key Control Points
A walk-through of the critical control points auditors should test in an IT change management process, from request through deployment.
Change management is consistently one of the most heavily tested general IT controls (GITCs) on the CISA exam and in real-world SOX and IT audits. A weakness in change management can undermine reliance on every automated control in the environment, because an uncontrolled change could alter application logic, disable a control, or introduce a vulnerability without detection. Understanding the full lifecycle of a change, and the key control points within it, is essential.
The Change Management Lifecycle
A well-controlled change process typically flows through request, assessment, approval, development, testing, approval to deploy, deployment, and post-implementation review. Each stage represents a distinct control point that auditors should identify and test independently rather than treating change management as a single monolithic control.
Request and Assessment
Every change should originate from a documented request that captures the business justification, scope, and requesting party. The assessment stage should evaluate risk, impact, and required testing depth. High-risk changes, such as those affecting financial reporting systems or security configurations, should trigger additional scrutiny and approval layers compared to low-risk cosmetic changes.
Approval Prior to Development
Auditors should confirm that changes are approved by an appropriate authority before development work begins, and that this approver is independent of the developer. This is a key segregation of duties point: the person requesting or building a change should not be the sole person approving it.
Testing and Quality Assurance
- User acceptance testing (UAT) performed by business representatives, not solely by developers
- Evidence of test cases, expected results, and actual results retained for audit purposes
- Regression testing for changes to complex or interdependent systems
- Segregation between development, test, and production environments
Approval to Deploy and Deployment Controls
Before a change moves to production, a separate deployment approval should be obtained, distinct from the earlier development approval. This confirms that testing was successfully completed and that the change is ready for the live environment. Deployment itself should be performed by personnel who do not have the ability to also develop or approve changes, reinforcing segregation of duties, and ideally through an automated deployment pipeline that enforces these controls programmatically.
Emergency Changes
Every mature change process includes a defined emergency change procedure for urgent fixes that cannot wait for the standard approval cycle. Auditors should verify that emergency changes still require some form of expedited approval, even if after the fact, and that all emergency changes are retrospectively reviewed by management within a defined timeframe to confirm they were appropriate and properly documented.
Post-Implementation Review
A frequently overlooked control point is post-implementation review, where the organization confirms the change achieved its intended effect without unintended side effects. This closes the loop on the change lifecycle and can catch issues that testing missed.
Auditing Approach
An effective change management audit combines walkthroughs of the documented process, a sample of changes traced end-to-end through each control point, analysis of the change ticketing system for completeness (comparing tickets against actual code deployments or configuration changes captured in system logs), and testing of segregation of duties between developers, approvers, and deployers. Auditors should be particularly alert to the possibility of undocumented changes, which can be identified by comparing production system logs or version control history against the population of approved change tickets.