ICT Risk and Change Management

ICT risk and change management means assessing the risk of a technology change before it is made, controlling how it is introduced, and checking afterwards that it has not harmed the service. Change is a normal and necessary part of running a financial service, but it is also a common source of disruption, because a change alters a system, a configuration, a data flow, or a supplier arrangement that the service depends on. Managing that risk is part of ICT risk management, not a separate administrative process.

The work is proportionate to the change. A minor configuration correction and a platform migration are not assessed in the same way, but both are assessed in relation to the service they affect. The question in each case is the same: what could this change interrupt, expose, or corrupt, what would the service effect be, and how would the change be reversed if it goes wrong?

Change creates risk because it alters a working system in ways whose full effects are hard to foresee. A software update may interact with an integration that was built for an earlier version. A configuration change may close one route while opening another. A data migration may transform records in a way that only becomes visible when a particular transaction type is processed. A supplier change may alter performance, support, or security characteristics without changing the outward service.

Change also creates risk through accumulation. A series of individually small changes, each assessed in isolation, can together transform a system, its dependencies, or its risk profile. A platform that has drifted through many small changes may no longer match its documentation, its asset record, or its recovery plan. Change management therefore needs a view of cumulative effect, not only of each change in isolation, and a routine for refreshing the service picture when accumulated change has altered it.

Assessment begins with the service effect. The change is described in terms of the services it touches, the systems and data it alters, and the dependencies it introduces or removes. Risk is then considered in relation to that service picture: what could go wrong, how the service would be affected, and what protections, detection, and recovery arrangements would be needed if the change introduced a fault. That service framing keeps assessment focused on harm, rather than on the technical elegance of the change itself.

Assessment also considers timing and reversibility. A change introduced during a period of high service demand carries a different risk from the same change introduced during a quiet period. A change that can be reversed cleanly carries a different risk from a change that alters data in a way that cannot be undone. Those considerations shape the controls around the change, including testing, staged introduction, monitoring, and the decision point at which a change is rolled back rather than fixed forward.

Control involves approval, separation of duties, and a record of what was changed, by whom, and why. Approval is based on the assessment, not on the seniority of the requester or the urgency of the business need alone. Separation means that the person who builds a change is not the sole person who approves it for production. The record allows a later incident to be traced to the change that caused it, and allows the change to be understood by people who were not involved in making it.

After a change goes live, monitoring watches for the faults and service effects that testing may have missed. That monitoring is more focused than routine monitoring, because it looks specifically for the symptoms associated with the change. A period of heightened attention, with a named owner and a clear rollback decision point, gives the entity a chance to catch a problem while its scope is still limited, rather than discovering it through customer impact.

Change links to legacy systems because older systems are often the hardest to change safely. Their documentation may be incomplete, their dependencies may be poorly understood, and their testing may be limited. A change to a legacy system therefore carries a higher assessment burden, and may require additional investigation before it can be assessed at all. That burden is part of the legacy risk picture, not a reason to avoid necessary change, but it shapes how change is planned for those systems.