Change management controls
Change management controls require that all modifications to systems impacting financial reporting are formally requested, tested, approved, and documented. The goal is to ensure that no unauthorized or untested changes are introduced into production that could compromise the integrity of financial data.
What it means
In practice, this is a set of IT General Controls (ITGCs) designed to prevent "unauthorized change." If a developer can write code and push it directly into a live financial system without oversight, there is a risk that errors or fraudulent logic could be introduced, leading to material misstatements in financial reports.
The scope includes software updates, configuration changes to ERP systems, database schema modifications, and infrastructure changes affecting the application layer. It applies to both permanent fixes and temporary "emergency" patches.
Compliance focuses heavily on the segregation of duties (SoD). The person who writes the code or requests the change should not be the same person who approves it or deploys it to the production environment.
How to meet it
- Implement a standardized ticketing system where every change is logged with a unique ID, description, and business justification.
- Establish a mandatory testing phase in a non-production (UAT/Staging) environment that mirrors production.
- Require formal sign-off from a designated business owner or manager before any change moves to production.
- Enforce technical restrictions (permissions) so that developers do not have write-access to the production environment.
- Create a documented "Emergency Change" process for critical fixes, including a requirement for retrospective review and approval within a set timeframe (e.g., 48 hours).
- Maintain a version control system (like Git) that links specific code commits to authorized change tickets.
Evidence an auditor asks for
- A population list of all changes made during the audit period, cross-referenced with approved change tickets.
- User Acceptance Testing (UAT) evidence, such as signed test scripts or emails confirming a business user validated the change.
- Approval timestamps showing that authorization occurred before the deployment date.
- System access logs proving that only authorized release managers—and not developers—performed the production deployments.
Common pitfalls
- "Rubber-stamping" approvals where the approver signs off on changes without reviewing evidence of testing.
- Failing to document emergency fixes, leaving a gap in the audit trail for critical system patches.
- Lack of traceability between the initial request ticket and the actual code commit or configuration change.
- Allowing developers to use "service accounts" or shared credentials to bypass deployment restrictions.