SOX change management controls make sure only authorised, tested changes reach systems that produce financial data. Most failures hide in the population: changes that never went through the ticket system. This article goes deeper than the general ITGC overview, with test steps for each kind of change.
Last reviewed: 17 October 2026. Facts checked. We opened the SEC's 2007 interpretive guidance (Release 33-8810, govinfo.gov; first 100,000 of about 161,000 characters read), which says management needs to evaluate IT general controls that other controls rely on. We searched for ITGC testing guidance but did not open a Big Four technical page on change management or the PCAOB standard (403 error). The test steps are practitioner method, not quotations from a standard.
SOX applies to companies subject to US securities law. Indian companies are covered only where they are SEC registrants or part of a group that is.
Where this sits
Our SOX ITGC testing guide covers access, change and operations together. Here we focus on change only. For access, see user access controls.
The SEC guidance says management evaluates only the IT general controls that other relevant controls need to operate. So scope change management to the applications, databases and interfaces behind your key controls.
Step 1: Know what a "change" is
Change management covers more than code releases.
| Change type | Example | Risk |
|---|---|---|
| Application code | New release or patch | Wrong calculation |
| Configuration | Tax code, approval limit, pricing table | Bypassed control |
| Report or interface | New query, file feed | Bad IPE or missing data |
| Infrastructure | Database upgrade, migration | Data loss |
| Direct data fix | Script run on production | Unreviewed ledger change |
| Vendor or cloud update | SaaS release | Unannounced behaviour change |
Include all that touch in-scope systems.
Step 2: Get a complete population
This is the hardest step. Do not take the list the IT team gives you without checking.
Ways to confirm completeness:
- Compare tickets to deployment logs or release records.
- Compare system version history or code repository commits.
- Check the database for objects with recent change dates.
- Ask who can deploy to production, and check their activity.
- For SaaS, review the vendor's release notes.
If a change reached production with no ticket, that is a finding on its own. Our IPE guide explains testing the population report.
Step 3: Test a sample of changes
For each selected change, look for:
- A request and business case.
- Approval before work started.
- Testing evidence, including user acceptance.
- Approval to go live by someone other than the developer.
- Evidence of who moved it to production and when.
- Rollback plan where relevant.
Use the sampling plan generator to choose the sample size by your methodology. We do not give a table here.
Step 4: Segregation between development and production
Check that developers cannot move their own code to production. Review the list of users with deploy rights. Look at whether a shared or generic account is used. See the segregation of duties conflict matrix template.
Developers having read access to production may be acceptable. Write access is the concern.
Step 5: Emergency changes
Emergency changes skip normal steps. That is allowed if the policy says how. Test:
- Was there a defined emergency path?
- Was approval recorded, even after the fact?
- Was testing done afterwards?
- Were emergency changes reviewed by someone senior within a set time?
- How many are there? A high count shows the normal process is not working.
Step 6: Vendor patches and data fixes
Vendor patches: check who decides to apply them, and where they were tested. For a cloud product where you cannot control release timing, look for the vendor's assurance report and your own monitoring.
Direct data fixes: these are often outside the ticket system. Ask for the log of scripts run on production. Select some and check approval and review of before and after data.
Step 7: Link to automated controls
If a key control is automated, such as a three-way match, you can test it once and rely on change controls to show it has not altered. If change management is weak, you must test the automated control more often. The ITGC audit workbook can help you record this.
Common failures
- Ticket system is not the whole population.
- Approver is the developer.
- Testing evidence is a statement, not a result.
- Emergency changes never reviewed.
- Direct data fixes unrecorded.
- No process for SaaS updates.
Frequently Asked Questions
Do all changes need approval?
In-scope changes should, as the policy states. Define a lighter path for minor ones.
What if the application is SaaS?
Review the vendor's reports and your own configuration changes. Record the reliance.
Is a code repository enough as a population?
It helps, but compare it to the release records. Configuration changes may not appear there.
How do I test a one-off migration?
Treat it as a project. Check data reconciliation before and after, and approvals.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error