In plain English.

A Change Control Board is the governance primitive that says who has decision authority on what, and at what cadence. Every change management process (the checklist, the priority scale, the form) is downstream of that question.

This charter gives you:

• Scope, what the CCB decides, what it doesn't.
• A nine-field change request form.
• A five-level priority scale (plus explicit rejection).
• Nine CCB roles with per-role final-approval criteria.
• The low-risk paths that skip the CCB safely, named, with guardrails.

What the CCB decides.

• Which changes enter which release.
• Which changes are rejected.
• What priority each open change carries.
• Whether a change meets final-approval criteria for delivery.

What the CCB does not decide: release dates (set by release management / executive), technical implementation (owned by engineering), defect severity (assigned by the bug-reporting process). Clean decision-rights.

Logged. Always logged.

Executive Management may override a CCB approval or rejection. Overrides must be logged with rationale.

Frequent overrides are a charter-review signal, the CCB is not operating with appropriate authority, and the organization is working around it instead of fixing it.

Definition, subsystems, priority.

• a · Definition of the change. What and why. Customers and users requesting and affected.
• b · Subsystems changed. At least one, often more.
• c · Unchanged subsystems affected. Dependencies, integrations, shared data.
• d · Documentation to be updated. Internal (project plan, test plan, specs) and deliverable (user guide, API reference, runbook, release notes).
• e · Priority. Submitter's proposal, CCB may revise.

Dependencies, cost, effort, date.

• f · Dependencies. Linkages to other pending changes, decisions, or assumptions.
• g · Cost or savings. Estimated cost / savings + post-release benefits.
• h · Effort. Estimated person-hours to implement, test, and integrate.
• i · Requested completion date. Date by which implementation, test, and integration should be complete.

Every CR gets exactly one.

• 1 · Urgent, must be implemented immediately. Emergency release. Within-one-business-day disposition.
• 2 · Essential, must-have / must-fix for this scheduled release.
• 3 · Valuable, significant benefit or loss-of-value in this release.
• 4 · Desirable, include if feasible within constraints; otherwise next release.
• 5 · Discretionary, include when possible in some future release.
• X · Rejected, do not implement. Costs / issues / risks outweigh benefits.

Every CR scored. No exceptions. Teams that let "everything is urgent" through stop using the CCB within a year.

Development, Test, Support, Ops, Finance.

• a · Development, one rep per changed or affected subsystem.
• b · Test, test manager (or designate).
• c · Technical Support, support manager (or designate).
• d · System Operations, operations / SRE / platform lead.
• e · Finance, cost-impacting changes; consulted async for routine.

Marketing, Sales, Release Eng, PM.

• f · Marketing, externally-facing changes.
• g · Sales, customer-commitment-impacting changes.
• h · Release Engineering, CI/CD ownership; deliverable check-in.
• i · Project Management, CCB chair in most organizations.

Smaller programs may consolidate roles. What cannot be consolidated: the distinction between who implements a change and who assesses its impact.

Gather, review, implement.

• Step 1 · Gather. All requested changes and bug fixes proposed since last meeting.
• Step 2 · Review. At regular or emergency meeting. Assess → Prioritize → Identify deliverables.
• Step 3 · Implement. Plan, code, test, integrate. Update the CR with anything new that surfaces.

Final review, integrate.

• Step 4 · Final review. Present results to the CCB. Assess outstanding → Weigh benefits vs. costs → Approve or reject inclusion.
• Step 5 · Integrate. If approved: check all new and changed components into configuration management (source repo, IaC repo, documentation system, release notes).

Priority-1 items trigger an out-of-cadence meeting or asynchronous disposition within one business day.

Evidence. Not assent.

Each dev manager approves if (1) the change has no impact on their subsystems, OR (2) the dev team has fully unit- and component-tested all anticipated impacts, AND the manager has reported any material technical or business impact to the CCB.

"Development approved" ≠ "Development said yes in the meeting." Every role's approval is gated on evidence.

Risks assessed and mitigated.

The test manager approves if (1) the test team has subjected the change to an agreed-upon set of tests, AND (2) the test manager has presented results to the CCB including risks assessed and mitigated and risks not yet assessed or mitigated.

The second half is load-bearing. Naming unmitigated risk explicitly is what lets the CCB weigh an approval honestly.

Runbooks. Rollback. Response.

These two criteria close the loop between release and operations. Without them, the CCB is signing off on code only.

Finance. Marketing. Sales.

• Finance, financial impacts or risks are understood and acceptable.
• Marketing, marketing benefits outweigh business or technical risks.
• Sales, (1) one or more customers requires the change, AND (2) benefits outweigh risks.

Short criteria, real authority. Business sign-off prevents engineering-only decisions from shipping with zero commercial awareness.

Checked-in. Closed.

Nine criteria. Nine sign-offs. That's the anti-rubber-stamp mechanism.

Five categories. Named, guarded.

• Feature-flag toggles, post-hoc log + two-person on-call sign-off.
• Config-as-code, PR process + pipeline + auto-rollback.
• SRE runbook responses, pre-authorized; logs to the incident record.
• Routine security patches, auto-merge up to a CVSS ceiling; above = CCB.
• Automated canary rollouts, the rollout policy is the CCB artifact.

Silent bypass is not a low-risk path. It is a governance failure. Every low-risk path: named owner, defined guardrail, logged audit trail, published failure-mode list, quarterly CCB review.

Advisory. Gate. First-class.

• AI-assisted impact assessment is useful for surfacing affected subsystems. Not a substitute for human sign-off. Record as advisory; human owner confirms.
• Observability artifacts are standing CCB input. Every non-trivial change names the dashboards, logs, and SLOs that confirm it's working. No observability artifact = rejection condition.
• Rollback path is first-class deliverable. Including data-migration rollback. "Cannot be rolled back" is a CCB decision, not an engineering afterthought.

Decision forum. Not meeting.

• Governance primitive. Decision rights first; everything else follows.
• Priority is a forcing function. Every CR scored; "everything is urgent" kills the board.
• Per-role approval criteria keep the CCB from becoming ceremony.

Name the bypass. Govern it.

• Name the low-risk paths that skip the CCB. With guardrails. Silent bypass is worse.
• Rollback path is a deliverable. Including data migrations.
• Observability artifacts are a standing input. No artifact = no approval.