Configuration Management Policy

Version: 1.00Issue Date: 10/6/2015

This Configuration Management Policy ensures that changes to systems and software are coordinated.

1.0 Overview

This Configuration Management Policy will help ensure that system and 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 Configuration Management Policy requires that changes to systems and software are coordinated and logged to prevent duplication of effort or conflict. This change management will help ensure that changes are tracked which will be useful for debugging problems discovered after changes are made.

3.0 Scope

This Configuration Management Policy applies to all software created by the organization and all computer systems. This policy is effective as of the issue date and does not expire unless superceded by another policy.

4.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.

5.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.

6.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.

7.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.

8.0 Other Policies

  • Change Management Policy
  • Development Life Cycle Policy
  • Technology and System Management Policy
  • Approved Application Policy
  • Computer and Printer Naming Policy
  • Equipment and Media Disposal Policy
  • Preventative Management 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

6.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:_______________