IT Change Risk

From Open Risk Manual

Definition

IT Change Risk is the risk arising from the inability of the institution to manage IT system changes in a timely and controlled manner, in particular for large and complex change programmes[1]

Risk Sub-types

Inadequate controls over IT system changes and IT development

Incidents caused by undetected errors or vulnerabilities as a result of change (e.g. unforeseen effects of a change or a poorly managed change due to a lack of testing or improper change management practices) to e.g. software, IT systems and data .

Examples:

  • Release into production of insufficiently tested software or configuration changes with unexpected adverse effects on data (e.g. corruption, deletion)

and/or IT system performance (e.g. breakdown, performance degradation).

  • Uncontrolled changes to IT systems or data in the production environment.
  • Release into production of ill-secured IT systems and internet applications, creating opportunities for hackers to attack the provided internet services and /or to breach the internal IT systems.
  • Uncontrolled changes in the source code of internally developed software.
  • Insufficient testing due to the absence of adequate testing environments.

Inadequate IT architecture

A weak IT architecture management when designing, building and maintaining IT systems (e.g. software, hardware, data) can lead, over time, to complex, difficult, costly to manage and rigid IT systems, that are no longer sufficiently aligned with business needs and are falling short compared to actual risk management requirements.

Examples:

  • Failure/malfunction of storage (hard disks), server or other IT equipment caused by e.g. lack of maintenance.
  • Infinite loop in application software prevents transaction execution.
  • Outages due the continued use of outdated IT systems and solutions that no longer meet present availability and resilience requirements and/or are no longer supported by their vendors.

Inadequate IT continuity and disaster recovery planning

Failure of IT planned availability and/or continuity solutions and/or disaster recovery (e.g. fall-back recovery datacentre) when activated in response to an incident.

Examples:

  • Inadequately managed changes to IT systems, software and/or data over a prolonged period of time, leading to complex, heterogeneous and

difficult to manage IT systems and architectures, causing many adverse business and risk management impacts (e.g. lacking flexibility and agility, IT incidents and failures, high operating cost, weakened IT security and resiliency, reduced data quality and reporting capabilities).

  • Excessive customisation and extension of commercial software packages with internally developed software, leading to the incapacity to

implement future releases and upgrades of the commercial software and the risk of no longer being supported by the vendor.

Inadequate lifecycle and patch management

The failure to maintain an adequate inventory of all IT assets in support of, and in combination with, sound life-cycle and patch management practices. This leads to insufficiently patched (and thus more vulnerable) and outdated IT systems that may not support business and risk management needs.

Examples:

  • Unpatched and outdated IT systems that may cause adverse business and risk management impacts (e.g. lacking flexibility and agility, IT outages, weakened IT security and resilience).

Factors

  • an institution may be more exposed to ICT change risks due to the complexity (e.g. as a result of mergers or acquisitions)
  • when an institution is implementing material changes to its IT systems and/or IT function (e.g. as a result of mergers, acquisitions, divestments or the replacement of its core IT systems), which may adversely impact the stability or orderly functioning of the IT systems and can result in IT change risks;

Controls

The institution’s IT risk framework should cover the risks associated with the development, testing and approval of IT systems changes, including the development or change of software, before they are migrated to the production environment and ensure an adequate IT lifecycle management.

  • Documented processes for managing and controlling changes to IT systems (e.g. configuration and patch management) and data (e.g. bug fixing or data corrections), ensuring the adequate involvement of IT risk management for important IT changes that may significantly impact the institution’s risk profile or exposure;
  • Specifications regarding the required segregation of duties during the different phases of the implemented IT change processes, with a focus on the implemented solutions and segregation of duties to manage and control changes to the production IT systems and data by IT staff (e.g. developers, IT system administrators, data base administrators) or any other party (e.g. business users, service providers):
    • solution design and development
    • testing and approval of new software and/or changes
    • migration and implementation in the production environment
    • bug fixing
  • test environments that adequately reflect production environments
  • an asset inventory of the existing applications and IT systems in the production environment, as well as the test and development environment, so that required changes (e.g. version updates or upgrades, systems patching, configuration changes) can be properly managed, implemented and monitored for the involved IT systems.
  • a process to monitor and manage the life cycle of the used IT systems, to ensure that they continue to meet and support the actual business and risk management requirements and to make sure that the used IT solutions and systems are still supported by their vendors; and that this is accompanied by adequate software development life cycle (SDLC) procedures.
  • a software source code control system and appropriate procedures to prevent unauthorised changes in the source code of software that is developed in-house
  • a process to conduct a security and vulnerability screening of new or materially modified IT systems and software, before releasing them into production and exposing them to possible cyber-attacks;
  • a process and solutions to prevent the unauthorised or unintended disclosure of confidential data, when replacing, archiving, discarding or destroying IT systems;
  • an independent review and validation processes to reduce the risks for human errors when performing changes to the IT systems that may have an important adverse effect on the availability, continuity or security of the institution (e.g. important changes to the firewall configuration), or security of the institution (e.g. changes to the firewalls).

References

  1. EBA, Final Guidelines on ICT Risk Assessment under SREP