Change Management Policy¶


Code	`OPS-006`
Domain	Operational Resilience
Owner	Chief Technology Officer
Status	Draft
Applicability	Platform
Jurisdiction	NZ + AU
Business domain	BD09
Review date	2027-03-25

Regulations: CPS 230 Operational Risk Management ¶

Purpose¶

Govern the platform's obligations for change management and release management, including the Change Advisory Board, change risk assessment, release controls, and rollback requirements.

Scope¶

All changes to production systems, infrastructure, configuration, and data pipelines of the platform in NZ and AU.

Policy statements¶

The platform SHALL operate a change management process governing all changes to production systems. Changes SHALL be classified as standard, normal, or emergency. Standard changes are pre-approved, low-risk, and may follow an expedited process. Normal changes SHALL require Change Advisory Board (CAB) approval before deployment. Emergency changes that bypass the CAB SHALL be permitted only with CTO approval and SHALL be documented within 24 hours and reviewed by the CAB retrospectively.

All normal changes SHALL be accompanied by a change request that includes: a description and business justification, a risk assessment, evidence of testing in a non-production environment, a tested rollback plan, and an implementation schedule with defined deployment and observation windows.

The CAB SHALL meet at least weekly to review and approve normal changes. The CAB SHALL include representation from Technology, Operations, and Compliance. Changes to regulated data pipelines, regulatory reporting systems, or AML/CFT systems SHALL require sign-off from the CCO or delegate in addition to CAB approval before deployment.

All changes SHALL be deployed through the governed CI/CD pipeline. Direct modifications to production systems outside the pipeline are prohibited. Emergency changes authorised by the CTO that bypass the pipeline SHALL be followed by a pipeline-equivalent change record within 24 hours. Any direct production modification without CTO authorisation is a policy breach and SHALL be escalated to the BRC.

Every normal change SHALL have a documented and tested rollback plan. Rollback SHALL be initiated within the rollback window specified in the change request if post-deployment monitoring indicates the change has caused or contributed to a severity 1 or severity 2 incident. Rollback decisions require incident commander authority under OPS-002.

Change success rates, emergency change volumes, changes resulting in incidents, and rollback activations SHALL be reported to the BRC quarterly as indicators of change management effectiveness and release quality.

Satisfying modules¶

Module	Name	Mode	Description
MOD-150	Risk management platform	`LOG`	CI/CD pipeline deployment events auto-create change records with timestamp, artefact hash, environment, and outcome; post-implementation review is auto-scheduled for P1 changes.
MOD-156	CI/CD pipeline platform	`LOG`	Every pipeline execution, approval gate decision, and environment promotion is logged as an immutable event linked to the triggering commit and approver identity.

Part of Operational Resilience · Governance overview Compiled 2026-05-22 from source/entities/policies/OPS-006.yaml