A financial auditor relies on an automated control because it behaves the same way every time. That reliance holds only if nobody changed the control, or the code around it, without testing and approval. Program change controls are how you show that.
For a company that deploys many times a day, SOX change management can feel like it was designed for a different era. It was not, quite. The objective is unchanged: every change to an in-scope system is authorized, tested and approved, and the people who write changes cannot push them to production unchecked. What changes with modern pipelines is how you produce the evidence.
This article covers what auditors test, how the change population is built, and the cases that cause trouble. For where change management sits among the ITGC areas, see our overview of SOX IT general controls.
What auditors test
For each in-scope application and its supporting layers, auditors commonly test whether:
Changes are requested and authorized before work starts, or at least before deployment.
Changes are tested, with evidence of the testing.
Changes are approved for production by someone other than the developer.
Developers cannot move their own changes into production without that approval, or, where they can, there is a compensating review.
Emergency changes follow a defined process, with approval after the fact.
Configuration changes to financial applications are controlled like code changes.
The exact control set, and which layers it covers, is agreed with your auditor during planning.
Start with the population
Every change management test begins with a list of changes made to production during the period. The auditor samples from that list and traces each sample back to its authorization, testing and approval.
The population is the first place a test can fall apart, because it is easy to produce the wrong list. A list of closed change tickets is not a list of changes. It is a list of the changes someone remembered to ticket.
The auditor wants the list from the system that makes the change:
Deployment records from your pipeline or deployment tool.
Merge history on the protected branch that deploys to production.
Database migration logs for schema changes.
Audit logs from financial applications, for configuration changes.
Then they compare that system-generated list with your tickets. A deployment with no matching ticket is an exception. Our article on proving population completeness covers how to show the list is whole.
Authorization, testing and approval
Authorization
Someone with the authority to request the change should have done so. For product changes, a ticket or issue linked to the change usually serves. For configuration changes in a financial application, such as revenue rules, tax settings or approval workflows, the business owner of that process should authorize them. Finance cares about those changes more than any code change.
Testing
The auditor needs evidence that the change was tested before production. Automated test results attached to the change, or a record of user acceptance testing for business-facing changes, both work. "It was tested" in a ticket comment does not.
Approval
Approval for production comes from someone other than the person who made the change. In a pull request workflow, a required review by a second engineer is the usual mechanism. Our article on code review as a change management control covers what makes a review count, and our article on branch protection rules covers the repository settings that enforce it.
For SOX, check one more thing: whether the settings that enforce review were themselves in place for the whole period. A branch protection rule that was disabled for a week, even briefly, opens a window the auditor will ask about.
Separating development from deployment
The traditional control is that developers do not have access to deploy to production. In many modern teams, the pipeline deploys, and nobody has direct production deployment rights at all.
That design usually satisfies the objective, provided three things hold:
The pipeline only deploys from a protected branch that requires an independent approval.
The pipeline cannot be bypassed. Nobody can deploy from a laptop, change the pipeline definition without review, or push directly to the protected branch.
Administrators are controlled. People who can change branch protection, pipeline configuration or production infrastructure are few, and their changes are logged and reviewed.
That last point is where change management meets access control. Our article on access to programs and data covers how privileged access is restricted and reviewed.
Where a small team cannot separate duties fully, document the gap and add a compensating detective control. A regular review of all production changes by someone outside the change, comparing what was deployed with what was approved, is the common answer.
Emergency changes
Emergency changes are legitimate. Systems break, and fixing them cannot wait for a normal review. The control is not that emergencies never happen. It is that they follow a defined path.
A defensible emergency change process:
Defines what qualifies as an emergency, and who can declare one.
Allows the change to proceed with a lighter or delayed approval.
Requires approval after the fact, within a set timeframe.
Keeps a record linking the emergency change to the incident or reason.
Auditors test emergency changes separately, often selecting all of them if there are few. An emergency path used for routine work, to avoid review, is a finding waiting to happen.
Configuration and vendor changes
Not every change is code. Financial applications often allow powerful changes through configuration screens: a new approval threshold, a changed revenue schedule, a modified report. These deserve the same discipline as code changes. Confirm that the application logs configuration changes, restrict who can make them, and review the log.
For vendor-hosted SaaS applications in scope, you do not control the vendor's code changes. Your auditor will look to the vendor's SOC 1 report for the vendor's change controls, and to you for the user controls the report lists. Reviewing the vendor's release notes for changes that affect your financial processes is a sensible addition.
Program development and data migration
Larger projects, such as implementing a new ERP or migrating billing systems, bring their own risks. Auditors look for project approval, testing that covers financial functionality, sign-off before go-live and controls over data conversion. The data conversion control is the one most often missed: show that balances and records were reconciled between old and new systems.
Common change management mistakes
Building the population from tickets. The test starts from the system.
Approvals after deployment for normal changes. Approval dates later than deployment dates fail, however legitimate the change.
Self-approval through an admin override. Branch protection with an administrator bypass that someone used.
Ignoring configuration changes. The ERP setting that changed revenue timing was never ticketed.
Emergency changes never closed. Retroactive approvals that never came.
The SOX ITGC framework page summarizes how change management fits with the other ITGC areas.
How TrustLynce helps
TrustLynce collects change records from your code and deployment systems on a schedule, so the population comes from the source system rather than a ticket export (evidence collection). Continuous monitoring checks settings such as branch protection over time and routes failures to the owner.