STD-021: Change Advisory Board (CAB) Process

CHLA change management process using iTrack. Every infrastructure change that affects production systems requires a Change record, CAB review, and post-implementation validation.

Applicability

This standard applies to work (CHLA) changes only. Personal/home infrastructure changes follow STD-005 (Change Control) without CAB requirements.

iTrack Change Record

Every change MUST have an iTrack Change record with all required fields populated before implementation begins.

Details Tab — Required Fields

Field	Guidance
Summary	One-line description: what is being changed and why
Description	Technical detail — enough for another engineer to understand the change without asking questions
Requested By	Person requesting the change (may differ from implementer)
Manager	Direct manager of the requester
Director	Director in the reporting chain
Implementer(s)	All personnel performing configuration changes — list each person and their scope
Start Date / End Date	Change window — must be within approved maintenance windows
Down Time Required?	Yes/No — if yes, specify duration and affected services
Affected Users	Who will experience impact during the change

Field

Guidance

Summary

One-line description: what is being changed and why

Description

Technical detail — enough for another engineer to understand the change without asking questions

Requested By

Person requesting the change (may differ from implementer)

Manager

Direct manager of the requester

Director

Director in the reporting chain

Implementer(s)

All personnel performing configuration changes — list each person and their scope

Start Date / End Date

Change window — must be within approved maintenance windows

Down Time Required?

Yes/No — if yes, specify duration and affected services

Affected Users

Who will experience impact during the change

Change Plans Tab — Required Fields

Field	Guidance
Detailed Implementation Plan	Step-by-step procedure with verification commands. Reference the CR document (xref to case-studies/changes/)
Detailed Backout Plan	How to reverse every change if the implementation fails. Must be tested or validated as feasible
Detailed Testing Plan	Pre-CAB testing: what was validated before requesting approval. Post-production testing: what will be validated after implementation
Detailed Communication Plan	Who is notified, when, and how (email, Teams, Slack) — before, during, and after
Risk Analysis/Mitigation Plan	Risks identified, likelihood, and mitigation strategy
Benefits Of Change	Business justification — why this change matters
Pre-CAB Testing Approval Date(s)	Date pre-implementation testing was completed
Pre-CAB Validation By	Person who validated the testing
Post-Production Validation Date(s)	Date post-implementation validation will occur
Post-Production Validation By	Person responsible for confirming success

Field

Guidance

Detailed Implementation Plan

Step-by-step procedure with verification commands. Reference the CR document (xref to case-studies/changes/)

Detailed Backout Plan

How to reverse every change if the implementation fails. Must be tested or validated as feasible

Detailed Testing Plan

Pre-CAB testing: what was validated before requesting approval. Post-production testing: what will be validated after implementation

Detailed Communication Plan

Who is notified, when, and how (email, Teams, Slack) — before, during, and after

Risk Analysis/Mitigation Plan

Risks identified, likelihood, and mitigation strategy

Benefits Of Change

Business justification — why this change matters

Pre-CAB Testing Approval Date(s)

Date pre-implementation testing was completed

Pre-CAB Validation By

Person who validated the testing

Post-Production Validation Date(s)

Date post-implementation validation will occur

Post-Production Validation By

Person responsible for confirming success

Change Lifecycle

State	Description
Logged	Change record created, fields populated. Not yet submitted for review.
Reviewed	CAB has reviewed the change. Questions addressed, schedule confirmed.
Approved	CAB approved implementation. Change window is authorized.
Implemented	Change executed during the approved window. Post-validation in progress.
Closed	Post-implementation validation complete. Change record finalized.
Cancelled	Change withdrawn before implementation.
Failed	Backout executed. Requires incident report (STD-011) if service impacted.

State

Description

Logged

Change record created, fields populated. Not yet submitted for review.

Reviewed

CAB has reviewed the change. Questions addressed, schedule confirmed.

Approved

CAB approved implementation. Change window is authorized.

Implemented

Change executed during the approved window. Post-validation in progress.

Closed

Post-implementation validation complete. Change record finalized.

Cancelled

Change withdrawn before implementation.

Failed

Backout executed. Requires incident report (STD-011) if service impacted.

Personnel Roles

Role	Responsibility
Requester	Identifies the need, creates the iTrack record, provides business justification
Implementer(s)	Execute the technical change during the approved window. Multiple implementers are common (e.g., network engineer + NAC engineer)
Tester / Validator	Verifies the change works as expected — independent from implementers where possible
CAB Reviewer	Reviews the change plan for completeness, risk, and scheduling conflicts

Role

Responsibility

Requester

Identifies the need, creates the iTrack record, provides business justification

Implementer(s)

Execute the technical change during the approved window. Multiple implementers are common (e.g., network engineer + NAC engineer)

Tester / Validator

Verifies the change works as expected — independent from implementers where possible

CAB Reviewer

Reviews the change plan for completeness, risk, and scheduling conflicts

Scheduling

Standard changes: Submit 5+ business days before the change window
Emergency changes: CAB chair approval required — document retroactively within 24 hours
Freeze periods: No non-critical changes during declared freezes (e.g., mobile release cuts, quarter-end)
Change windows: Coordinate with the CHLA change calendar to avoid conflicts

Cross-Reference

STD-005 (Change Control) — the verify-change-verify pattern applies to every command within a CAB-approved change
STD-011 (Incident Response) — failed changes that impact service trigger incident workflow
STD-013 (Case Studies Taxonomy) — CR- documents in domus-captures provide the detailed implementation plan