Software Change Management Policy

for Software Development

Version: 1.00Issue Date: 3/16/2015

This Software Change Management Policy ensures that changes to software are coordinated and do not adversely affect business processes.

1.0 Overview

This Software Change Management Policy will help ensure that software changes are minimally disruptive to services and that changes are coordinated between applicable groups so conflicts or duplication of effort does not occur.

2.0 Purpose

This Software Change Management Policy requires that changes to software are coordinated and logged to prevent service disruption, duplication of effort or conflict. This change management policy will help ensure that changes are tracked which will be useful for debugging problems discovered after changes are made.

3.0 Scope

This Software Change Management Policy applies to all software created by the organization. This policy is effective as of the issue date and does not expire unless superseded by another policy.

4.0 Business Support

All changes must work for the benefit of the business whether in cost savings, improved performance, increased security or other benefits. The business area affected must be informed of all changes that may affect service availability or service performance to that business area. Any time a business process may be broken by a change, the business area that is affected by the change must be made aware of it prior to the change except during emergency situations

  • A change request process must be developed and must:
    • Be communicated to all parties affected including the user or customer.
    • Specify both user and IT department personnel responsibilities.
    • Specify both user and IT department personnel authority.
  • A clear process along with a tool must be used to keep change requestors informed about their request status.
  • All changes must include an impact assessment including areas of performance, capacity, and security.
  • The impact assessment must consider thresholds and metrics which define when impact is significant.
  • A process to create the impact assessment including the thresholds and metrics and extent of impact, considering performance, capacity, and security should exist.
  • All changes must be reviewed by management and approved by management. A process must ensure that only approved changes are implemented.
  • To expedite the change approval process, changes should be categorized by type and common changes should be created in template form with common information pre-created in the change form.
  • Review of changes must include a way to be sure compliance problems are not caused by the change.
  • All applications and systems must have a log of change requests.
  • Interdependencies between changes must be considered and a process must be used to identify and manage changes with interdependencies.
  • Procedures must be used to ensure all changes are prioritized considering possible impact, effort, benefit, and urgency.
  • Change procedures must include consideration for documentation to be updated. The procedures must be sure training materials, operational procedures, and other help functionality are treated as part of the change and tested the same as the system functionality.
  • Changes to documentation and training programs that are modified due to software changes must consider features of the updated software.
  • Users of software that is modified must be appropriately trained in the changes and new features of the software.
  • When appropriate, as changes are made, business processes must be updated to use any new functionality.
  • When system software changes are made, business continuity plans must be updated when it is appropriate.

5.0 Change Control

  • Access control methods must be used to control changes to data.
  • Methods to monitor data for unauthorized changes must be implemented.
  • Owners for specific configuration items must be identified.
  • Owners of specific configuration items must determine the business importance of those items and whether the component is critical to the business function.
  • Data and software must be backed up before installation of new software (or updates) is performed or maintenance tasks are performed.

6.0 Software Change Distribution

  • Software changes and patches must be centrally distributed and the configuration must be centrally controlled.
  • The Software Version Control Team is responsible for designating and configuring changes to software that is in use.
  • The software control team shall have access to systems used to distribute software. Other personnel shall not have privileges to distribute software.
  • Changes made to software distribution points shall be monitored and logged. Auditors shall have read access to the logs.
  • All software changes must be done using the normal change process.
  • Installation of unapproved software is not allowed.

7.0 Security of Change

  • Security characteristics of software installed and maintained must be assessed including modifications of initial default passwords and initial parameter settings.
  • Software changes made or software products modified or installed must be tested to ensure established security conditions are still in force after the change.
  • After maintenance or installation tasks have been completed, temporary access must be removed.

8.0 Software Testing

  • A process must be created which ensures that software is tested in a separate environment from production. The separate environment must be similar to production for testing purposes.

9.0 Software Requirements

  • Only licensed software may be installed or tested.

10.0 Software Installation

  • Purchased software must be installed according to the manufacturer's instructions. If deviations from the instructions are done, they must be first discussed with the vendor.

11.0 Software Maintenance

  • Management must authorize all maintenance tasks.
  • Management must ensure that all changes are tested and documented before the change is made or new software is put into the production environment.
  • Software maintanence tasks must be performed according to the manufacturer's instructions.
  • Software maintanence tasks must follow the same processes used for application updates.
  • Qualified personnel must perform software maintenance tasks.
  • Authorized personnel must perform software maintenance tasks.
  • External personnel performing maintenance tasks must comply with organizational policies (non-disclosure and security) by contract.
  • Upgrades or patches to software must be applied in a timely manner.
  • Software must be monitored for errors and logs checked regularly. Errors must be corrected.
  • Expiration dates of maintenance contracts must be monitored and maintenance contracts must be renewed in a timely manner.
  • Maintenance must be continued so long as maintenance is more cost effective than replacement. A cost benefit analysis must be determined when applicable to determine which is the better alternative.
  • Responsibility for the maintenance of software documentation must be assigned. When software changes are made, vendors must be required to deliver updated documentation.
  • All changes to software must be tracked and reported either using procedures or a software change control program.
  • Software programmers are not allowed to have duties that may cause a conflict of interest. They should not perform final testing of their own code.
  • Maintenance tasks must be detailed so the actions of maintenance staff can be controlled.
  • Actions of maintenance staff must be logged.
  • Logs of maintenance actions must be reviewed to be sure only authorized tasks were performed.
  • Access controls must be used to ensure that maintenance staff can only perform assigned tasks.

12.0 Software Libraries

  • An independant librarian must manage programs and software library functional code.

13.0 Change Process

  • A change request process must be implemented and published.
  • The change request process should use tools where expedient.
  • Backups to system software must be stored offsite.
  • Software backups must be made both before and after significant changes are made. The software and its documentation must be archived before the change is made.
  • Backout plans must be in place before the change is implemented.
  • When changes are made to configuration files, the configuration files should be backed up and restored as part of the backout plan rather than manually modifying the configuration. This will prevent subtle errors from affecting configuration files.
  • Implementation instructions for new code must be provided in advance.
  • Updated user guides and instructions for new code affecting user functionality must be provided before the software changes are put into place.
  • When source programs are transferred from the testing environment to production, the process must ensure the source libraries and all program copies in the production environment are promptly updated with the latest code and it must be clearly labeled. Previous versions must be kept at least six months and for a minimum of the last three versions.
  • Software version control must be integrated into the software release process.
  • A review process should be implemented for reviewing changes. The reviewers must be independent of those making and approving changes.
  • After changes are completed, reviewed, and accepted, a new baseline must be established and the software inventory must be updated.
  • The software baseline can be used to be sure unauthorized changes to software have not been made.
  • When software must be distributed to clients, a process must exist to get the software distributed in a timely and effective manner while ensuring its integrity and source.
  • A log must be kept showing what software has been given to which departments, organizations, and the person it was given to. The log must include information about where the software has been implemented.
  • Commercial software must log distribution and match it with licensing information.

14.0 Emergency Changes

  • Management must define what constitutes an emergency and what conditions allow for emergency changes to be made.
  • Management must institute procedures used to identify and declare emergencies.
  • System owners should authorize the types of changes and specific changes that may be made during emergencies.
  • Emergency changes must be documented either before or after the change is made.
  • Emergency changes must be tested either before or after the change is made.
  • Emergency changes must be approved even if done after the change.
  • Emergency changes must be reported and followed up by management to determine whether the change should be permanent or a better way of effecting the change could be done.
  • Where possible, before and after images and logs should be kept for review.

15.0 Software Development Requirements

  • A Software Version Control Team or set of staff must be designated to control production source libraries.
  • The Software Version Control Team shall have exclusive access to source libraries.
  • Changes to source libraries shall be monitored by supervisors and logged. Logs shall be available to auditors for reading.
  • All software code changes must be made using the normal change process. Changes made not using the normal change process are not allowed.
  • Changes to software source code outside the scope of approved projects must be approved by the Project Management Board.
  • Specific individuals on the Software Version Control Team designated by management shall track configuration information.
  • When significant changes to software takes place that will add or modify user features of the software, the personnel that use the software must be trained to understand the changes. The training materials and manuals that document the software must be updated when the software change is complete. New training should describe the differences between the old version and the new version of the software.
  • As programs are being transferred from the test or QA environment to production, the librarian must be sure that the change is documented and source code libraries are promptly updated. The version number and date of the program must be recorded. Enough previous versions of the program must be kept so the software may be rolled back or referenced if the newer version encounters problems. The current version of the program must be saved and stored in the library before the new version is installed.
  • Software released for sale or to production must be based on source code stored in the central library and managed by the librarian. The librarian must be sure that the released software was tested, documented, and authorized for release.
  • Formal build requests are required for software to be released on media for distribution. The librarian must be sure that the software released for distribution is the same as was tested during the acceptance testing process.
  • Software released on media should have a hash value dependent on the content of the media. The hash value should be stored in the library so the media may be verified as authentic and not tampered with.
  • The librarian should log when software is distributed, to whom it is given, and what version is distributed.
  • When new software is issued, a process to be sure it is distributed in a timely manner to all departments should be followed. The distribution should be thorough so all affected customers are reached with updated software and documentation in a timely manner.

16.0 Configuration for Projects

  • Each project must have its own configuration management plan. Within the configuration management plan, an optimal configuration baseline should be defined which defines optimal functionality and includes scope.
  • The configuration baseline should change as the project progresses when system components are completed and accepted into the production system. The configuration management plan and configuration baseline should change for development, test, and production environments. The project team must develop a process to revert to the baseline configuration if a change should break or damage the system. This is especially important for the production system.
  • Changes to the baseline configuration should be authorized by the system owner with a sign off.
  • Tools should be used to monitor changes and compare them to the configuration baseline. The history of changes should be retained by the tools used to track changes. Reports to management about changes should be provided regularly.
  • Equipment shall be named according to the Computer and Printer Naming Policy.
  • The Development Life Cycle Policy and Technology and System Management Policy shall be followed.
  • The Equipment and Media Disposal Policy shall be followed when replacing or retiring equipment at the end of a project life cycle.
  • The Asset Control Policy must be followed during the life cycle of a project to be sure assets are properly tracked. Procurement procedures and policies must be in compliance with the Asset Control Policy.
  • Organizational policies must be communicated and enforced when third party organizations are in charge of projects or configuration management. All contracts must provide for enforcement of policy and auditing of third parties. Third party organizations should be audited for compliance.
  • A configuration management tool or system should be utilized to record the configuration changes made to servers, software, network equipment, and other appropriate equipment. Designated personnel should have access to the tool and allowing too many people to have write access should be avoided to prevent errors. Help desk and other information technology personnel should have read access.
  • Physical security is used according to the Physical Security Policy to help control additions or removals of equipment and be sure policy is followed.

17.0 Enforcement

Since following the Change Management Policy is important for the welfare of the organization, employees that purposely violate this policy may be subject to disciplinary action up to and including denial of access, legal penalties, and/or dismissal. Any employee aware of any violation of this policy is required to report it to their supervisor or other authorized representative.

18.0 Other Policies

  • Development Life Cycle Policy
  • Technology and System Management Policy
  • Approved Application Policy
  • Computer and Printer Naming Policy
  • Equipment and Media Disposal Policy
  • Preventative Maintenance Policy
  • Asset Control Policy - Authorized software may only be installed by authorized personnel, based on an official request and the software inventory must be kept current.
  • Physical Security Policy
  • User Privilege Policy

19.0 Additional Requirements

  • A formal change process for software code development must be created by the Software Version Control Team. Procedures should reflect the needs of the project life cycle.
  • A formal change process for software change distribution must be developed by the Software Version Control Team.
  • Procedures for putting equipment into operation must be developed including installation procedures for servers, configuration procedures, hardening procedures, joining equipment to a domain, and others.
  • Procurement procedures for equipment and software must be developed.
  • Change management procedures must be developed for various types of projects including projects involving both hardware and software.
  • Procedures for making configuration changes for each project must be defined and utilize the configuration management tool providing for record keeping and auditing. These procedures should use or refer to standard change management procedures as much as possible.
  • Regular periods of review and updates of configuration change records for both hardware and software must be established by management. Management will determine how often reviews are done.
  • Capacity planning procedures must be written so system capacity is considered when changes to systems or system configurations are made.


Approved by:__________________________ Signature:_____________________ Date:_______________