ITGC Change Management Testing: Evidence and Audit Procedures
MTJ Job Solutions ITGC Training Team
Sneha worked as a QA analyst at a fintech company in Gachibowli. One Thursday evening her team pushed a small fix to the payments screen. Nobody thought about it again until the auditors arrived three weeks later. One of them pointed at a line in the change list and asked a plain question. “Show me who approved this change, who tested it and who released it.”
Sneha remembered the change. She remembered the testing too. But the approval lived in a chat message, the test result sat in a spreadsheet on someone’s laptop, and the release was done by the same developer who wrote the fix. The change had been safe. The evidence was a mess. That day she learned why ITGC change management testing matters so much, and why auditors care about proof as much as about the work itself.
This guide follows Sneha as she learns how auditors test ITGC change management. You will see the audit procedures in order, the evidence to collect, a worked example with real numbers, and the findings that appear again and again. If you are new to the subject, our simple guide on what is ITGC is a good place to start first.
What ITGC Change Management Means
Every company keeps changing its systems. Developers fix bugs, add features, update settings and move code to the live environment. ITGC change management is the set of rules that makes sure each of those changes is requested, approved, tested and released in a controlled way. Its aim is simple. Only authorised and tested changes should reach the live system, and anything else should be caught.
Think of a hospital. A nurse cannot change a medicine dose because she feels like it. A doctor writes the order, a pharmacist checks it, and the nurse gives it. Change management works the same way for systems. Several people take part, and each step leaves a record. When the records are complete, an auditor can rely on the system. When they are missing, the auditor must do far more work. Our post on the top 5 IT general controls shows where change management sits among the other control areas.
Types of Changes Auditors Look At
Not every change follows the same path. Before testing, Sneha learned to ask which kinds of change her company allows, because each kind has its own approval route and its own risk.
| Change type | Example | Usual approval path | What the auditor checks |
|---|---|---|---|
| Standard | Routine, low risk update with a fixed procedure | Pre approved template | The change really fits the approved template |
| Normal | New report, bug fix, setting change | Request, review, approval, testing, release | Every step happened in order and left evidence |
| Emergency | Urgent fix for a live outage | Quick approval, review after release | Approval was recorded and a review followed |
| Major | New system or large upgrade | Project governance and sign off | Testing, user acceptance and go live approval |
Key Risks and the Controls That Answer Them
Auditors do not test for the sake of testing. They start from a risk and then find the control that is meant to answer it. This table is the map Sneha kept beside her laptop.
| Risk | Control | Evidence that proves it |
|---|---|---|
| An unapproved change reaches the live system | Changes need approval before release | Approval record with date and approver name |
| A faulty change breaks a business process | Changes are tested before release | Test plan, test result and user sign off |
| One person controls the whole change | Requester, approver and releaser are different people | Role listing and ticket history |
| Changes are made outside the process | Live changes are compared with approved tickets | Release log matched to the change list |
| An urgent fix skips review | Emergency changes are reviewed after release | Post release review record |
ITGC Change Management Audit Procedures, Step by Step
Sneha’s mentor, a senior auditor, gave her a simple order of work. The exact steps differ between firms, but the flow below matches how most ITGC change management testing runs.
- Understand the process. Hold a walkthrough with the change manager. Ask how a change starts, who approves it, how it is tested and how it is released. Note which tool holds each record.
- Identify the key controls. Pick the controls that answer the risks, such as approval before release, testing before release and separate roles for building and releasing.
- Test the design. Ask whether the control, as built, could stop the risk. An approval step that anyone can skip is poorly designed, even if people usually follow it.
- Get the population. Ask for a full list of changes made to the live system during the audit period. Where possible, take it from the system itself and not from a list someone typed.
- Check that the population is complete. Compare it with an independent source, such as deployment logs or the release records of the live system. A change that appears in the logs but not in the ticket list is a warning sign.
- Select a sample. Choose changes in line with the audit approach and how often the control runs. Include emergency changes so that they are not overlooked.
- Test each item. For every sampled change, check the approval, the testing, the release and the roles involved, and confirm that the order of events is correct.
- Evaluate exceptions and conclude. Record each exception, ask management for an explanation, look for other controls that reduce the risk, and decide whether the control worked across the period.
The first three steps are the test of design. The remaining steps are the test of operating effectiveness. Our IT general controls audit checklist shows how the same flow applies to the other control areas.
Graph 1: Sample split of effort in a change management test
This is a sample split for learning, not a fixed rule.
Evidence Auditors Ask For
Good evidence is dated, complete and comes from the system, not from memory. A screenshot of a ticket with its timestamps is stronger than a manager saying “yes, we approved it.” Here is what Sneha learned to collect, and the gap that usually shows up for each item.
| Evidence item | What it proves | Common gap |
|---|---|---|
| Change ticket with timestamps | The change was requested and tracked | Ticket created after the change was already live |
| Approval record | An authorised person agreed before release | Approval in chat or email, not in the tool, or dated after release |
| Test plan and result | The change worked before release | Results kept on a personal laptop |
| User acceptance sign off | The business accepted the change | Sign off by the developer who built it |
| Release or deployment log | What actually went live and when | Log does not match the ticket list |
| Access list for release rights | Only suitable people can release | Developers hold release rights |
| Emergency change review | Urgent changes were checked afterwards | Review never recorded |
Remember that evidence must also be reliable. If a report was pulled by the team being audited, an auditor will ask how the report was produced and whether any rows were removed. A list is only useful when it is complete and accurate.
Worked Example: Testing 25 Changes
Sneha’s mentor gave her a practice case. A company made 240 changes to its payment system in a quarter. The auditor checked that the 240 matched the deployment log, then chose 25 changes and tested each one for approval before release, testing evidence and separate roles. This is an example for practice. Real sample sizes depend on the firm and the audit approach.
Graph 2: Practice results from 25 sampled changes
Four of the 25 changes had exceptions. The auditor did not stop there. For each one, she asked what happened and whether another control reduced the risk. The two late approvals turned out to be a habit of one team that approved in bulk on Fridays. The missing test record was a single change by a contractor. The self approval was the most serious, because it showed the tool allowed one person to request and approve. A few exceptions in a sample do not automatically mean a failed control, but a pattern like this one needs a clear explanation and often a wider look.
Emergency Changes and Segregation of Duties
Two areas deserve extra care. The first is emergency changes. When a live system breaks at midnight, nobody wants to wait for a full approval cycle, and that is reasonable. The control is not that emergency changes never happen. The control is that each one is approved quickly, recorded in the change log and reviewed afterwards. Auditors often find emergency changes missing from the list, so they test the population against deployment logs first.
The second is segregation of duties. A developer who writes a fix should not be the person who releases it to the live system, because nobody then checks the work. In small teams this is hard to achieve. Auditors then look for other controls, such as a review of every release by a manager. Modern teams also use automated release pipelines. In that case the auditor looks at how the approval rule is set in the tool, who can change that rule, and whether code can reach the live system by any route that skips it.
For the user side of the story, our post ITGC in real life shows how access and change controls work together behind everyday logins.
Common Findings and How to Write Them
| Finding | What the auditor saw | Why it matters |
|---|---|---|
| Change without approval | Live change has no approval record | Unauthorised changes could affect financial data |
| Approval after release | Approval dated after the release date | The approval did not control the release |
| No test evidence | No result kept for a released change | Nobody can show the change was tested |
| Developer releases to live | Same person built and released | No independent check of the work |
| Incomplete change list | Deployment log shows changes missing from the list | The test sample cannot be trusted |
A good finding is short. Sneha learned to write three lines. First, say what you saw, such as “Two of 25 sampled changes were approved after the release date.” Second, say why it is a risk: the approval could not stop an unauthorised change. Third, say what proof you checked: the ticket history and the deployment log. Management then replies with a fix and a date.
Practice and Training for ITGC Change Management
You can start practising before you join any class. Take one change from your own work, or a sample ticket, and trace it. Who asked for it, who approved it, where is the test result, and who released it? Then ask whether you could show each answer to a stranger with a date on it. That small habit is the heart of ITGC change management testing. Our 12 week ITGC learning plan shows where change management fits in a full study schedule.
When Sneha wanted guided practice, she compared a few options. A good itgc audit course should let you work on sample tickets, approval records and release logs, not only slides. The better itgc training courses also give you mock interviews and feedback on your findings. Searching for ITGC training in Hyderabad will show many choices, so ask for a demo class and the full plan before you pay. MTJ Job Solutions offers an ITGC course in Hyderabad that covers change management, access controls and IT operations with online and classroom batches. For a closer look at modules and duration, read our guide to the ITGC course syllabus, duration and careers.
Months later, Sneha sat across from the same auditor. This time every change in the sample had a ticket, an approval before release, a test result and a release record. When the auditor asked her to explain one exception, she showed the emergency review and the follow up. The meeting ended early. Nothing dramatic happened, and that was exactly the goal. Good change management makes audits quiet.
Frequently Asked Questions
What is ITGC change management?
It is the set of controls that make sure changes to systems and applications are requested, approved, tested and released in a controlled way, with a record of each step.
How do auditors test change management?
They understand the process, get a complete list of changes, choose a sample and check each change for approval, testing, release and separate roles. They then record and evaluate any exceptions.
What evidence is needed for a change management audit?
Typical evidence includes the change ticket with timestamps, the approval record, test results, user acceptance sign off, the release log and the list of people who can release to the live system.
Why do auditors test the change population first?
Because a sample is only as good as the list it comes from. If the list leaves out emergency or unrecorded changes, the test cannot show whether the control worked for all changes.
Is an emergency change a control failure?
Not by itself. Emergency changes are expected. The question is whether each one was approved quickly, recorded and reviewed afterwards.
Can a fresher learn change management testing?
Yes. You need careful reading, neat notes and a basic idea of how software reaches a live system. Practice on sample tickets and a good course make the rest easy to learn.