Ruslan Rakhmetov, Security Vision
Think of an apartment building as a company's information system, and renovations or various resident actions as changes to the infrastructure. Hammering a nail under a mirror in the hallway doesn't threaten the integrity of the building, so residents don't need to get it approved by the authorities, but the decision to demolish a load-bearing interior partition affects the safety of the entire building. Concept Change Management serves as the engineering regulation that draws a clear line between cosmetic work and the risk of collapse of the building's load-bearing structures.
Analytical reports from research company Gartner show that approximately 80% of unplanned downtime in corporate environments is caused by incorrect actions of engineers and procedural failures when making modifications. Change Management, within the IT Service Management (ITSM) methodology, was historically created as a mechanism for protecting infrastructure, and in this article, we will detail the lifecycle, regulatory requirements, and how the process itself has evolved over time.
1. From Bureaucratic Control to Change Enablement
2. Classification of changes and approval routes
3. Synergy of change management and information security
4. Audit and regulatory requirements
5. Process Metrics and Best Practices
6. Checklist and ready-made memo
1. From Bureaucratic Control to Change Enablement
The traditional approach long suffered from bureaucracy: every action required approval from dozens of people, blocking innovation and reducing business agility. The new ITIL 4 model shifted the focus from prohibitions to creating a secure technology platform: regulations should not hinder value delivery; their goal is to ensure automated risk assessment and high speed of safe modifications in the era of continuous integration and delivery (CI/CD).
Any authorized modification of an information system begins with formalization: a request for change (RFC), a structured electronic artifact in the ITSM system that combines a technical description of the work, business justification, criticality class, a list of affected configuration units, as well as resource and time costs. Approving a housing redevelopment project with municipal authorities is very similar to a change request: the owner develops an architectural design, coordinates a noisy work schedule with neighbors, obtains permission from the housing inspectorate, and only then invites a construction crew.
2. Classification of changes and approval routes
ITIL classifies technological transformations into three categories, distributing the workload between the approving bodies depending on the level of potential risk:
1) Standard changes are regulated, repetitive operations with predictable results. Because the risks of such actions are understood, their approval process is automated through the service catalog, relieving experts of routine work.
It's like replacing a light bulb in a chandelier or changing the oil in a car engine: the procedure is outlined in the service manual, the consumables are certified, and there's no need to coordinate the replacement with the automaker's engineers.
2) Normal changes cover a wide range of releases and changes to the application software architecture. Each such request requires individual analysis, an assessment of dependency relationships, and peer approval.
Changes of this magnitude are comparable to installing a gas heating boiler in a private home instead of an electric one: it requires approval of design documentation from the gas service, inspection of ventilation ducts, and the allocation of a separate day for installation.
3) Emergency changes are initiated only in force majeure circumstances: when addressing high-priority incidents, such as cyberattacks or critical communication channel failures. Bureaucratic filters are minimized, and responsibility for risks is assigned to the on-duty crisis response team.
An emergency change is comparable to applying a tourniquet to an open injury: medical care is provided immediately to save the victim's life, and completing the medical history and taking laboratory tests are postponed until vital signs stabilize.
3. Synergy of change management and information security
Since we place a special emphasis on cybersecurity, we will also examine change management processes from this perspective. Unaccounted changes are considered the primary source of compromise of the protected perimeter: unauthorized opening of a network port, disabling an antivirus agent for the supposed purpose of speeding up database performance, or modifying access control lists create hidden vectors for network intrusion.
The gradual deviation of the actual state of servers from the design basis due to the accumulation of manual temporary edits made by system administrators is called Configuration Drift. To address this issue, IT and information security experts recommend implementing automated version control of infrastructure as code and file integrity monitoring systems.
4. Audit and regulatory requirements
To control the quality of change processes, the industry also relies on the metrics system of the DORA research group (DevOps Research and Assessment) and ITSM methodology. For example, during an external security audit, inspectors verify the consistency of change logs on information security tools (such as hardware firewalls, DLP systems, and asset databases) with entries in the ITSM registry. If a configuration change is made, but there is no authorized RFC ticket signed by an information security officer, the event is recorded as a serious breach of information security. Such documentation of requests is required by regulators:
- International standard for information security management systems, ISO/IEC 27001:2022
Requires mandatory documentation, risk assessment and authorization of any changes to IT components, as well as configuration control.
- International Card Processing Industry, PCI DSS v4.0
Mandates auditing of changes to the cardholder environment (CDE), documenting rollback plans, and ensuring separation of responsibilities between developers and administrators.
- National standards for the protection of financial transactions of the Russian Federation, GOST R 57580.1
They regulate the life cycle of IT assets, require the recording of basic reference configurations and the control of any updates to software modules.
- Operational Risk Management in Russian Banks, Bank of Russia Regulation No. 716-P
Requires credit institutions to implement end-to-end change accounting, regulate process windows, and continuously maintain records of incidents caused by infrastructure failures.
5. Process Metrics and Best Practices
Let 's imagine the production defect rate at a food processing plant: if a pastry shop produces 1,000 cakes per shift, but the cream separates on 150 of them right on the store shelf, the production defect rate is 15%. The company's technologist's goal is to reconfigure the ingredient mixing process so that the defect rate does not exceed one cake in a thousand.
а) Usually the main indicator of process efficiency is Change Failure Rate (CFR), applied to releases that ended in rollbacks or crashes. Thanks to automated checks and risk filtering, the change process management allows you to monitor these changes and achieve target indicators of 0%-15 %.
b) The time required to restore the service to normal operation (Failed Deployment Recovery Time or MTTR) is another indicator that ideally should not exceed one hour. This is due to the mandatory presence and testing of rollback scenarios during the change process. management this indicator can be effectively managed.
c) The duration of the path from task approval to its appearance in production (Lead Time for Changes) is optimized in change management by upgrading routine requests to standard changes and is typically managed within a few hours to a couple of days.
d) Frequency of successful releases to production (Deployment Frequency) in companies with developed change processes management allows for releases in small batches with low risk.
e) A clear distribution of zones of influence reduces the number of conflicts between teams, therefore, in change processes The RACI responsibility matrix plays a major role in management:
-
R (Responsible), for example, an engineer/developer who physically prepares the script, tests it, and rolls out the change.
-
A (Accountable), for example, the owner of the service or Change Manager – a person who is personally responsible to the business for the results.
-
C (Consulted), for example, security experts (IS), network architects, lawyers (CAB committee), whose opinion is necessarily taken into account when analyzing risks.
-
I (Informed), such as technical support, business users, and customers who are notified of the technology window schedule.
If we were to describe the process of replacing a flat tire on a busy country highway, the time from the moment of an emergency stop on the side of the road to the tightening of the last wheel bolt would be described by the MTTR. There's no formal approval process, and the frequency of repairs will depend on the number of accidents and the road quality. Having an inflated spare tire, a working jack, and a wheel brace in the trunk represents a pre-planned rollback, allowing you to get back on your way in ten minutes instead of waiting for hours for a tow truck.
RACI matrix can be analyzed using a more complex example of wedding planning: the bride and groom (Accountable) make the final decisions; the banquet manager (Responsible) sets the tables; the decorator and sommelier (Consulted) provide advice on decorations and the wine list; and guests (Informed) receive invitations with a starting time.
6. Checklist and ready-made memo
We have prepared a checklist that engineers can print out or implement into the ticket system as a checkbox:
1. Has the original data backup been recorded and its integrity verified?
2. Has the Rollback script been tested on the Staging bench ?
3. Is the exact point of no return defined? (Drop-dead point by hours and minutes)?
4. Has a technical support engineer been assigned on duty and have related services been notified?
5. Are monitoring alerts configured to detect degradation of key business metrics of the service?
Successful Deployment of the Change Process Management requires a gradual transition from administrative coercion to engineering automation:
- At the initial stage, the organization is required to conduct a complete inventory of computing resources and build an up-to-date configuration item database (CMDB). Change management is impossible without a clear understanding of the boundaries of the infrastructure being protected.
- The next step is calibrating the risk matrix and approving the standard change catalog. Transitioning regular, tested, low-risk procedures into automatic approval frees the CAB from routine work, allowing it to focus on reviewing critical architectural transformations.
- Every normal change must be accompanied by mandatory technical regulations, including a preliminary test on the Staging stand , a strictly defined technological window, and a formalized emergency rollback scenario with a defined point of no return.
By adhering to these principles, change management transforms from a bureaucratic barrier into a tool for ensuring the reliability, continuity, and cyber resilience of digital business.
