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:

  1. 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.
  1. Contact any relevant SMEs with questions.
  2. Submissions for the Pre-approved Changes list.
  3. 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:

  1.  Final Standard Patch Management reviews
    1. Ask any outstanding questions with SMEs present
  1. Vote to approve/reject changes
  2. Prioritize changes
  3. Schedule changes
  4. Review change deployments
  5. Discuss other business
    1. Review Exceptions List (Monthly)
    1. Review Pre-Approved List (Quarterly)
    1. Add to Exceptions List
    1. Flag and discuss Normal Changes that might be pre-approved as Standard Changes
    1. Process improvement initiatives
  1. Review and Accept minutes from previous meeting
  2. 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:

  1. 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.
  • Schedule change
  • Provide CAB with a Post-Implementation review.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: