Change Management Framework

Summary

No change reaches a live platform without assessment, testing, and approval. This applies to changes BeeTcore initiates as much as those a client requests. Every change is categorised by risk, a backup is taken immediately before deployment, and every change can be reversed. Where a client has its own change approval process, BeeTcore works within it.

1. Scope

This framework covers every change to a live client platform: content management platforms and custom applications, whether the change is functional, structural, a configuration change, or an update. Changes during an initial build follow the Development Methodology SOP.

2. Change categories

• Standard: pre-approved, low-risk, and repeatable, such as content updates and routine security patching. Proceeds under the client’s maintenance plan.
• Normal: functional or structural changes that need assessment. Requires written client approval before deployment.
• Emergency: needed to resolve an active incident or close an exploited vulnerability. Proceeds immediately, and is documented and communicated afterwards, as set out in Section 4.

3. Process for normal changes

1. Request. The change is logged with the requester, a description, and the business reason.
2. Assess. Impact on function, performance, security, and integrations is assessed, along with the risk to the client’s operations and the resources needed. Where risk can be reduced, BeeTcore recommends how.
3. Approve. The client approves in writing before work begins. Verbal approval is confirmed in writing.
4. Build and test. The change is built and tested in a staging environment or an isolated copy of the platform, never directly on the live platform.
5. Review. The client reviews the tested change and confirms in writing.
6. Back up. A backup is taken immediately before deployment, as set out in the Backup and Recovery Standards.
7. Deploy. The change is deployed at a time that minimises disruption, agreed with the client for critical platforms.
8. Verify and close. Function is confirmed after deployment, the change is monitored, and the record is closed.

Custom applications: changes also follow version control, peer code review, and automated release pipelines, as set out in the Development Methodology SOP.

4. Emergency changes

Where a vulnerability is being actively exploited or a platform is failing, the fix proceeds without waiting for approval, following the Incident Management Response Strategy. The client is informed as soon as the immediate risk is contained, and the change is documented and reviewed afterwards.

5. Client approval structures

Where a client has a formal change approval process, such as a change advisory board, a business owner, or an IT change manager, BeeTcore submits changes through it and follows its decisions and schedules. Approval authority for each engagement is confirmed in the project agreement.

6. Communication

Clients are informed of planned changes before they happen, with the nature of the change, its expected impact, and the timing. Completion is confirmed once the change is verified. Where the client has separate business and IT teams, both are kept informed.

7. Rollback and records

• Rollback. Every change can be reversed. The pre-change backup is the rollback position, and custom applications can also redeploy the previous tagged release. If verification fails and the fault cannot be fixed quickly, the platform is returned to its previous state and the change is reassessed.
• Records. Every change is recorded with what changed, when, who approved it and on what date, and why. The change history is kept for the duration of the engagement, as an auditable trail.

This framework is reviewed annually and after any change-related incident. Lessons feed into Continuous Service Improvement.

Frequently asked questions