Change Management

Purpose

The purpose of this policy is to establish a streamlined change management control process that ensures all changes to major systems are effectively managed, minimising risk and ensuring system stability. This policy is supported by our continuous integration and continuous delivery (CI/CD) approach.

Scope

This policy applies to all team members involved in the development, testing, deployment, and maintenance of major systems within the organisation.

Roles & Responsibilities

Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.

Policy Statements, Standard, or Procedure

All changes to major systems must follow the procedures outlined below to ensure proper risk assessment, testing, authorisation, and control.

Change Proposal

• Documentation: Changes must be documented in our version control system (Github) with a clear description, rationale, and expected impact; this will generally be a pull request.
• Risk Assessment: The developer proposing the change must assess the risk level (low, medium, high) based on potential impact; this will usually be done in the pull request as a tag.
• Impact on Confidentiality, Integrity, and Availability: The developer must consider the impact of the change on the confidentiality, integrity, and availability of the system. See our Information Security Policy for more information.

Risk Review

• Second Developer Review: A second developer shall review the proposed change and risk assessment.
• Stakeholder Involvement: For medium or high-risk changes, additional stakeholders should be consulted, including consideration for time to deploy, potential impact, and rollback plan. This includes stakeholders internal to Vaxa, as well as any suppliers.

Testing

• Environment: All changes must be tested in a staging or test environment.
• Automated Tests: Ensure all automated tests pass before deployment, and that coverage is sufficient in the CI/CD pipeline.
• QA Verification: Relevant QA resources (including business takeholders) should conduct additional testing as needed.

Authorisation

• Approval: The second developer must approve all changes before deployment to production if a low-risk change, or if a medium or high-risk change, the CTO must approve.
• Documentation: Approval is documented in the version control system.

Deployment

• CI/CD Pipeline: Changes should deployed via the CI/CD pipeline where possible, but may be deployed manually where required.
• Scheduling: Consideration should be given to deployment timelines and potential impact on users; deployments in-hours is permissible if the risk mitigation plan is sufficient.

Rollback Plans

• Rollback Plan: A rollback plan must be documented for each change.
• Automated Rollback: The CI/CD pipeline should support automated rollback to the previous stable version, or a manual rollback plan should be documented.
• Initiation: The CTO can initiate a rollback in case of post-deployment issues.
• Incident Management: If a rollback is required, the incident management process should be followed.

Change Control Record Keeping

All changes, approvals, test results, and deployment logs are stored in version control for audit purposes. This are retained in line with our Data Retention Policy.

Exceptions

• Urgent Changes: In critical situations (e.g., emergency fixes), the standard procedure may be expedited. This shall be documented in the ticketing system, including rationale and any additional risks.

Compliance & Monitoring

• Periodic Reviews: The team lead will periodically review change records to ensure compliance.
• Team Meetings: Deviations from the policy will be discussed to prevent future occurrences.
• Automated Enforcement: Tools may be used to enforce aspects of the policy (e.g., requiring approvals before merge in Github), alongside our access control policy ensuring only authorised personnel can deploy.

References

• Information Security Policy
• Cloud Security Policy
• Secure Development Policy
• Data Retention Policy