In this video, we walk through 5 ISC practice questions on change management tools and documentation. These questions are from ISC content area 1 on the AICPA CPA exam blueprints: Information Systems and Data Management.
The best way to use this video is to pause each time we get to a new question in the video, and then make your own attempt at the question before watching us go through it.
Change Management Tools and Documentation
Organizations change their IT systems constantly. They update software, adjust settings, and modify code. Change management is the process that keeps those changes under control. Every change should be requested, approved, tested, and documented before it’s made, and it should be possible to reverse it if something goes wrong.
Change management depends on two things working together. Tools handle the operational work of tracking, testing, and deploying changes. Documentation provides the evidence that each change was properly authorized and managed. A company can have one without the other. Changes can be approved on paper but never tested, or tested thoroughly but never approved. Either gap is a weakness.
Tools Used Before a Change Goes Live
Version control keeps a complete history of changes to code and configuration files. Each modification is saved as a new version instead of overwriting the old one. Teams can compare versions to see exactly what changed, and several developers can work on the same files without overwriting each other’s work. If an update introduces errors, the team can restore an earlier version.
Test libraries hold standardized test cases, scripts, and test data used to check a change before deployment. Because the same tests are used each time, testing is consistent and repeatable. This includes regression testing, which confirms that features that already worked still work after the change. Testing always happens in an environment separate from the live system.
Build automation compiles code, runs tests, and prepares the system for deployment automatically. Suppose staff once handled these steps by hand and sometimes skipped one or did them out of order. Build automation runs the same validated steps the same way every time, which removes that source of human error.
Tools Used After a Change Goes Live
Change tracking records what was changed, who made the change, and when. In effect, it’s an audit log of system modifications. If errors start appearing on a Tuesday morning, the team can look at what changed shortly before and trace the problem to its source. The same record helps identify changes nobody authorized or expected.
Monitoring and logging track how the system performs and behaves once a change is live, including uptime, error rates, and system events. This gives early warning. If an update starts causing outages, the team finds out quickly instead of hearing about it from customers.
Documentation That Describes the System
A system component inventory lists all hardware, software, and configuration items in the IT environment, along with the dependencies between them. Before upgrading a database server, for example, the team needs to know which applications and hardware rely on it. Without the inventory, there’s no way to assess what else a change might affect.
Baseline configuration documents a system’s approved, standard setup, its known good state. Before a change, it’s the reference point for what the system should look like. After the fact, the current settings can be compared against it. Settings that no longer match, with no approved change to explain them, point to configuration drift and possibly unauthorized changes.
Documentation That Runs the Change Process
A change request formally proposes a change. It typically includes a description of the change, the business justification, the affected systems, a risk assessment, and the required approvals. Its purpose is to make sure changes are reviewed and authorized before they’re made, not made informally.
A ticketing system assigns each change request a unique identifier and tracks it through approval, implementation, and closure. This creates a complete audit trail, so any change can be followed from the original request to its completion.
Rollback procedures are the documented steps for reversing a change that causes problems. They describe how to restore the system to its prior state, usually with backups or earlier versions from version control. Because the steps are written down in advance, a failed change can be undone quickly, limiting downtime.
