This chapter covers the Change Advisory Board (CAB) process, a critical component of ITIL-based change management that appears in roughly 5-8% of N10-009 exam questions, primarily in Domain 3.2 (Network Operations). You will learn the CAB's role in reviewing, approving, and overseeing changes to network infrastructure, the types of changes (standard, normal, emergency), and how the process ensures stability while enabling necessary updates. Mastering this topic helps you answer scenario-based questions about change management procedures and identify where a CAB would be required.
Jump to a section
Think of the Change Advisory Board (CAB) like the airport security committee that approves changes to terminal operations. An airline (change requester) wants to install a new boarding gate system. They submit a request to the committee detailing the equipment, schedule, and impact on flights. The committee, which includes security, operations, and maintenance representatives, reviews the request. They consider risks: will the installation disrupt passenger flow? Are there backup systems if the new gate fails? They may require a test during low-traffic hours (maintenance window) and mandate a rollback plan if something goes wrong. Once approved, the change is scheduled, and the team proceeds. After implementation, the committee reviews the outcome to ensure no issues. Just as the committee balances efficiency and safety, the CAB balances innovation and stability. If the committee ever bypassed review for a 'minor' change that later caused a security breach, they'd learn that all changes, even seemingly small ones, need proper scrutiny. This mirrors ITIL's principle that every change, regardless of size, should follow a defined process to prevent unauthorized modifications that could disrupt services or introduce vulnerabilities.
What is the Change Advisory Board (CAB)?
The Change Advisory Board (CAB) is a group of stakeholders responsible for reviewing, assessing, and approving or rejecting proposed changes to the IT infrastructure, including network devices, configurations, and services. It is a key element of ITIL (Information Technology Infrastructure Library) change management practices. The CAB does not implement changes; it provides oversight to ensure changes are beneficial, risks are understood, and proper planning is in place.
Why the CAB Exists
Uncontrolled changes are a leading cause of network outages and security incidents. The CAB provides a formal checkpoint to:
Assess risk and impact of changes on business services.
Ensure changes align with business objectives and policies.
Coordinate changes to avoid conflicts (e.g., two teams modifying the same router).
Verify that rollback plans exist if a change fails.
Maintain a change schedule and history for auditing.
How the CAB Process Works – Step by Step
The CAB process follows the ITIL change management lifecycle:
Request for Change (RFC) Creation: Anyone can submit an RFC via a ticketing system (e.g., ServiceNow, Jira). The RFC must include:
Description of the change.
Justification (why is it needed?).
Configuration items affected (e.g., specific routers, firewalls).
Implementation plan (steps, timeline).
Rollback plan (how to revert if failure occurs).
Risk assessment (low/medium/high).
Change type: standard, normal, or emergency.
RFC Logging and Categorization: The change manager logs the RFC and categorizes it. Standard changes are pre-approved (e.g., adding a user to a VLAN). Normal changes require CAB review. Emergency changes (e.g., security patch for an active breach) follow a fast-track process, often with a smaller Emergency CAB (ECAB).
CAB Meeting: The CAB meets regularly (weekly or bi-weekly) to review normal changes. Members include:
Change manager (chair).
Network engineers (for technical impact).
Security team (for security risks).
Application owners (if apps are affected).
Business representatives (for business impact).
Vendors or third-party experts (if relevant).
Assessment and Voting: Each change is assessed based on:
- Risk level (probability × impact). - Resource availability (staff, hardware). - Schedule conflicts (other changes happening simultaneously). - Compliance with policies (e.g., PCI-DSS). The CAB votes: approve, approve with conditions (e.g., require additional testing), reject (with reasons), or defer (wait for more information).
Implementation: Approved changes are scheduled during maintenance windows. The change manager assigns an implementer (e.g., network engineer) who executes the plan. Communication is sent to stakeholders.
Review and Closure: After implementation, the change is reviewed (post-implementation review, PIR). If successful, the RFC is closed. If issues occurred, lessons are documented to improve future changes.
Key Components and Defaults
- RFC: Unique identifier (e.g., CHG0012345). Fields: priority (1-4), impact (1-4), urgency (1-4). - Change Types: - Standard: Pre-approved, low risk, repeatable (e.g., firmware update for known devices). No CAB needed. - Normal: Requires CAB approval. Includes all non-standard changes. - Emergency: High urgency (e.g., security vulnerability). Fast-tracked by ECAB within hours. - CAB Meeting Frequency: Typically weekly, but can be daily for critical environments. - Quorum: Usually 50%+1 of members required to vote. - Emergency CAB (ECAB): A subset of CAB members (e.g., change manager, security lead, network lead) who can approve emergency changes outside normal meetings. - Change Window: Scheduled time when changes are allowed (e.g., 2 AM – 6 AM Sunday). - Rollback Plan: Mandatory for all normal and emergency changes. Must include steps to restore previous state. - Post-Implementation Review (PIR): Conducted 1-2 weeks after implementation to verify success and capture lessons.
Configuration and Verification in Tools
While the CAB process is not a device configuration, it is managed via ITSM tools. Example workflow in ServiceNow:
To create an RFC:
Navigate to Change Management > Create New.
Fill fields: Short description, Justification, Risk (1-4), Impact (1-4), Urgency (1-4).
The system auto-calculates priority (e.g., urgency×impact).
Submit; the change manager assigns a CAB meeting.
To verify change status:
- Query: SELECT * FROM change_request WHERE status = 'scheduled'
- Or in ServiceNow: sys_id=CHG0012345
Interaction with Related Technologies
The CAB process interacts with: - Configuration Management Database (CMDB): The CAB uses CMDB to identify affected CIs (configuration items). Example: a change to a core switch is linked to the switch's CI record. - Problem Management: If a change causes an incident, the problem management process investigates to prevent recurrence. - Incident Management: Emergency changes often arise from incidents (e.g., outage). The CAB reviews the incident to approve a fix. - Release Management: Major changes may be bundled into releases. The CAB approves the release, not individual changes. - Network Monitoring: After a change, monitoring tools (e.g., SNMP, NetFlow) verify that performance metrics remain within baseline.
Exam-Relevant Numbers and Terms
CAB vs. ECAB: Know that ECAB handles emergency changes; it has fewer members and meets as needed.
Change Advisory Board vs. Change Manager: The change manager is a role, not the board. The manager chairs the CAB and manages the process.
RFC fields: Priority = urgency × impact (ITIL). Impact: 1=extensive, 4=narrow. Urgency: 1=immediate, 4=low.
Standard changes: Do NOT require CAB approval. Examples: password resets, adding new users to a group.
Emergency changes: Require documented justification for bypassing normal CAB. Must be reviewed retrospectively.
Post-implementation review: Required for all significant changes to capture lessons learned.
CAB meeting minutes: Must be recorded for audit purposes.
Common Misconfigurations and Issues
Bypassing CAB: A team implements a change without approval, causing an outage. This violates ITIL and often leads to disciplinary action.
Incomplete RFC: Missing rollback plan leads to extended downtime when change fails.
Poor risk assessment: Underestimating risk leads to unexpected outages. Overestimating causes delays.
CAB not representative: Missing security or business members leads to overlooked impacts.
Emergency change abuse: Teams label changes as 'emergency' to avoid CAB review. This is a red flag for auditors.
Submit Request for Change
A network engineer or stakeholder identifies a need for change, such as upgrading a router IOS. They create an RFC in the ITSM tool, providing details: description, justification, affected CIs (e.g., router RTR-01), implementation steps, rollback plan, and risk assessment. The RFC is assigned a unique ID and logged with status 'draft' or 'submitted'. The change manager reviews the RFC for completeness and categorizes it as standard, normal, or emergency. If standard, it proceeds directly to implementation without CAB. If normal, it is added to the next CAB meeting agenda. If emergency, it triggers the ECAB process.
CAB Meeting Review
The CAB meets (typically weekly) to review normal RFCs. The change manager presents each RFC, summarizing the change, risk, impact, and rollback plan. Members discuss potential conflicts with other scheduled changes, resource availability, and security implications. Each member votes: approve, approve with conditions, reject, or defer. Quorum must be met (e.g., >50% of members). The decision is documented in meeting minutes. If approved with conditions, the RFC is updated with required actions (e.g., 'must test in staging first'). If rejected, the RFC is closed with reason.
Schedule and Implement Change
Once approved, the change manager schedules the change during a maintenance window (e.g., Sunday 2-4 AM). The implementer (e.g., senior network engineer) executes the implementation plan. They may use change windows to minimize business impact. During implementation, they follow the plan step by step, and if something goes wrong, they execute the rollback plan. The change status is updated to 'in progress'. After completion, they verify functionality (e.g., ping, traceroute, service checks) and update the status to 'implemented'.
Post-Implementation Review
After a set period (e.g., 2 weeks), the change manager conducts a PIR. They review whether the change achieved its objectives, any incidents caused, and lessons learned. If the change was successful, the RFC is closed. If issues occurred, a problem record may be created. The PIR may recommend improvements to future changes. For emergency changes, the PIR is mandatory to ensure the emergency justification was valid and to prevent recurrence.
Close and Document Change
The RFC is officially closed. All documentation is archived, including the RFC, CAB meeting minutes, implementation logs, and PIR results. The change is recorded in the CMDB, updating the affected CIs' change history. This documentation is critical for audits (e.g., SOX, PCI-DSS). The change manager ensures that any unresolved issues are transferred to problem management. The closed RFC serves as a record of what changed, when, and why.
Enterprise Scenario 1: Core Router IOS Upgrade
A multinational corporation needs to upgrade the IOS on its core routers to patch a critical security vulnerability (CVE-2023-XXXX). The network team submits an RFC with high urgency (1) and high impact (2), resulting in priority 2. The CAB meets within 24 hours (ECAB) because the vulnerability is actively exploited. The ECAB includes the network director, security lead, and change manager. They approve with conditions: the upgrade must be tested on a non-production router first, and a detailed rollback plan must include console access. The upgrade is scheduled for Saturday 2 AM. The engineer executes the upgrade via TFTP, reloads the router, and verifies BGP neighbors are established. The change is successful. The PIR confirms no incidents. This scenario highlights how ECAB enables rapid response while maintaining oversight.
Enterprise Scenario 2: Data Center Switch Replacement
A hospital is replacing an aging access switch in its data center. The RFC is submitted as normal change (low urgency, high impact). The CAB meets weekly and reviews the change. They note that the switch supports patient monitoring systems, so they require the change to occur during a scheduled maintenance window (Sunday 4-6 AM) and that the clinical engineering team is notified. The implementer pre-configures the new switch and uses a cutover plan: disable old switch ports, connect new switch, verify VLANs and STP. The rollback plan involves reconnecting the old switch. The change is implemented successfully. The PIR shows no downtime. This shows how CAB coordinates with business units to minimize patient care impact.
Common Pitfalls in Production
Inadequate rollback plan: A team attempted a firmware upgrade but didn't have a backup of the old firmware. The upgrade failed, and the device was bricked. Now, all RFCs must include a verified rollback plan.
Scheduling conflicts: Two teams scheduled changes on the same core switch without CAB coordination, causing an outage when both tried to modify config simultaneously. The CAB now requires a change freeze during critical periods (e.g., month-end closing).
CAB becoming a rubber stamp: When CAB meetings are too frequent or members don't review RFCs in advance, approvals become automatic. This led to an unauthorized config change that opened a security hole. The organization now requires pre-reading of RFCs and random audits.
What N10-009 Tests on CAB Process
The exam (Objective 3.2) expects you to understand the CAB's role in change management, especially in scenario-based questions. You must know:
The difference between standard, normal, and emergency changes.
When a CAB is required (normal and emergency changes) and when it is not (standard changes).
The purpose of a rollback plan.
The role of the change manager vs. the CAB.
The importance of post-implementation review.
Top Wrong Answers Candidates Choose
'Standard changes require CAB approval.' This is false. Standard changes are pre-approved and do not need CAB. Candidates confuse 'standard' with 'normal.'
'The CAB implements changes.' The CAB does not implement; it only reviews and approves. Implementation is done by the appropriate technical team.
'Emergency changes bypass all approval.' Emergency changes still require approval, but by a smaller ECAB. They are not unauthorized.
'The change manager is a member of the CAB.' The change manager chairs the CAB but is not necessarily a voting member. The exam may test this distinction.
Specific Numbers and Terms That Appear
RFC: Request for Change.
CAB: Change Advisory Board.
ECAB: Emergency Change Advisory Board.
PIR: Post-Implementation Review.
Standard change: Pre-approved, low risk, repeatable.
Normal change: Requires CAB approval.
Emergency change: Fast-tracked, requires ECAB.
Change window: Scheduled time for changes.
Rollback plan: Steps to revert change.
Edge Cases and Exceptions
What if a change is rejected? The RFC is closed with a reason. The requester can resubmit with modifications.
Can a standard change become an emergency? Yes, if the standard change fails and requires immediate remediation, it may be reclassified as emergency.
Who can submit an RFC? Anyone, but the change manager filters incomplete requests.
What if a change affects multiple CIs? The RFC must list all CIs. The CAB uses the CMDB to assess impact.
How to Eliminate Wrong Answers
If the question mentions a change that is low risk and repeatable, it's likely a standard change – no CAB needed.
If the question says 'immediate fix for a security breach', look for 'emergency change' and 'ECAB'.
If the question asks who approves a change, the answer is the CAB (or ECAB for emergency), not an individual manager.
If the question mentions 'post-change review', that's PIR.
CAB = Change Advisory Board; reviews and approves normal and emergency changes.
Standard changes are pre-approved and do not require CAB involvement.
Emergency changes are fast-tracked via ECAB (Emergency CAB).
Every change must have a rollback plan to revert if implementation fails.
The change manager chairs the CAB but does not typically vote.
Post-Implementation Review (PIR) is mandatory for all significant changes.
CAB meetings are documented with minutes for audit purposes.
RFC (Request for Change) is the formal document that initiates the process.
Change windows are predefined periods when changes are allowed to minimize business impact.
The CAB includes stakeholders from IT, security, business, and sometimes vendors.
These come up on the exam all the time. Here's how to tell them apart.
Standard Change
Pre-approved by change manager or predefined policy.
Low risk, repeatable, well-understood (e.g., password reset).
No CAB meeting required.
Implementation is straightforward and often automated.
Documentation is minimal but still logged.
Normal Change
Requires review and approval by the CAB.
Higher risk, unique, or significant impact (e.g., router replacement).
Scheduled for CAB meeting (weekly/bi-weekly).
Requires detailed implementation and rollback plans.
Full documentation including risk assessment and PIR.
Normal Change
Approved in regular CAB meetings.
Planned in advance (days to weeks).
Full risk assessment and rollback plan required.
Standard implementation window.
PIR conducted after 1-2 weeks.
Emergency Change
Approved by ECAB (subset of CAB) within hours.
Unplanned, urgent (e.g., security patch for active threat).
Risk assessment is expedited; rollback plan still required.
Implementation outside normal window if necessary.
PIR conducted immediately after resolution; retrospective documentation.
Mistake
The CAB implements all approved changes.
Correct
The CAB only approves changes; implementation is done by the appropriate technical team (e.g., network engineers). The CAB does not have the technical expertise or resources to implement changes.
Mistake
Standard changes do not require any documentation.
Correct
Standard changes still require a pre-approved RFC template. They are documented and logged, but they do not require CAB review. Documentation is essential for audit trails.
Mistake
Emergency changes can be made without any approval.
Correct
Emergency changes must be approved by the ECAB (Emergency CAB) as soon as possible. They are not unauthorized; they follow a faster, but still controlled, process. Retrospective approval is not acceptable.
Mistake
The change manager is a voting member of the CAB.
Correct
The change manager chairs the CAB and facilitates the meeting but typically does not vote. They ensure the process is followed. Voting members are stakeholders from technical and business areas.
Mistake
A post-implementation review is optional for successful changes.
Correct
PIR is mandatory for all significant changes, including successful ones. It captures lessons learned and ensures the change met its objectives. Skipping PIR can lead to repeated mistakes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CAB (Change Advisory Board) reviews normal changes during scheduled meetings (weekly). ECAB (Emergency CAB) is a smaller group that meets as needed to approve emergency changes within hours. ECAB typically includes the change manager, security lead, and relevant technical experts. The key difference is speed and scope: CAB handles planned changes; ECAB handles urgent, unplanned changes.
Anyone in the organization can submit an RFC, including network engineers, system administrators, developers, and even business users. However, the change manager reviews all RFCs for completeness and may reject incomplete ones. The submitter must provide sufficient detail, including justification, risk assessment, and rollback plan.
The implementer executes the rollback plan immediately to restore the previous state. The change status is set to 'failed' or 'rolled back'. The incident is logged, and the CAB is notified. A post-implementation review (PIR) will analyze the failure to prevent recurrence. The RFC may be resubmitted after issues are resolved.
No. Standard changes (low risk, pre-approved) do not require CAB approval. Normal changes require CAB approval. Emergency changes require ECAB approval. The change manager determines the change type based on risk and urgency. The goal is to balance control with agility.
The change manager is responsible for the overall change management process. They log RFCs, categorize changes, schedule CAB meetings, chair the meetings, ensure decisions are documented, and oversee implementation. They do not typically vote but facilitate the process. They also ensure compliance with policies and audit requirements.
CAB meetings are typically held weekly, but the frequency depends on the organization's change volume and risk tolerance. High-change environments may meet twice a week or daily. Emergency changes are handled by ECAB as needed, often within hours.
An RFC must include: description of the change, justification, affected configuration items (CIs), risk assessment (probability × impact), implementation plan, rollback plan, schedule, and contact information for the implementer. For emergency changes, the same information is required but may be provided retrospectively.
You've just covered Change Advisory Board (CAB) Process — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?