Skip to content

Change and release management
Code DT-007
Domain Data & Technology
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 · DTA Outsourcing Standard

Governs the approval, execution, documentation, and rollback of all changes to bank systems and infrastructure across all environments.

Scope

Applies to all changes to production systems, infrastructure, configuration, and data schemas across all eight code repositories and their cloud environments. Changes to dev and UAT environments are subject to the pipeline requirements in DT-010.

Change categories

Category Definition Approval required Pipeline gate
Standard Routine change following established, pre-approved pattern (e.g. feature deploy via CI/CD pipeline) Pre-approved — no additional approval Full pipeline must pass
Normal Planned change with lead time ≥ 48 hours Tech lead + relevant domain owner Full pipeline must pass
Emergency Unplanned change required to restore service or prevent material harm CTO or delegate Expedited pipeline — no gates skipped
Unauthorised Any change to prod made outside of an approved change record Not applicable — prohibited Triggers incident process

Standard changes (CI/CD deployments)

Deployments executed via the CI/CD pipeline that have passed all automated test gates are pre-approved standard changes. The pipeline log constitutes the change record. No additional approval is required unless the deploy triggers a Normal or Emergency flag.

Normal change process

  1. Submitter raises a change request in the change management system with: description, rollback plan, impacted systems, and scheduled window.
  2. Tech lead reviews and approves or rejects within 24 hours.
  3. For changes touching customer data, payments, or compliance modules: domain owner co-approval required.
  4. Change is executed during the approved window. Actual execution is via the CI/CD pipeline — no manual steps.
  5. Post-implementation review completed within 24 hours of deployment.

Emergency change process

Emergency changes bypass the standard lead time but do not bypass pipeline gates.

  1. Engineer notifies CTO or on-call delegate verbally before execution.
  2. A change record is created concurrently with or immediately after the change.
  3. The pipeline runs at expedited priority. All automated test gates still apply.
  4. A post-incident review is completed within 48 hours of the emergency change.
  5. All emergency changes are reviewed at the next change advisory board (CAB) session.

Change advisory board (CAB)

The CAB meets weekly to review: upcoming Normal changes, completed Emergency changes, and change failure rate trends. Attendees: CTO, Head of Platform Engineering, relevant domain tech leads.

Rollback requirements

Every change must have a documented rollback plan before it is approved. For CI/CD pipeline deployments, the rollback plan is automatic: the pipeline redeploys the previous immutable image. For schema migrations or data changes: a down-migration script must exist and be tested before the change proceeds.

Rollback triggers: - Automated: smoke tests fail within 5 minutes of prod deployment - Manual: on-call engineer observes degradation and triggers rollback via pipeline

Change failure rate target

See NFR-030 — change failure rate (prod deploys requiring rollback) shall be ≤ 5%.

Prohibited practices

  • Manual changes to production environments outside of a CI/CD pipeline
  • Bypassing a failed pipeline gate without a documented exception approved by the CTO
  • Deploying to prod without a passing UAT pipeline run for the same image
  • Storing change approval evidence only in chat or email — all approvals must be recorded in the change management system

Satisfying modules

Module Name Mode Description
MOD-156 CI/CD pipeline platform GATE No module may be deployed to any environment without the CI pipeline passing all mandated checks — no manual bypass path exists.

Part of Data & Technology · Governance overview Compiled 2026-05-22 from source/entities/policies/DT-007.yaml