Control Architecture: Change management: How are changes to information technology managed?

Options:

Basis:

Just let change happen and hope you can handle it.
Fast and loose is often the best approach for smaller businesses or for portions of businesses where risks are low. The cost of sound change control is often on the order of twice the cost of not having it, so low risk and low cost make sense together. But for medium and high risk systems, change control is absolutely required.

Make backups before changes in case you have to revert.
Backups are used to provide a modicum of recoverability, and changes are made with the knowledge that reversion is, at least theoretically, possible. It is prudent to also have a tested recovery procedure and to verify that thew backups are a workable solution for recovery in desired time frames.

Research and development separated from change control separated from production, testing at each step

Use change control prior to changes but move forward and count on your expertise to make it work.
In forward-only environments, such as financial transaction systems, many enterprises choose to never go back once a substantial change is made. This means that they accept the risk of failure and save the cost of full reversion. It places additional pressure on testing and process to get it right, and means that experts have to be available to deal with the issues if and when they arise, and in real time.

Use sound change control with full reversion capabilities.
Sound change control implies:

• A system for requesting, specifying, implementing, and testing changes,
• A method for tracking and backing out of changes,
• Separation of duties between research and development, testing, change control, and operations,
• Databases that track these different elements of the process,
• Approval processes and work flows to assure operational execution,
• Integration of changes into the detection and response process to prevent false positives and potentially harmful responses,
• Notification of audit so they can adapt their auditing to meet the new requirements,
• Updated documentation to reflect operational changes and user changes,
• Training to adapt the people to the changes,
• HR and legal approval of changes impacting those areas, and
• Policies, standards, and procedures must be followed along the way.

Recertify systems in context whenever significant changes are made.
In high-consequence systems, particularly where process failures can cause harm that is not rapidly and automatically detected and readily mitigated, significant changes (i.e., anything other than well-tested variations in parameters) should result in a system recertification in context. This includes both a thorough retest of the systems undergoing changes equivalent to the acceptance tests performed initially, regression testing of all known and resolved subsequent issues, and tests equivalent to acceptance and regression tests of interoperation to assure that changes don;t have adverse effects on related systems.

System-specific change controls should be used.
For systems that directly contact and control physical systems, changes are very closely related to the specifics of the physical system under control. As such, issues like stability and the ability to maintain control over the process are central to change management. As such, these are engineering decisions that rely on engineering calculations and analysis. Such changes cannot be made in bulk or based on a generic patch management approach, and cannot be tested with common system testing methods. Plant shutdown is often required for such changes, and simulations may also used to test some classes of changes.