MSP Change Advisory Board: Govern Changes Without Slowing Down

Your MSP pushed a Windows update last night. This morning, three line-of-business applications are not working. Nobody approved the change. Nobody tested it in a non-production environment. Nobody documented what was changed or how to roll it back.

This scenario plays out in MSP environments because there is no governance over changes. The opposite extreme — a heavyweight change process that requires six approvals and three weeks of review for a minor patch — is equally problematic because it creates technical debt and security risk through delayed maintenance.

The Change Advisory Board (CAB) is the middle ground: a structured but efficient governance mechanism that ensures changes are assessed, approved, and tracked without creating bureaucratic bottlenecks.

What a CAB Does

Core Functions

1. Risk Assessment Evaluate each proposed change for: - Impact on business operations - Risk of failure or adverse effects - Security implications - Compliance considerations - Dependencies on other systems

2. Approval Authority The CAB has the authority to: - Approve changes for implementation - Reject changes that are too risky or poorly planned - Defer changes pending additional information - Require modifications to reduce risk

3. Scheduling Coordinate change timing to: - Minimise business disruption - Avoid conflicts with other changes - Align with maintenance windows - Account for business-critical periods

4. Post-Implementation Review After changes are implemented: - Verify the change achieved its intended outcome - Document any issues or deviations - Update documentation as needed - Identify lessons for future changes

Types of Changes

Not all changes require the same level of CAB review:

Building Your CAB

Membership

Essential members: - CAB Chair (your IT manager or equivalent) — leads meetings, has final authority - MSP Technical Lead — presents change requests, provides technical assessment - Business Stakeholder — represents operational impact and priorities - Security Representative — evaluates security implications

Optional members (for larger environments): - Finance representative (for cost impact) - Compliance officer (for regulatory implications) - Department heads (for department-specific impacts)

Key principle: CAB members must have decision-making authority. A CAB where nobody can approve changes is a talking shop, not a governance body.

Meeting Structure

Regular CAB meetings:

Total time: 55-60 minutes, monthly

Change Request Template

Every change request should include:

1. Change ID — unique identifier
2. Date — when the change is proposed
3. Requestor — who is requesting the change
4. Description — what the change involves
5. Business justification — why the change is needed
6. Risk assessment — potential impact and likelihood of issues
7. Rollback plan — how to revert if the change fails
8. Testing — evidence of testing in non-production environment
9. Schedule — proposed implementation date and time
10. Impact — which systems and users are affected

The CAB Process

Step 1: Change Submission

The MSP submits a change request for each proposed change (except pre-approved standard changes). The request includes all required information and is submitted at least 5 business days before the proposed implementation date.

Step 2: CAB Review

The CAB reviews each change request:

• Risk assessment: Is the risk acceptable?
• Business justification: Is the change necessary?
• Testing: Has it been tested adequately?
• Rollback plan: Can it be reverted if it fails?
• Timing: Is the proposed schedule appropriate?

Step 3: Decision

The CAB makes one of four decisions:

Step 4: Implementation

The MSP implements the approved change: - Follows the approved implementation plan - Executes the rollback plan if issues arise - Documents what was actually done - Notifies affected users as agreed

Step 5: Post-Implementation Review

After implementation: - Successful: CAB confirms the change achieved its outcome, documentation is updated - Failed: CAB reviews what went wrong, rollback is executed, lessons are captured

Emergency Changes

Some changes cannot wait for the regular CAB cycle:

Emergency Change Criteria

• Critical security vulnerability requiring immediate patching
• System failure requiring immediate remediation
• Regulatory requirement with imminent deadline
• Business-critical issue that cannot wait for the next CAB meeting

Emergency Change Process

1. Requestor identifies the need for an emergency change
2. MSP assesses the risk and documents the emergency change request
3. Emergency CAB approval — CAB chair + one other member approve (can be via email or phone)
4. Implementation — MSP implements the change immediately
5. Retrospective CAB review — full CAB reviews the emergency change within 48 hours
6. Documentation — emergency change is fully documented post-implementation

What Is NOT an Emergency

• Routine patching that was not scheduled
• Convenience changes ("it would be nice to have")
• Changes that were deferred by the regular CAB
• "The MSP forgot to include this in the last CAB meeting"

Common CAB Failures

No CAB exists. Changes are made without governance, leading to incidents and finger-pointing.

CAB is too bureaucratic. Every change requires the full process, creating delays and driving change underground.

No business representation. Technical-only CABs miss business impact considerations.

Rubber-stamp CAB. The CAB approves everything without genuine assessment. This is worse than no CAB because it creates a false sense of governance.

No post-implementation review. Changes are approved but never verified as successful. Issues are not captured for learning.

Emergency change abuse. Too many changes labelled "emergency" to bypass the CAB. This indicates either CAB inflexibility or MSP process failure.

Balancing Control and Agility

The Right Level of Governance

The CAB should be as lightweight as possible while providing adequate oversight:

• Small environments (<50 users): Monthly CAB with 3-4 members, 30-minute meetings
• Medium environments (50-200 users): Monthly CAB with 4-6 members, 60-minute meetings
• Large environments (200+ users): Weekly or bi-weekly CAB with 6-8 members, 90-minute meetings

Pre-Approved Changes

Reduce CAB burden by pre-approving routine changes:

• Regular operating system patching (within defined parameters)
• Antivirus signature updates
• User account management (creation, modification, deletion)
• Standard configuration changes

Pre-approved changes are still documented and tracked, but do not require individual CAB review.

Continuous Improvement

The CAB should periodically review its own effectiveness:

• Are change-related incidents increasing or decreasing?
• Is the CAB process creating unnecessary delays?
• Are emergency changes being used appropriately?
• Are post-implementation reviews capturing useful lessons?

Related Guides

• MSP Service Level Management — SLA governance
• MSP Quality Management System — Quality frameworks
• MSP Technical Debt Assessment — Uncontrolled changes create debt
• MSP Project Management Methodology — Change in project context
• MSP Data Breach Response Plan — Emergency change in incident context