In this video, we walk through 5 ISC practice questions on testing the design and implementation of change control policies. 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.
Testing the Design and Implementation of Change Control Policies
Change control policies set the rules for how an organization’s IT resources get modified. They make sure changes are documented, tested, reviewed, and approved before they reach production. Auditing these policies means looking at two things: whether the policy is designed to control the risk, and whether it’s actually in place and being used.
What Change Control Covers
A change control policy should apply to every type of IT resource, not just software. That includes three groups. Applications are the software the business runs, such as a billing or payroll system. Infrastructure components are the systems those applications run on, such as servers, operating systems, and network equipment. Configurations are the settings that control how systems behave, such as firewall rules and user access settings.
A policy that only covers application changes has a design gap. If network engineers can update firewall rules or the infrastructure team can upgrade servers outside the process, those changes go through with no testing or approval, even if everyone follows the policy exactly as written.
That’s the difference between design and implementation. Testing design asks whether the policy would control the risk if it were followed. Testing implementation asks whether the control actually exists and is being used, which is often confirmed by walking a recent change through the process from start to finish.
Testing Before Deployment
Before a change goes live, it should be tested in an environment that mirrors production, so the results reflect how the change will behave once it’s deployed. The results should be documented, and any change that fails testing should go back for revision.
Documentation alone isn’t the control. For example, if a change fails two test cases and is approved and deployed anyway because of a business deadline, the testing requirement isn’t in place the way it was designed. The results were recorded but not acted on, and the person approving the change let a known problem through.
Logging and Monitoring
The change log is the audit trail. Each entry should record what changed, who initiated it, who approved it, and when. That makes every change traceable to a person and an approval.
The limitation is that a change made outside the process never reaches the change log. Monitoring covers that gap by watching production for changes that don’t match an approved change ticket. One way to find these is to compare the system’s own list of production changes to the change log. A change that appears in production with no log entry needs to be investigated to determine whether it was authorized.
A monitoring tool is only half the control. If the tool generates an alert for an unauthorized change but nobody opens it, the change stays in place with no one aware of it. Alerts have to be reviewed and acted on for monitoring to work.
Change Control in CI/CD
Continuous integration and continuous deployment (CI/CD) pipelines automatically combine code changes, run them through checks, and deploy them, sometimes dozens of times a day. The controls don’t go away in this environment. Many of them move into the pipeline.
When an organization drops separate manual testing, the automated test suite becomes the main control keeping defective code out of production. A comprehensive suite includes unit tests, which check individual pieces of code on their own; integration tests, which check that those pieces work together and with connected systems; and security tests, which check for vulnerabilities. The pipeline also has to stop a deployment when a test fails. Running tests that don’t block anything prevents nothing.
Access Controls and Infrastructure as Code
With fewer manual checkpoints, segregation of duties depends on pipeline permissions. The person who writes a change shouldn’t be able to approve it and push it to production alone. Requiring a second developer to approve each change before it’s merged is a common way to build review into the pipeline.
Infrastructure as Code means server configurations and network settings are defined in scripts, and running a script applies those settings to production. These scripts need the same review and approval as application code. Tracking them in version control records who changed what, but it doesn’t stop an engineer from applying an unreviewed change to production.
