A change control board charter that actually governs.Nine roles, five priority levels, one decision cadence, and the low-risk paths that do not need to reach the CCB.

The Change Control Board (CCB) prioritizes, approves, plans, and integrates requests for changes and bug fixes into the current release (during project execution after requirements and/or design freeze) and into future releases.

• The CCB has decision authority on: what changes enter which release, what changes are rejected, what priority each open change carries, and whether a change meets the final-approval criteria for delivery.
• The CCB does NOT have decision authority on: release dates (set by release management / executive), technical implementation choices (owned by engineering), or defect severity (assigned by the bug-reporting process).
• Executive Management may override a CCB decision on approval or rejection. Executive overrides must be logged with rationale. Frequent overrides are a charter-review signal, the CCB is not operating with appropriate authority.

Any member of a project team may submit a Change Request (CR) to the CCB. The Change Request Form captures the following items:

A five-level descending scale plus an explicit rejection outcome. Every CR receives exactly one priority at each CCB review.

• 1 · Urgent, Request or bug fix must be implemented immediately. Emergency release or patch required. Triggers a CCB meeting within one business day (or disposition via email / conference call). Must be accompanied by a disposition plan.
• 2 · Essential, Request or bug fix is must-have or must-fix, respectively, for this scheduled release.
• 3 · Valuable, Request provides significant benefit (or fix addresses significant loss of value) to one or more customers / users in this scheduled release.
• 4 · Desirable, Request or fix should be in this release if possible within feature, budget, and schedule constraints; otherwise in the next scheduled release.
• 5 · Discretionary, Request or fix could be included whenever possible in some future release, subject to all other priorities.
• X · Rejected, Do not implement. Costs, issues, or risks outweigh benefits.

Bug fixes are handled through the CCB process, but no Change Request form is required, the bug report itself is the CCB artifact.

• If the CCB deems a bug report out of scope for the current release, the submitter may convert it into a change request (closing the bug and opening a new CR).
• Individual programmers, with consent of their managers, may dispose of low-risk, low-effort, medium-to-high-priority bug reports filed by other team members without CCB review. These disposals are still logged.
• High-severity bugs (S1 system-down, S2 major-feature-loss) always reach the CCB regardless of programmer-level disposal, because the CCB owns release integrity.

The CCB for each project consists of a representative (either the team manager or a responsible subordinate designated by the team manager) from each of the following groups. Smaller programs may consolidate roles; larger programs may split them. What cannot be consolidated is the distinction between who implements the change and who assesses its impact.

• a) Development, one representative responsible for each changed and affected subsystem.
• b) Test, test manager (or designate).
• c) Technical Support, support manager (or designate).
• d) System Operations, operations / SRE / platform lead.
• e) Finance, finance representative (for cost-impacting changes; may be consulted asynchronously for routine changes).
• f) Marketing, marketing representative (for externally-facing changes; skippable for internal or developer-facing changes).
• g) Sales, sales representative (for customer-commitment-impacting changes; skippable otherwise).
• h) Release Engineering, release engineering / CI-CD ownership.
• i) Project Management, project manager (CCB chair in most organizations).

The Change Control Board solicits impact statements from the project team for all proposed changes and bug fixes. At each regularly scheduled CCB meeting, the board reviews every outstanding change request and bug report filed since the last meeting. Priority-1 items trigger an out-of-cadence meeting (or asynchronous disposition via email / conference call) within one business day.

Each CCB member indicates final approval or rejection for each requested change or bug fix following implementation, testing, and release integration. Approval is against a specific, evidence-based criterion per role, not generic assent.

The classic CCB cadence is incompatible with continuous delivery if every commit routes through a weekly meeting. The adaptation is to name the low-risk paths that do not reach the CCB, and define the guardrails on those paths.

• Feature-flag toggles, turning an already-deployed, already-tested feature on or off for a subset of users does not require a CCB decision, but a post-hoc log entry and a two-person on-call sign-off do.
• Config-as-code rollouts, configuration changes in version control, reviewed and merged through the standard PR process, deployed via the pipeline, backed by an auto-rollback, do not require CCB approval. The commit history is the audit trail.
• SRE-owned runbook changes, operational responses to production incidents (restart a service, scale a fleet, roll back a bad deploy) are pre-authorized and log to the incident record, not the CCB.
• Routine security patches, patches that land through an automated dependency-update pipeline (Dependabot / Renovate plus a green CI) can merge automatically up to a defined CVSS ceiling; anything above the ceiling requires CCB.
• Automated canary and progressive rollout, deploys that traffic-split through automated canary analysis with automatic rollback on SLO breach do not need per-change CCB approval; the rollout policy itself is the CCB-approved artifact.
• For every low-risk path: a named owner, a defined guardrail, a logged audit trail, a published failure-mode list, and a quarterly review where the CCB re-validates the path. Silent bypass is not a low-risk path, it is a governance failure.

Three disciplines that were optional in the 2002 charter and are required in the 2026 enterprise environment.

• AI-assisted impact assessment is useful for surfacing affected subsystems and dependency trees; it is not a substitute for human sign-off. Record AI-generated impact assessments as advisory artifacts attached to the CR, and require the relevant human owner to confirm or correct before the CCB reviews.
• Observability artifacts are a standing CCB input. Every non-trivial change should name the dashboards, logs, and SLOs that will confirm the change is working after release. "No observability artifact" is a rejection condition for non-trivial changes.
• Rollback path is a first-class deliverable. Every approved change must have a documented rollback procedure, including data-migration rollback where state changes were made. "Cannot be rolled back" is a CCB decision, not an engineering afterthought.

The submitter of a change request attaches all appropriate supporting information to the CR in the change-control database. The CCB may request additional information, returning the CR to the submitter for further research and resubmission at a subsequent meeting. Prior to final approval, the project manager confirms that all deliverables required for implementation, testing, and integration of the release are complete, and release engineering confirms that all deliverables are checked into the project repository.