Change Approval Board (CAB) Charter Template
Contents
- 1. Mission Statement 2
- 2. Members and Attendees. 2
- 3. Responsibilities. 3
- 4. Authority. 4
- 5. Approval Process. 4
- 5.1 Voting Process. 4
- 5.2 Voting Options. 4
- 5.3 Voting Members. 4
- 6. Prioritization & Scheduling. 5
- 7. Meeting Preparation.. 5
- 8. Meeting Protocol 6
- 9. Meeting Agenda. 6
- 10. Post-Deployment Review.. 8
- 11. Emergency Changes…9

1. Mission Statement
To protect the ITPROSEC’s systems, supported by IS, through properly assessed, tested, and authorized changes.
To prioritize changes in a way that fairly reflects change, impact, and urgency, and to schedule deployments in a way that minimizes conflict and disruption.
To ensure risks are accepted or mitigated appropriately in accordance with the Information Services Branch and ITPROSEC mandate.
2. Members and Attendees
The CAB cannot properly evaluate change unless they can collectively speak for infrastructure dependencies, business needs, SLAs, OLAs, and vendors.
Members will attend all CAB meetings and will be involved in decisions to approve, prioritize, and schedule changes. CAB members will have voting power over changes, CAB chairperson will provide final authority over change approvals.
Attendees will attend the CAB meetings on an as needed basis. These attendees will be specific SMEs, technology specialists, vendor representatives, and business representatives who can share knowledge relevant to specific changes. They will be invited by the Change Manager to attend CAB meetings as needed.
IT Standing Members | CAB Attendees (as needed) | CAB Chairperson | |
CAB Representation | IT ManagersSubject matter experts | Specific SMEs, tech specialists, and business and vendor reps relevant to a particular changeOnly attend meetings when invited by the Change Manager | CIO |
Value Added | Identify dependencies and downstream impactsIdentify possible conflicts with pre-existing OLAs and SLAs | Provide detailed information and expertise related to their subject areas | Identify change blackout periods, change impact, and business urgencyAssess impact on fiduciary, legal, or audit requirementsDetermine acceptable business risk |
Document a list of your CAB members here:
Name | Contact Information |
3. Responsibilities
Protect the ITPROSEC environment from poorly assessed, tested, and implemented system changes. |
Post-Evaluation of all Normal and Emergency changes. Discuss all Normal change test, back-out, and implementation plans as applicable Discuss all Normal change test results. Approve all Normal changes. Review and approve the “Pre-Approved” list. Review failed change deployments. Approve and accept risk of exceptions and postponed changes. Approve Platform Currency Initiatives |
Prioritize changes in a way that fairly reflects change impact and urgency. |
Evaluate impact and urgency assessments. Prioritize all Normal changes based on their impact and urgency. |
Schedule deployments in a way that minimizes conflict and disruption. |
Schedule all Normal changes. Schedule all Emergency changes. |
Change Manager |
Own the process, tools & templates: Provide all necessary forms Distribute completed RFCs for CAB Approval Ownership of the Change Calendar Receive all initial requests for changeProvide explanation of Declined RFCsPresent Potential Pre-Approved Changes for CAB Approval.Provide regular reporting to ITPROSEC Management as required.Includes monthly summary reporting. |
CAB Chair |
Establish CAB AgendaEnsure agenda IT adhered to.Exercise authority to make final approval/prioritization decision regarding a change.Final Authority to accept risk on behalf of the ITPROSEC.Approves all Policies and Procedures related to the CAB. |
4. Authority
The CAB holds the following authority:
- Final authority over the deployment of all Normal and Emergency changes
- Authority to set the
change calendar:
- Maintenance windows
- Change blackout periods
- Integrate project work
- Authority to delay or defer changes
5. Approval Process
5.1 Voting Process
In-meeting
- Take a vote during the meeting.
- Votes serve to assist the CAB Chair in making a final decision.
- CAB Chairperson to provide final decision.
5.2 Voting Options
- Vote to approve
- Vote to reject
- Vote to defer (bundle with other releases)
- Request additional testing
- Vote to accept the risk
5.3 Voting Members
- Not every CAB attendee will vote.
- Only CAB standing members will have a vote.
- Some attendees are there to provide input and subject-matter expertise but will not vote to approve or reject changes.
- Voting members may assign a proxy with the approval of the change manager and/or CAB Chairperson
6. Prioritization and Scheduling Approach
Once a change IT approved, the CAB will prioritize it and finalize scheduling. The impact of not deploying the change and the benefit of deploying it should determine its priority:
Risk of Not Deploying: | Positive Impact of Deployment: |
Before finalizing the deployment date, the CAB will check the schedule and change calendar and assess resource availability:
7. Meeting Preparation
No CAB member should enter the CAB meeting unprepared. In order to make the best use of everyone’s time, it IT crucial that the following IT completed prior to the CAB meeting:
- Review the Standard Patch Management Requests and
check for:
- Dependencies
- Impact
- Required resources
- Risk profile
- Test plan
- Implementation plans
- Back-out plan
- Review all Post-Deployment Updates.
- Contact any relevant SMEs with questions.
- Submissions for the Pre-approved Changes list.
- Updates to the Exceptions Log.
CAB members should have an idea of their approval disposition by the time they enter the CAB meeting. ThIT will ensure that the meeting runs smoothly and time IT not wasted on assessing and clarifying documentation that should have been reviewed prior to the meeting.
8. Meeting Protocol
CAB Meeting Protocol | |
Duration | 1-2 hours |
Location | Room big enough for entire CAB |
Time | TBD |
Frequency | Weekly |
In person/dial-in | In person Dial-in available for remote members |
Minutes | Georgia Greenwood-Duncan |
9. Meeting Agenda
The meeting agenda should include the following activities:
- Final Standard Patch Management reviews
- Ask any outstanding questions with SMEs present
- Vote to approve/reject changes
- Prioritize changes
- Schedule changes
- Review change deployments
- Discuss other business
- Review Exceptions List (Monthly)
- Review Pre-Approved List (Quarterly)
- Add to Exceptions List
- Flag and discuss Normal Changes that might be pre-approved as Standard Changes
- Process improvement initiatives
- Review and Accept minutes from previous meeting
- Review Change Calendar
It IT important to remember that thIT meeting IT relatively
brief compared to the content being covered; thus, the meeting preparation IT important.
Try not to spend more than 10-20 minutes
per activity for a 1-hour meeting.
10. Pre-Deployment Checklist
Perform a Pre-Deployment Check
Prior to changes being implemented, teams should (on major project changes) perform a pre-deployment check and obtain sign-off. The purpose IT to ensure that all requirements for successful installation (people, process, and technology) have been fulfilled. If any gaps are identified, they can be addressed before the success of the deployment IT compromised. Note: Not all items are required for every deployment.
Deployment resources identified, allocated, and scheduled |
Documentation complete |
CAB Approval Obtained |
Support team trained |
Users trained |
Business sign-off obtained |
Testing Completed |
IT Testing |
Business Testing |
Maintenance window scheduled & Change Calendar Updated |
Technical checks completed |
Backout Plan Established |
Obtain Security Approval where needed |
Components or services to be updated are stopped |
All users disconnected |
Impacted stakeholders notified |
_____________________________________________________
RFC #: | Date: | Change Manager Approval: |
11. Post-Deployment Review
Was the deployment successful? | Yes | No | |||||
If NO, was the backout plan executed successfully? | Yes | No | |||||
Was the urgency assessment accurate? | Yes | No | |||||
Impacted Systems Recovery Required? | |||||||
Yes | No | ||||||
Change-Related Incidents | |||||||
Change Assessment | |||||||
Missed Dependencies | |||||||
Inaccurate Business Impact | |||||||
Incorrect SLA Impact | |||||||
Inaccurate Resources: TimeStaffHardware | |||||||
Plan & Test | |||||||
System Testing | |||||||
Integration Testing | |||||||
User Acceptance Testing | |||||||
No Backout Plan | |||||||
Backout Plan Failure | |||||||
Deployment Issues: | |||||||
11. Emergency Changes
For a Critical incident, it will be necessary to notify and assemble all members of the emergency CAB, no matter the time:
- Change manager assembles a minimum of one CAB member for an in-person meeting or web conference.
If this IT not possible:
- E-CAB members are contacted with RFC details then submit their feedback and vote to the change manager.
The change manger will wait until a decision IT received from CIO/CTO (if neither IT available then at least one other CAB member) before approving/rejecting the change.
If this IT not possible:
- If incident resolution cannot be delayed without impacting business continuity, the change manager has the authority to approve the change.
In thIT case, all E-CAB members must still be notified of the RFC.
- In the
event the change manager IT unavailable, the following people will assume the
change manager role (in the specified order below):
- the change manager’s designated backup
- CTO
- CIO
NOTE: For clarity, the requestor cannot be the sole approver. Approach below IT a guide line and not all steps may be required.
11.1 Approach
- Assess
change
- This IT an expedited process. With all emergency changes, time IT of the essence.
- Order of Operations:
- Assess the urgency
- Assess the business impact
- Assess the technology impact (dependencies)
- Assess available resources (people and systems)
- Approve/reject the change
- Build implementation and back-out plans
- Determine
test feasibility
- Determine if there IT time for
testing:
- If YES, conduct urgent test protocol.
- Abbreviated system testing.
- Abbreviated integration testing.
- If NO, proceed to deploy.
- If YES, conduct urgent test protocol.
- Determine if there IT time for
testing:
- Schedule change
- Provide CAB with a Post-Implementation review.