Triage every change. Integrate only the approved ones.
Five phases around a Change Control Board.
Undisciplined change is the largest single risk to test completion. This process defines the Change Control Board loop — from intake through final approval — so nothing slips into a release untested or unscored.
Every change is a proposal to trade one set of risks for another. The CCB is the forum where that trade is made explicit — and therefore reversible.
Key Takeaways
Four things to remember.
Gather before you triage
A single intake queue for changes and bug fixes prevents shadow prioritization inside individual teams.
Assess cost, schedule, and risk together
A change that is cheap to implement can still be expensive to test or to release. Evaluate all three dimensions at intake, not after implementation.
Decide at the board, not at the desk
The whole point of a CCB is that prioritization and rejection happen in one forum with all stakeholders present. Out-of-band approvals corrupt the signal.
Approve inclusion, not just completion
Even a successfully implemented and tested change must clear a second gate before shipping — because the world may have changed while you were building it.
Why this exists
The problem this process fixes.
Change during a release is the default. The question is whether that change arrives through a clean process or through shadow channels — late bug fixes jammed in on Friday, feature flags flipped mid-cycle, "just one more thing" from a product owner after sign-off.
This process replaces the shadow channels with a Change Control Board loop. Five phases, one governance body, and two explicit gates: one at intake, one before inclusion. The result is a release whose contents can be defended.
The checklist
11 steps, in order.
- 1
Gather requested changes and bug fixes proposed for inclusion in the current, a future, or an emergency system release.
- Phase 2
Review proposed requests during a regular or emergency change control board meeting, via e-mail, or by conference call.
- 2.A
Assess associated feature, budget, schedule, and quality benefits, costs, issues, and risks for implementation, testing, and release. Defer consideration to a subsequent meeting and obtain clarifying information if necessary.
- 2.B
Prioritize or reject each request.
- 2.C
Identify implementation, testing, and release integration deliverables, and estimated completion dates for each request.
- 3
Plan, implement, test, and integrate the change or fix, noting new costs, benefits, issues, or risks.
- Phase 4
Present implementation, testing, and release integration results and deliverables for final approval.
- 4.A
Assess outstanding feature, cost, schedule, and quality costs, benefits, issues, and risks.
- 4.B
Weigh benefits of including change against costs, issues, and risks.
- 4.C
Approve or reject inclusion of the change in appropriate release.
- 5
If approved, check new or changed system components, project documents, and other deliverables into configuration management.
One more thing
The cost of change control is felt at intake; the cost of skipping it is felt at release. Teams that treat the CCB as optional will eventually release a change they could not have defended — and the first release after that is when discipline becomes easy to enforce.
Take it with you
Download the piece you just read.
We keep this library free. All we ask is that you tell us who you are, so we know who to follow up with if we release an updated version. One-time form, this browser remembers you after that.
Related in the library
Pair this with.
Need a QA program to back this up in your organization?
If a checklist is not enough and you want help applying it to a live engagement, we can have a call this week.
Related reading
Articles, talks, guides, and case studies tagged for the same audience.
- Whitepaper
Evaluation Before Shipping: How to Test an AI Application Before It Hits Production
The release-gate playbook for AI features. Covers the five evaluation dimensions, how to build a lean golden set, where LLM-as-judge is trustworthy and where it lies, rollout mechanics with named exit criteria, and the regression suite that keeps a shipped AI feature from quietly rotting in production.
Read → - Whitepaper
Choosing the Right Model (and Knowing When to Switch)
A practical framework for matching LLM model tier to task. Covers the four axes (capability, latency, cost, reliability), cascade routing patterns that cut cost 60 to 80 percent without measurable quality loss, switching costs you did not plan for, and the worked economics at 10K, 100K, and 1M decisions per day.
Read → - Whitepaper
Beyond ISTQB: A Multi-Domain Certification Roadmap for Technical L&D
Most engineering L&D programs over-index on a single certification family, usually ISTQB on the QA side, AWS on the infrastructure side, and under-invest across the rest of the technical domains the org actually needs. This paper covers a multi-domain certification roadmap (QA, AI, cloud, data, security, project management, software engineering) with sequencing logic for each level of the engineering ladder, plus the maintenance discipline that keeps the roadmap relevant as the technology shifts underneath it.
Read → - Guide
The ISTQB Advanced Level path, mapped
The Advanced Level landscape keeps changing — CTAL-TA v4.0 shipped May 2025, CTAL-TM is on v3.0, CTAL-TAE is on v2.0. This guide maps all four core modules, prerequisites, exam formats, sunset dates, and which module a given role should take first. Links directly to the authoritative istqb.org syllabi.
Read → - Whitepaper
Bug Triage: A Cross-Functional Framework for Deciding Which Defects to Fix
Bug triage is the cross-functional decision process that converts raw defect reports into prioritized action. Done well, it optimizes limited engineering capacity against risk; done poorly, it becomes a backlog-management ritual that neither fixes the important defects nor drops the unimportant ones. This whitepaper covers the triage process, the participants, the six action outcomes, the four decision factors, and the governance disciplines that keep triage effective in continuous-delivery environments.
Read → - Whitepaper
Building Quality In: What Engineering Organizations Do from Day One
Testing at the end builds confidence, but the most efficient quality assurance is building the system the right way from day one. This whitepaper covers the upstream disciplines — requirements clarity, lifecycle selection, per-unit programmer practices, and continuous integration — that make system-level testing cheap and fast rather than the only thing holding a release together.
Read →
Where this leads
- Service · Quality engineering
Software Quality & Security
Independent test programs, security testing, and quality engineering for systems where defects cost real money.
Learn more → - Solution
Risk Reduction & Clear Decisions
Quality programs and decision frameworks that shift risk discussions from anecdote to evidence.
Learn more → - Solution
Reliable Software at Scale
Quality engineering programs for organizations whose software is now operationally critical.
Learn more →