Change Management Controls and How to Audit Them
An uncontrolled change turns last year's tested control into an untested one.
Change management is the control over every modification to a system after it goes live: a new GST rate in the billing module, an interest calculation change in core banking, a vendor patch to the ERP. Each change is a chance to break something that worked, or to slip in something that should not be there.
For a statutory auditor relying on automated controls, change management is the general control that keeps last year's tested control the same control this year. If changes are not controlled, a test of an application control proves only that it worked on the day you looked.
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
The Change Process in ICAI's Module 3
- 1
Raise a change request
A formal request with the reason, expected benefit and, where possible, cost justification.
- 2
Define and analyse requirements
What changes (function, screen, processing), why, when, for whom and which programs are affected.
- 3
Impact analysis
Effect on related processes, interfacing programs and technology.
- 4
Approval
By the asset owner, usually the application owner; a change approval board (CAB) where several functions are affected.
- 5
Prioritise
Resolve conflicts between competing requests.
- 6
Carry out the change
Program change records kept: programmer ID, date and time, request number, before and after images of changed code.
- 7
Update documentation
Flowcharts, data dictionaries, run books and user manuals; the step most often neglected.
- 8
Test
Existing functions unaffected, performance as expected, no new security weakness; UAT and owner sign-off.
- 9
Release to production
Only after approval, with a fall-back plan; ideally by a team independent of development and testing.
- 10
Review and keep records
Post-release review where useful, and a trail of all approvals and rejections linked to the original request.
Emergency Changes
Production breaks at 11 pm on the last day of the quarter and cannot wait for a CAB meeting. Module 3 accepts this, with conditions: a special user ID with higher privileges is used, every action under it is logged and reviewed, and the normal change process is completed after the event so documents, source library and diagrams catch up.
The auditor's test is that the emergency route stays exceptional. Count emergency changes against normal ones, check each has a post-facto approval, and check who held the emergency ID and for how long.
Segregation of Duties and Its Substitutes
Uncontrolled change is mainly an access problem. Module 3's baseline separation, and the compensating controls it accepts where a small IT team cannot separate fully:
Development, test and production environments kept separate
Where it can't be done
One server hosts everything
Compensating control
Restricted, logged access per environment; independent review of changes moved
Developers have no access to test or production
Where it can't be done
The developer is also the operator
Compensating control
User management authorises and monitors every change
A librarian or release team moves code between environments
Where it can't be done
No separate release team
Compensating control
A transfer ID enabled only after approval, with its activity monitored
Developers cannot write, modify or delete production data
Where it can't be done
Support needs live data
Compensating control
Read-only access, and none to personal data where the risk warrants it
| Baseline control | Where it can't be done | Compensating control |
|---|---|---|
| Development, test and production environments kept separate | One server hosts everything | Restricted, logged access per environment; independent review of changes moved |
| Developers have no access to test or production | The developer is also the operator | User management authorises and monitors every change |
| A librarian or release team moves code between environments | No separate release team | A transfer ID enabled only after approval, with its activity monitored |
| Developers cannot write, modify or delete production data | Support needs live data | Read-only access, and none to personal data where the risk warrants it |
Quick practice on audit concepts. No signup.
Change, Configuration and Release
- Change management
- The process that requests, approves, tests and records a modification.
- Configuration management
- Keeping a baseline of each configuration item (program, module, database instance) in a configuration management database (CMDB), so every change can be traced against a known state.
- Release management
- Packaging approved changes and moving them into production in a controlled way.
How an Auditor Tests Change Management
- checkForward test: sample change requests and trace each from request to approval, testing, UAT and move to production
- checkReverse test: take changes actually made in production (from system logs or the code library) and trace them back to an approved request; this is what finds unauthorised changes
- checkCheck that access to source code and production libraries is restricted
- checkReview vendor patches: were they impact-assessed and tested before installation
- checkReview use of emergency IDs and the post-facto approvals behind them
How the DISA Assessment Test Tests This
- check_circleBest control against unauthorised program changes: segregating developers from production, not more testing
- check_circleEmergency changes: the correct answer keeps logging and post-facto approval; the trap skips documentation "because it is an emergency"
- check_circleSample selection: a sample drawn from approved tickets cannot find a change that never had a ticket
- check_circleWho approves a change: the application or asset owner, not the IT head alone
FAQs
What is the most important control in change management?expand_more
Segregation of duties: the person who writes a change should not be able to move it into production. Approval, testing and records depend on that separation holding.
How should emergency changes be controlled?expand_more
Through a defined emergency route: a privileged ID used only for the fix, every action logged and reviewed, and the full change process completed afterwards.
What is the difference between change management and configuration management?expand_more
Change management controls each modification. Configuration management keeps the baseline of every component in a CMDB, so changes can be traced against a known state.
How do auditors find unauthorised changes?expand_more
By starting from what changed in production, using logs or library records, and tracing each change back to an approved request. Testing only from the ticket list misses changes that bypassed it.
Next steps
- ITGC vs Applicationarrow_forward
- Post-Implementation Reviewarrow_forward
- ERP Auditarrow_forward
- SDLC Modelsarrow_forward
Assessment Test format, timed and scored.