System Change Management Policy
for System and Equipment Maintenance
|Version: 1.00||Issue Date: 3/16/2015|
This System Change Management Policy ensures that changes to systems are coordinated.
This System Change Management Policy will help ensure that system changes are minimally disruptive to services and that changes are coordinated between applicable groups so conflicts or duplication of effort does not occur.
This System Change Management Policy requires that changes to systems are coordinated and logged to prevent 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.
This System Change Management Policy applies to all computer systems managed by the organization and those providing direct services to the organization. This policy is effective as of the issue date and does not expire unless superseded by another policy.
4.0 Universal Policies
Most standard users will not be able to install software on their computers according to the User Privilege Policy. Windows domain policies combined with local privileges may be used to control these privileges.
A test plan must be created for testing the product functional and security features. When the initial code is tested or changes are made, the test plan must be used to be sure established functional and security features work properly.
All software must be appropriately licensed to be installed or used.
Separation of duties does not allow programmers to have system administration privileges and administrators do not perform programming duties on any systems where they have administrative privileges. Programmers may test code on the development environment but do not test code on the Quality Assurance environment where the customer tests code.
Backups of software, system settings, and systems should be periodically stored offsite according to the Backup and Recovery Policy. Offsite backups should be updated or replaced when any significant change is made to system software or systems that are being backed up.
5.0 Software Change Distribution Policies
Software changes and patches must be centrally distributed and the configuration must be centrally controlled.
Software changes must be applied in a timely fashion to keep systems and software secure.
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.
Authorized software must be installed by authorized and qualified personnel for software developed both inside and outside the organization.
The software inventory database must be updated when software is purchased or installed to help keep licensing accurate and current.
6.0 Software Development Requirements
Only administrators on servers will be able to install software on servers. Software may only be installed when authorized and the administrator with privileges to install should not be able to remove system log entries. Use of the privilige of installing software should be logged and monitored.
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.
7.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.
The owner of each configuration change should be identified and recorded in the tool used to track configuration changes.
The importance of each configuration change should be provided by the system owner at a rating of high, medium, or low. This importance should be recorded.
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.
At the start of the project, business requirements are documented as system requirements are determined.
Service level agreements are defined for the maintenance phase of projects.
The project is designed to meet business need based on business importance of various aspects of the project. For instance the amoount of required security and availability of services must be considered in the business impact.
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.
A security assessment of the project must be created near the start of the project and reviewed and modified near the end of the project. Settings and configurations that may affect security must be considered. Default parameter settings and settings of accounts with default accounts and passwords must be considered so the default account name and password are not used.
When significant changes are made to software that may affect the business functionality, the business continuity plan must be updated.
Business processes should be modified to take advantage of new features of the product or use new technologies provided.
8.0 Change Process
A different change process will be created for in-house software development and updates to vendor provided software such as operating system updates.
The change process for performing equipment maintenance for servers, networking equipment, and other equipment must include provision to be sure the data, software, and configuration on the equipment is backed up and can be restored before the change is performed.
Procedures and a plan must be in place so if a change causes unexpected problems, the system or software may be rolled back to the original version.
After software installation, settings and configurations that may affect security must be checked. During maintenance, periodic checks of settings and configurations that may affect security must be checked. Default parameter settings and settings of accounts with default accounts and passwords must be checked so the default account name and password are not used.
Software or products to be installed whether they are created in house or externally must be tested prior to operation in a production environment. The security and functional requirements must be adequately tested in an environment that simulates the production environment. Testing should be done by a combination of technical staff and those who will use the system. Testing done by those who use the system such as end users may be done in a Quality Assurance (QA) environment.
All software must be installed using instructions from the software creator. Any changes to the installation procedure must be discussed with the creator of the software.
Software documentation must be complete and kept up to date. Where applicable, vendors are required to provide original or updated documentation according to contract. The responsibility for the maintenance of software documentation for all software must be defined.
System documentation must be promptly updated when changes are made that affect the operation of the system. Backups must be updated where the changes affect the backups.
When changes affect the business process or require changes to contingency plans, the contingency plans must be promptly changed to reflect the changes to the system or business processes.
A change request process must be created with the following characteristics:
The change request process must be clearly defined, written, and published so all groups that need to know the process are aware of it and understand it. Training must be provided if the process is not clear.
Enough information must be included in the change request to allow an impact assessment to be created. The change request must include details about changes that may affect the capacity of the system, security of the system, performance of the system, or changes to features of the system.
The change process must provide ways to estimate or measure the significance of the impact of the change.
An impact assessment of significant changes must be done to give change approvers thorough information which they can use to make decisions. The impact assessment must estimate the change impact and list any possible coompliance issues the change may create. Significant changes include changes that modify user functionality or modify security.
A tool is used to track change requests and allow the requestor and personnel working on the change to post comments and be aware of the status of the request.
All requested changes must be approved by management. Specific managers qualified to approve changes must be defined by department and/or project. Only authorized changes are allowed to be implemented and all changes must be logged in the change request tool.
Change requests should be linked to specific systems or projects so managers can determine the history of changes on their projects or systems.
The change request system must provide for listing business processes that are affected by the change, other changes related to or affected by the change, or other projects that are affected. Those making the change are responsible for coordinating the change with those making other related changes or personnel using business processes affected by the change.
Changes must be ranked in order of urgency such as low, medium, high, or urgent. The potential benefit should be analyzed by the change requestor and entered into the request. The benefit may be in a dollar savings per year or features that may make user's jobs more efficient saving some amount of labor per year.
The change process should consider release cycles and testing. If changes not related to the cycles are made, management should approve the changes.
The change process must require documentation to be updated and tested as part of the change process. Documentation requirements include changes to change procedures, changes to configuration, user manuals, operational procedures, training materials, and technical manuals.
An independent test process must be created which will allow evaluations of the success or failure of changes to be conducted.
When changes are tested and accepted, the inventory for the software must be updated to include the version and date whether the software is developed in-house or purchased from vendors. This will help prevent or detect unauthorized or erroneous changes. The tested and accepted software will become the new baseline.
9.0 Emergency Changes
Management must define what an emergency is by defining characteristics of the emergency such as defined critical services being down.
Images or backups of the system before and after the emergency and a log of actions taken during the emergency should be retained for at least two weeks.
Any emergency changes to systems, vendor provided software, or software developed in house must be documented, controlled, and approved by management either before or after the change.
Any emergency changes to systems, vendor provided software, or software developed in house must be tested either before or after the change.
When temporary access for installation or for emergencies is granted, after the installation or emergency is over, the account used is either made inactive, deleted, or its password is changed.
A maintenance plan for systems must be created or a universal maintanence plan should be followed. Maintenance will include firmware and software updates. Maintenance tasks must be defined so actions and access required is known.
Maintenance personnel must have only the required access to perform their duties and logical or physical controls should prevent additional access. Actions of maintenance staff must be logged and the log must be reviewed by another staff member.
Updates to software is done according to instructions from the software creator.
Personnel performing software maintenance or updates must be authorized and qualified.
When external personnel work on equipment, they must be required by contract to comply with organizational policies and procedures including security policies. External personnel must be bound by a nondisclosure agreement.
Performance of software must be monitored and errors must be logged and checked to determine whether corrective action is required. Corrective action must be taken in a timely manner where required.
As systems age, the cost of replacement versus maintenance is evaluated to determine whether system replacement or maintenance is a better alternative.
Maintenance contracts are promptly renewed where the cost is justifiable. Information Technology staff must check the Asset Control database to determine when maintenance contracts expire and contact appropriate management to determine whether renewal is desired. When renewal is desired, the IT personnel must renew the contract and update the Asset Control database.
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.
12.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 Management Policy
Asset Control Policy
Physical Security Policy
User Privilege Policy
13.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 and meet the requirements in section 8 above.
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. All changes to software must be documented including the date of change and the person making the change.
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.
A maintenance plan detailing maintenance tasks for specific systems and general systems should be created.
A software release procedure should be created for software development which is used for controlling changes to the production environment and released software.
Approved by:__________________________ Signature:_____________________ Date:_______________