All of Built Intelligence Ltd's products and processes are within the scope of this procedure.
- All functional managers are responsible for raising change requests
- Senior Managers are responsible for approving changes.
- The Quality Management Team are responsible for reviewing changes.
A change request may arise for many reasons includig the following:
- An incident or problem
- New hardware
- New software functionality
- New or changing technology
- New or changing legislation
- Changed business requirements
- Retirement of serviec
The following categories of change will be used:
The following changes are considered major and are therefore subject to this procedure:
- New system or major system upgrades
- System integrations
- New website or changes to the existing website
- IT Infrastructure upgrades
- Office location move
- Mergers and acquisitions
The following changes are considered standard and are therefore not subject to this procedure:
- Anti-virus updates
- Vulnerability patching
- Hot fixes
Major and Emergency changes require Senior Management approval and if a Senior Manager raises the change then this requires approval by another Senior Manager.
Desktop Software updates are version controlled, system documentation is updated and old documentation is archived.
The originator of a change request completes the change request form (ISMS-C REC 12.1.2) and obtains approval for the change, taking into account the costs of the exercise, the potential benefits, risks etc.
Change requests and approvals are raised and stored in the Dropbox Change Management Folder.
The change initiator is responsible for carrying out a risk assessment to identify potential risks, their impacts and to identify controls in line with the organisation's risk management framework.
A testing plan, complete with clear acceptance criteria including business and technical criteria must be documented prior to commencing change testing.
A back out plan must be documented prior to a change being implemented.
Once the change has been reviewed and is proved to be effective (working in line with the test criteria) the approver authorises its transfer to the operational environment.
Standard changes - these are "business as usual" changes which are expected to make up the majority of the change requests that are logged and handled through the change management process as described in this document. Although not emergencies, they will be prioritised in order that resources can be allocated in as effective a manner as possible.
Major changes will be logged within the change management process but referred to the Senior Management Team as their scope and implications will generally encompass a wider audience. They can be raised as projects with their own business case, project team and budget. However, note that a project may generate further change requests that may be managed within the change management process as normal changes.
Emergency changes - whilst all changes likely to be required should be foreseen and planned, there will be occasions when business requirements demand that changes be made in an emergency situation. Such changes are those requests which impact on internal or external 'live' systems and require implementation in order to resolve (or prevent) a current high priority incident or problem. In such cases a change request must be raised immediately even if the full change details are not available and the Senior Management Team must be notified. This is to ensure that all parties ar aware at the earliest opportunity. From initial logging of the change, the principles of the normal change management process should be observed as far as is realistic, however as an emergency changes may require swift approval from the Senior Management Team. If an emergency change cannot be formally authorised after reasonable efforts have been made to follow the process (e.g. out of hours) a ? may be made as to whether this change will be implemented. However, details of the change must still be recorded and the change management process followed retrospectively to ensure that records are maintained accurately and the success or failure of the change can be reviewed.