Change Management
      Back to home
      1. AssuranceLab - Knowledgebase
      2. Change Management

      Change Management Policy (Change Control Process)

      AL Refs: CHM02, GOV17

      Purpose

      The Change Management Policy sets out AssuranceLab’s systems, processes and requirements for ensuring secure and reliable software and systems development. It applies to all software and configuration changes managed by AssuranceLab including infrastructure changes to AWS that are managed as code changes.

      Example Change Management Policy

      Responsibilities

      Head of Engineering 
      The Head of Engineering is responsible for the implementation and management of this policy, unless noted otherwise. Managers and supervisors are responsible for the implementation of this policy, within the scope of their responsibilities, and must ensure that all staff under their control understand and undertake their responsibilities accordingly. 
      Product Owner
      The Product Owner is responsible for reviewing change requests, determining relevant priorities and ensuring all service level agreements are met by the change priorities, and overseeing and approving change releases, including ensuring key change management steps like testing and approval have been completed appropriately. 
      DevOps 
      Developers are responsible for following this policy, including ensuring all the required change management steps are followed for all software and configuration changes. This includes ensuring security and reliability objectives are considered and prioritised in the software development lifecycle and product roadmap. 
      Customer Success 
      The Customer Success team are responsible for raising change requests and bug fixes to the Engineering team. These should be assessed and prioritised initially by the support team by understanding the impact, urgency, and number of customers impacted to support the prioritisation in the product backlog.

      Software Development Lifecycle (SDLC)

      Change requests
      All changes require a change request ticket in the product backlog Services > Product Input including software changes. Change requests are raised by Customer Success, Audit Services, within the Engineering team, the Leadership Team or from other stakeholders of AssuranceLab. 
      Change requests are approved by management prior to raising on the product backlog to ensure the changes have been appropriately assessed, rated for prioritisation, and fit the objectives of AssuranceLab. Each change should have defined acceptance criteria and an impact assessment completed to understand any impacts on our functionalities or usage of the system(s) that may occur from the change. The acceptance criteria should also include any non-functional requirements; such as reliability, scalability and security.
      Product backlog 
      The product backlog includes all change requests and strategic plans. The Product Owner regularly reviews the backlog priorities and prepares sprint plans for each planned software release. This includes a combination of feature enhancements, bug fixes, security and reliability vulnerabilities or improvements. The changes are to be prioritised based on the following matrix or by the judgement of the Chief Product Officer.
       
      Priority
      Target Timeline
      Features
      Bugs
      Vulnerabilities
      High
      3 weeks
      Critical feature needed by users
      Major impact on most or all customers
      Critical vulnerability
      Medium
      60 days
      Important/strategic new feature
      Moderate impact on some customers
      Medium-High rated vulnerability
      Low
      When feasible
      Standard new feature roadmap
      Minor impact on one or a few customers
      Low rated or observation only
       
      Segregated change environments 
      Separate change environments are managed in AWS. All changes should be developed or performed first in the development environment until they have been confirmed to meet the requirements. These should then be migrated to the testing environment for impact assessment, testing, review and approval prior to migrating into the production environment.
      Sprint backlog and planning meetings 
      On a fortnightly basis, sprint backlog and planning meetings are held to review the change requests and prioritise those for development in accordance with the above defined criteria. An agreed sprint plan is formed, including agreement on whether user acceptance testing and/or a release management checklist and plan is required based on the scale and impact of the change release.
      Software development steps 
      The approved and planned changes for each sprint are developed in the GitHub code repository. The following steps are performed for all changes;
      • Develop the change and perform system and unit testing through a mix of automated tests in the continuous integration/continuous deployment (CI/CD) pipeline, as well as manual tests, as required.
      • Peer review of the change is systematically enforced in GitHub prior to merging with the master code branch.
      • Code scanning is performed and any alerts generated using Github's Dependabot to identify and resolve vulnerabilities before implementation.
      • Following peer review and resolution of any material vulnerabilities identified, the change is merged with the master branch. 
      Where UAT and other testing is required. Major change releases that require this additional testing, are determined by the Product Owner in the sprint backlog and planning meetings:
      • The master branch is migrated to the pre-production environment for any user acceptance testing and other tests (as applicable).
      • The quality assurance testers provide sign off when acceptance criteria is met and tests have verified no other critical functions have been adversely impacted.
      Where the change release has any impacts on security, or includes any new features, as determined by the Product Owner in the sprint backlog and planning meetings:
      • An assessment of the release plan is performed to determine any communication requirements to users of the system, internal teams, and updates to system documentation.
      • The checklist is prepared and completed to ensure all impacts and team alignment are considered and completed accordingly.
      • The Product Owner approves the release into production including the time and plan for release and communications with the release.
      Emergency changes 
      Emergency changes may be required in conjunction with a major incident where the , , and/or have been enacted. It may not be feasible to complete the standard change management stages sequentially in this case. Approval is required from management, including the Emergency Response Team, Senior Leadership Team, or Head of Engineering, Product Owner to perform an emergency change. In these cases the stages above may be skipped as required, and performed retrospectively. The approving manager should be informed and consulted to the extent that the risks associated with skipping the standard stages are understood and will be retrospectively performed to ensure no adverse impacts or issues following the emergency release.