noIM₃ Legal & Policies

Change Management Policy

Last updated: [Date]

1. Purpose and Scope

This Change Management Policy defines the processes and controls governing changes to the noIM₃ platform, infrastructure, codebase, and operational procedures. The purpose is to minimise service disruption, prevent unauthorised changes, and ensure all modifications are documented, tested, and reviewed before deployment.

This policy applies to:

  • All changes to production systems, databases, and infrastructure
  • Software releases and feature updates to the noIM₃ platform
  • Changes to third-party integrations and APIs
  • Configuration and security changes

[Add scope exclusions if relevant, e.g. minor content updates, documentation changes.]

2. Change Categories

Standard changes

Pre-approved, low-risk, routine changes with well-understood processes and minimal impact on service availability. These may proceed without formal approval but must be logged.

Normal changes

Non-routine changes that require assessment, approval, and scheduled implementation. Includes new feature deployments, dependency upgrades, and infrastructure modifications.

Emergency changes

Urgent changes required to restore service, address a critical security vulnerability, or prevent imminent data loss. Emergency changes bypass standard scheduling but require retrospective documentation and review.

[Adjust categories and definitions to match your actual change management framework.]

3. Change Request Process

  1. Request: Change initiator documents the proposed change, rationale, affected systems, rollback plan, and estimated impact.
  2. Assessment: Technical review of risk, dependency impact, and testing requirements.
  3. Approval: Changes are approved by the designated change authority before implementation.
  4. Scheduling: Changes are scheduled during maintenance windows where possible to minimise user impact.
  5. Implementation: Change is implemented according to the documented plan.
  6. Verification: Post-implementation testing confirms the change is functioning as intended.
  7. Documentation: Change record is updated with outcome, any issues encountered, and closure status.

4. Rollback Planning

All normal and emergency changes must include a documented rollback plan prior to implementation approval. The rollback plan must identify the steps to restore the previous state, the personnel responsible, and the conditions under which rollback would be triggered.

5. Emergency Changes

Emergency changes may be implemented immediately to protect the integrity, availability, or security of the platform. The change initiator must notify the relevant stakeholders as soon as practicable and complete all required documentation within 24 hours of implementation.

[Define who has authority to approve emergency changes and the notification chain.]

6. Change Freeze Periods

[Define any change freeze periods, e.g. end-of-financial-year, peak usage periods, or public holidays when production changes are prohibited.]

7. Record Keeping

A change log is maintained for all changes to production systems. Records include the change description, requestor, approver, implementation date, outcome, and any associated incidents. Change records are retained for a minimum of [X years].

8. Policy Review

This policy is reviewed annually or following any significant incident, material change to the platform architecture, or relevant regulatory requirement.

Questions about this policy? Contact us and we'll respond within 2 business days.