A developer pushes an untested code fix directly to production at 4:55 PM on Friday. By Saturday morning, the payroll system has calculated overtime at double the correct rate for 3,000 employees. The root cause was not the bug fix itself. It was the absence of controls that would have prevented an unauthorized, untested change from reaching production.
AICPA Representative Tasks (verbatim). 1. Remembering & Understanding, Explain the purpose of change management processes and practices related to internal hardware and software applications, including identification of the associated risks. 2. Remembering & Understanding, Explain the different types of tools (e.g., change tracking, version control, test libraries, build automation, monitoring and logging) and documentation used (e.g., system component inventory, baseline configuration, change requests, ticketing, rollback procedures). 3. Remembering & Understanding, Explain the different environments used (e.g., development, staging, production) and the types of tests performed (e.g., unit, integration, system, acceptance).
HIGH-FREQUENCY: Change management is an IT general control that governs how modifications to hardware, software, and configurations move from concept to production.
Common mistakes
- Equating version control with change management. Version control tracks code changes but does not enforce authorization or testing. A complete change management process includes request, approval, development, testing, authorization to deploy, deployment, and post-implementation review. Version control supports this process but does not replace it.
- Allowing developers production access for troubleshooting. Granting developers access to production "just for debugging" circumvents separation of duties. Once access exists, developers can modify production data or code. Read-only access with enhanced monitoring is the appropriate alternative.
- Skipping testing for emergency changes. Emergency changes still require testing: abbreviated testing, not no testing. The emergency change procedure should define minimum testing requirements and compensating controls (immediate post-implementation monitoring, mandatory review within 48 hours).
Bottom line
- Change management is a preventive IT general control that blocks unauthorized, untested, or undocumented modifications from reaching production; uncontrolled changes risk disruption, data corruption, or security vulnerabilities
- Separation of environments (development, staging, production) ensures code is tested before deployment; separation of duties prevents developers from promoting their own code
- Four conversion approaches: direct (immediate cutover, highest risk, lowest cost), parallel (run both systems, lowest risk, highest cost), pilot (subset first), phased (by module or location)
- Patch management lifecycle: identify, prioritize by severity, schedule maintenance windows, test, deploy with rollback, monitor; unpatched systems are the leading cause of security breaches
Exam shortcut
Conversion approach by risk tolerance: Direct = highest risk, use only when forced. Parallel = lowest risk, use for financial systems. Pilot = moderate risk, test with subset first. Phased = moderate risk, implement incrementally. Match the approach to the scenario's risk profile.
The full lesson (about 3,189 words, 21 min read) adds 2 worked examples, all 6 common mistakes, a self-check, free in the app.
Learning objectives
- I.A4
Browse all free CPA ISC lessons or jump into free CPA ISC practice questions.