IT Change Management as Operational Risk Control: What to Test in an ITSM Platform

A straightforward software update can disrupt a core finance service if it is approved without the right context or scheduled alongside conflicting work. Treating IT change management as an operational risk control helps teams assess, authorize, schedule and review changes to financial systems before they are carried out.

For organizations choosing an IT service management (ITSM) platform, the question goes beyond whether it has a change calendar or an approval button. What matters is whether those features support the control decisions people need to make. Following one proposed change through each shortlisted platform gives buyers a practical way to find out.

In a finance environment, teams evaluating ITIL change management controls often treat retained decision history and automatic reapproval after a scope change as practical control considerations. These records help show reviewers that risk assessments stayed current when plans shifted and that every authorization matched the work actually performed.

01Start with one comparable change

Imagine an update to a finance application used by teams in London and Warsaw. The work requires a short outage, approval from the application owner and coordination with an infrastructure team. Database maintenance is proposed for the same evening.

Give each vendor that scenario, together with your organization’s approval rules. Invite the people who would use the platform to create and progress the record, instead of relying solely on a prepared demonstration.

According to Matrix42, change enablement is among the listed capabilities of Matrix 42 ITSM, making it one platform European organizations may choose to assess against this kind of scenario. Apply the same test to each candidate and note what the team can accomplish.

02Test risk assessment and approval routing

Testing risk assessment and approval routing establishes whether the platform captures complete impact context and enforces review before work proceeds. Start the application update as a change request. Can the requester record the affected service, expected outage, reason for the update and consequences if it fails? Check whether the application owner can see that context when deciding whether to approve.

Then introduce an objection. The owner rejects the proposed window because it clashes with a finance deadline. Can the requester find the reason, revise the plan and send it back for review? The rejection and the subsequent decision should be distinguishable in the record.

Once the change is approved, alter its scope: the update will now affect a connected service as well. Ask whether the platform can flag the revision and route it for renewed approval under your policy, while retaining the earlier decision.

Different changes can need different levels of scrutiny. A routine, preauthorized change may follow a simpler route, while an urgent change may need an expedited decision. The IT Process Wiki’s change-management reference describes standard, normal and emergency changes as separate categories. Test the routes your organization uses, instead of assuming every change must go to a change advisory board.

An audit of the IT change management process focuses on the design and operational effectiveness of the controls to meet the IT change management objective to determine whether controls provide reasonable assurance that changes to existing production infrastructure, data, or software are authorized, documented, tested, approved, and implemented.

Becky McCarty in IT Change Management for SOC: Process and Best Practices

03Check change windows across teams

Checking change windows across teams establishes whether the platform detects scheduling conflicts and prevents overlapping disruptions to production services. Return to the proposed evening outage. Ask the vendor to schedule the database maintenance at an overlapping time. Can the application team see the conflict, identify who owns the other task and agree on a revised window?

For teams working across Europe, check how that window appears in different time zones. Have one participant enter the time and another confirm the intended start and end from a different location. Then reschedule it and inspect the notification each team receives, including the language where that affects the handoff.

Look beyond the calendar itself. Staff also need to find the affected change records and reach the people responsible for coordinating the work.

04Follow implementation and decision history

Once the fictional update is approved, find the implementation steps and the infrastructure team’s assigned work. The record should show the planned sequence, who is responsible and what needs checking before the application returns to users.

Include a backout plan. If the update fails, the team needs to know where to find the steps for returning to the previous state. Ask the vendor to show how staff would record an unsuccessful update or a decision to stop.

Finally, reopen the change as someone who was not involved. Look for the original request, risk assessment, approvals, schedule changes and outcome. Can that person tell who made each decision and what information was available at the time? A “closed” status is much more useful when the reasoning behind it remains accessible, particularly when auditors review your IT change management process after an incident.

05Compare the evidence across ITSM platforms

Concepts: Start with one comparable change; Test risk assessment and approval routing; Check change windows across teams; Follow implementation and decision history; Compare the evidence across ITSM platforms.

For each platform, note what worked in the demonstration and what required extra configuration, an integration or a paid module. Ask who would maintain the approval rules when someone changes roles or the organization revises its policy.

The comparison should reveal more than a list of features. It should show how each platform handles the control decisions, exceptions and handoffs your teams face during a change, and what it will take to keep that process working when mitigating change management risks across production environments.

Frequently Asked Questions