What If Your Change Management Control Fails?

Can you still rely on the integrity of the system?

Let’s say your change management process isn’t working—tickets are missing, approvals weren’t captured, or worse, unauthorized changes have gone live.

What then?

Can you still rely on the integrity of the system?

Yes - if a compensating control is in place.

This week, let’s dive into one of the most important compensating IT general controls: The Change Review Control.

What is a Change Review Control?

As the name suggests, a Change Review Control is a detective ITGC that involves reviewing all changes deployed into a system over a given period - monthly, quarterly, or semi-annually depending on the risk level and change frequency of the application.

This control acts as a backup when your preventive controls fail and as a monitoring mechanism to catch unauthorized changes after they’ve happened.

Why It Matters?

Imagine this: Someone with elevated access modifies an application configuration. There’s no ticket, no approval, and no record - a complete breakdown of the change management process.

Without a Change Review Control, you’d have no way to detect it.

But with it? You can retroactively:

• Validate all changes made
• Ensure every change had proper approval
• Catch unauthorized activities in production

One of the most critical decisions in designing an effective Change Review Control is choosing the right frequency. Too infrequent, and you miss risks. Too frequent, and you waste time reviewing insignificant changes.

So, how do you strike the right balance?

Here are the four key factors that influence control frequency:

1. Risk Profile of the Application

• High-risk applications (e.g., financial reporting systems, ERP platforms) should be reviewed monthly. These are systems where unauthorized changes can have a material impact on financials, operations, or compliance.
• Medium-risk applications (e.g., internal platforms that support critical business operations) can be reviewed quarterly. Changes matter, but the impact of an error is less immediate or severe.
• Low-risk applications (e.g., tools with limited access or non-critical functions) might be reviewed semi-annually or annually.

2. Change Volume

• Frequent releases or deployments? Go for monthly reviews to ensure nothing slips through the cracks.
• Minimal change activity? A quarterly or semi-annual cadence may suffice—but always validate that the frequency aligns with actual risk.

3. Complexity of Changes

• Major configuration updates or code-level changes increase risk. If the changes are highly technical and impactful, the control should run more often, regardless of volume.
• Minor cosmetic or UI tweaks? These carry less risk and may not require frequent review.

4. Compensating Role in Control Environment

• If the preventive change management control has failed, the Change Review Control acts as a compensating control. In this case, the frequency should increase to provide a stronger safety net.

How Should You Evaluate a Change Review Control as an Auditor?

Here’s a simplified framework you can follow:

1. Understand the Risk the Control Is Addressing

• Is the application high-risk?
• What’s the impact of unauthorized changes?
• How often are changes deployed?

2. Assess the Control Frequency

• Monthly: for high-risk systems with frequent changes
• Quarterly: for medium-risk systems
• Semi-annually: for systems with rare changes
• The frequency should match the risk and volume of changes.

3. Evaluate the Change Listing

• How is the change list generated?
• Does it include all production instances?
• Is it complete and accurate?
• Are there filters being applied (e.g., specific roles, users)? That’s a red flag—every change should be reviewed, regardless of who made it.

4. Review Execution

• Is the reviewer checking tickets, approvals, and evidence?
• Are they just signing off on the list, or actually investigating?
• If it’s just a review of names and dates, it’s not effective.

5. Assess Reviewer Competence

• Does the reviewer understand the application and the nature of changes?
• A reviewer with no technical knowledge of the system won’t be able to spot anomalies.

Takeaway

A Change Review Control is one of the most critical detective ITGCs. It can:

• Compensate for failed preventive controls
• Detect unauthorized changes
• Reinforce audit reliability, even in imperfect systems

If designed and executed well, it’s a powerful safeguard every auditor should understand.

Next Up

In upcoming editions, we’ll break down each component of Change Review Controls and explore other core ITGCs like logical access, backup and recovery, and job scheduling.

If this newsletter helped you see Change Review Controls differently, consider sharing it with your team or network.

And if you have any questions, feel free to message me. I’ll do my best to help.

Until next time,

Chinmay Kulkarni

?