Change Management ITGC Testing: Program Changes, Emergency Changes and Migration to Production

Change management answers a simple question: how does the company know that every change to the systems behind financial reporting was approved, tested and moved to production by someone with the right to do it? The SEC's interpretive guidance for management names program changes and program development among the IT general control areas that may be relevant to ICFR, and says management needs to evaluate those ITGCs that are necessary for the proper and consistent operation of other controls addressing financial reporting risks. This post gives a control set, a test program and a worked example.

Why it matters

The guidance says that when adequate ITGCs exist and operate effectively, management may find automated controls more efficient to evaluate than manual controls, and that an automated control assessed as lower risk is one supported by a stable system that has not undergone significant change and by effective ITGCs. Change management is what makes "stable" provable. Without it, every automated control test is a point-in-time result with no assurance that the logic stayed the same.

NIST's Cybersecurity Framework 2.0 describes the relevant outcomes: ID.RA-07 (changes and exceptions are managed, assessed for risk impact, recorded and tracked), PR.PS-01 (configuration management practices are established and applied) and PR.PS-06 (secure software development practices are integrated and their performance monitored).

Control set

Test program

1. Population. Obtain the complete list of production changes from the system (for example, transport logs, deployment records, release tool exports), not from the ticketing tool alone. A ticket list shows only the changes that went through the process.
2. Completeness check. Compare the system change list to the ticket list. Changes with no ticket are unauthorized by definition. Agree population counts to a second source.
3. Sample for the full path. For a sample, trace the ticket to approval, test evidence, migration by an authorized person and timing (migration after approval).
4. Emergency changes. Test all, or a risk-based sample; confirm after-the-fact review and ratification.
5. Segregation. Compare the developer and migrator identities for each change.
6. Configuration. Obtain the audit log for the approval workflow and tolerance settings of the key financial applications and compare to tickets.
7. Data fixes. Obtain a list of direct database updates and trace to approvals.

Worked example

An ERP produced 214 production changes in the year according to its transport log. The ticketing tool listed 187 approved change tickets.

• Completeness. 27 transports had no ticket. Investigation: 19 were emergency fixes logged by phone and never ticketed; 8 were configuration changes by a finance systems analyst.
• Sample of 25 ticketed changes. 23 had approval before migration. 2 were migrated before approval was recorded by one and two days. 4 lacked test evidence.
• Segregation. Of 214 migrations, 31 were performed by the developer who authored the change, all by two developers who held both roles.
• Configuration. Of the 8 configuration changes without tickets, one removed the tolerance that blocks invoice payments with a price variance above 2 percent.

Conclusions: CM-01, CM-03, CM-04 and CM-05 not effective; CM-02 has exceptions (4 of 25 without test evidence) that must be evaluated for severity. Standard 14.5 Engagement Conclusions requires the conclusion to state the overall significance of the aggregated findings, so the five control results are reported together. The removed tolerance is also an exception to investigate: from the date of change, test the invoices that would have been blocked. See /us/blog/internal-audit-findings-criteria-condition-cause-and-effect-standard-14-3 for the finding structure.

For SEC registrants, the next step is ICFR evaluation: which automated and IT-dependent controls run on this system, and does a compensating control exist at the precision needed? The deficiency is aggregated with access deficiencies on the same application. See /us/blog/control-deficiency-aggregation-memo-sec-guidance-and-written-conclusion and /us/blog/user-access-provisioning-and-quarterly-access-review-itgc-testing.

Small and cloud environments

A company on a cloud accounting package has few program changes of its own, but configuration changes, integrations and add-ons still change how transactions are recorded. Treat settings that affect approvals, posting and tax as changes. For packages the vendor updates automatically, document the vendor's release notes review and confirm key controls after major releases. The glossary entries are /us/glossary/change-management and /us/glossary/software-development-life-cycle.

Mistakes to avoid

• Testing only the ticketed population.
• Treating emergency changes as exempt from review.
• Ignoring configuration changes because no code moved.
• Accepting "developer tested it" as test evidence.

CORAA prepares ready-to-review audit files for US CPA firms from client books; the firm keeps the client, the review and the signature. See /us.

Sources

• SEC, Release No. 33-8810, Sections II.A.1.b (efficiency of automated controls), II.A.1.d (role of IT general controls) and II.A.2.a (stable systems and ITGC effectiveness): https://www.sec.gov/rules/interp/2007/33-8810.pdf
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 26, 2024), ID.RA-07, PR.PS-01, PR.PS-06: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
• The IIA, Global Internal Audit Standards (2024), Standard 14.5 Engagement Conclusions: https://www.theiia.org/en/standards/2024-standards/global-internal-audit-standards/

AU-C references are to AICPA Professional Standards, paraphrased here; read the standard itself before relying on a requirement. This page is guidance, not professional advice. Report an error