This chapter covers the change management process, a critical operational procedure on the CompTIA A+ 220-1102 exam. Change management ensures that modifications to IT infrastructure are controlled, documented, and implemented with minimal risk. Expect approximately 5-8% of exam questions to touch on change management, often in scenario-based questions asking you to identify the correct steps or documents. Mastering this topic is essential for the Operational Procedures domain (Objective 4.2) and for real-world IT roles.
Jump to a section
Think of change management like obtaining a building permit for a major renovation. You don't just start demolishing walls because you have a good idea; you submit detailed plans (Request for Change), get approval from the building inspector (Change Advisory Board), schedule the work during off-hours to minimize disruption (maintenance window), and have a rollback plan if things go wrong (backout plan). The inspector may require a structural engineer's sign-off (technical review) before granting the permit. Once approved, you execute the work step-by-step, and after completion, you schedule a final inspection (post-implementation review) to ensure everything is safe and meets code. If you skip the permit and just start hammering, you risk fines, structural damage, or even having to undo everything (failed change). This mirrors IT change management: a formal process prevents unauthorized changes that can lead to outages, security breaches, or data loss. The process ensures that every change is reviewed, tested, scheduled, and documented, reducing risk and providing a clear audit trail.
What is Change Management?
Change management is a formal process used to ensure that changes to IT systems are introduced in a controlled and coordinated manner. Its primary goals are to minimize the risk of service disruption, ensure compliance with policies and regulations, and maintain the integrity of the production environment. The process applies to hardware changes (e.g., replacing a server), software changes (e.g., patching an OS), configuration changes (e.g., modifying firewall rules), and even documentation updates.
Why Change Management Exists
Without a structured process, IT teams risk implementing changes that:
Go undocumented, leading to configuration drift.
Are not tested, causing unexpected outages.
Conflict with other changes, creating cascading failures.
Bypass security controls, introducing vulnerabilities.
Are performed without rollback plans, making recovery difficult.
Change management addresses these risks by introducing review, approval, scheduling, testing, and documentation requirements.
Key Components of the Change Management Process
The change management process typically includes the following elements:
- Request for Change (RFC): A formal proposal detailing the change, its rationale, scope, impact, risks, and implementation plan. - Change Advisory Board (CAB): A group of stakeholders (IT managers, security officers, business representatives) that reviews and approves RFCs. - Emergency Change Advisory Board (ECAB): A subset of the CAB that handles urgent changes requiring rapid approval (e.g., security patches for active exploits). - Change Types: - Standard Change: Pre-authorized, low-risk changes (e.g., password reset, adding a user to a group). - Normal Change: Requires CAB approval, follows the full process. - Emergency Change: Requires ECAB approval, often expedited. - Scheduled Maintenance Window: A predefined time period when changes are implemented, typically during low-usage hours to minimize impact. - Backout Plan: A documented procedure to revert the change if it fails or causes issues. - Post-Implementation Review (PIR): A review after the change to assess its success, identify lessons learned, and update documentation.
Step-by-Step Change Management Process
The CompTIA A+ 220-1102 exam expects you to know the sequence of steps in change management. The standard ITIL-based process is:
Identify the need for a change: Recognize a problem, security vulnerability, or business requirement that necessitates a change.
Create the RFC: Document the change details, including justification, scope, impact analysis, risk assessment, and proposed implementation and backout plans.
Submit the RFC for review: Send the RFC to the CAB (or ECAB for emergencies) for evaluation.
Review and approve/reject: The CAB assesses the change based on risk, impact, resources, and business alignment. They may request modifications or reject the RFC.
Plan the change: Develop a detailed implementation schedule, assign resources, and communicate the plan to stakeholders.
Test the change (if applicable): In non-production environments, validate that the change works as expected and does not cause unintended side effects.
Implement the change: Execute the change during the scheduled maintenance window, following the implementation plan and using the backout plan if needed.
Verify the change: Confirm that the change achieved its intended outcome and that systems are operating normally.
Close the change: Update the change record with results, lessons learned, and updated documentation. Conduct a PIR if required.
Change Management Documentation
Proper documentation is a key aspect of change management. The following documents are commonly used:
Change Request Form: Captures all details of the proposed change.
Change Schedule: A calendar of approved changes and their implementation windows.
Change Log: A historical record of all changes, including approvals, implementation dates, and outcomes.
Configuration Management Database (CMDB): A repository that tracks the relationships between IT components and their configurations. Changes should update the CMDB to maintain accurate records.
Roles and Responsibilities
Change Manager: Oversees the change management process, ensures compliance, and chairs the CAB.
Change Initiator: The person who identifies the need for a change and creates the RFC.
Change Implementer: The technician or team that performs the change (e.g., a system administrator).
Change Approver: Members of the CAB who review and authorize changes.
Change Reviewer: Participants in the PIR who evaluate the change's success.
Change Management vs. Configuration Management
While related, change management and configuration management are distinct: - Change Management: Focuses on the process of introducing changes safely. - Configuration Management: Focuses on maintaining accurate information about the IT environment (e.g., hardware, software, network configurations).
A change may result in updates to the CMDB, but configuration management is an ongoing discipline, not a one-time process.
Common Pitfalls and Best Practices
Pitfall: Bypassing the process for small changes. Even minor changes can cause major issues if not documented. Use standard changes for low-risk, frequent tasks.
Pitfall: Inadequate testing. Always test changes in a staging environment before production, unless it's an emergency.
Pitfall: Poor communication. Notify all affected stakeholders (e.g., help desk, end users) before and after the change.
Best Practice: Use a change freeze during peak periods. Many organizations prohibit changes during critical business cycles (e.g., end-of-quarter) to reduce risk.
Best Practice: Automate change management. Tools like ServiceNow, Jira Service Management, or Remedy can enforce workflows and approval chains.
Change Management in the Real World
In enterprise environments, change management is often integrated with ITIL (Information Technology Infrastructure Library) or COBIT frameworks. For the A+ exam, focus on the practical steps and documentation. You may encounter scenario questions where you must identify the missing step (e.g., "A technician is about to install a new server. What should they do first?" – Answer: Submit an RFC).
Interaction with Other Operational Procedures
Change management interacts with: - Incident Management: A failed change may trigger an incident. Conversely, incident resolutions often require changes. - Problem Management: Root cause analysis may identify changes needed to prevent recurrence. - Release Management: Changes are often bundled into releases for deployment. - Asset Management: Changes affect asset records and CMDB entries.
Exam Tips
Know the order of steps: RFC → CAB review → Approval → Planning → Testing → Implementation → Verification → Closure.
Understand the difference between standard, normal, and emergency changes.
Remember that the CAB does NOT implement changes; they approve them.
A backout plan is required for every change, not just complex ones.
Post-implementation review is not always required; it's typically for major or failed changes.
The change initiator and implementer may be the same person, but the approver must be independent.
Sample RFC Content
An RFC should include:
Change ID and title
Description and justification
Scope and impact
Risk assessment (high/medium/low)
Implementation plan with timeline
Backout plan
Testing results
Required resources
CAB approval status
Change Management and Security
Change management is a security control. It prevents unauthorized changes that could introduce vulnerabilities. For example, a firewall rule change should be approved by security personnel. The process also ensures that changes comply with regulatory requirements (e.g., PCI-DSS, HIPAA).
Common Exam Scenarios
A technician wants to apply a critical security patch. What type of change is this? → Emergency change.
A user requests a new software installation. What should the technician do first? → Submit an RFC.
A change caused an outage. What document should the technician follow to revert? → Backout plan.
Who approves normal changes? → CAB.
What is the purpose of a maintenance window? → To schedule changes during low-impact periods.
Review
Change management is a structured process that ensures changes are controlled, tested, and documented. It reduces risk, improves communication, and maintains service stability. For the 220-1102 exam, focus on the process steps, documentation, and roles. Practice scenario-based questions to reinforce your understanding.
Identify and Document Change Need
The process begins when someone recognizes a requirement for a change—whether it's a bug fix, hardware upgrade, or new feature. The initiator documents the need in a Request for Change (RFC). The RFC includes a description, justification, scope, risk assessment, and preliminary implementation and backout plans. The initiator must also identify stakeholders and potential impact. At this stage, no action is taken on the system; it's purely a proposal.
Submit RFC for CAB Review
The RFC is submitted to the Change Advisory Board (CAB) for review. The CAB consists of representatives from IT, security, operations, and business units. They evaluate the change based on risk, resource availability, business impact, and alignment with policies. For emergency changes, the Emergency CAB (ECAB) may meet urgently. The CAB can approve, reject, or request modifications. A rejected RFC may be resubmitted with revisions.
Plan and Schedule the Change
Once approved, the change is planned in detail. The implementer creates a step-by-step implementation plan, assigns resources, and identifies a maintenance window (e.g., Sunday 2-4 AM). The backout plan is finalized. Communication is sent to all affected parties (help desk, end users, management). The change is added to the change schedule to avoid conflicts with other planned changes.
Test and Implement the Change
If possible, the change is tested in a non-production environment. After successful testing, the change is implemented during the scheduled maintenance window. The implementer follows the plan exactly, logging actions. If something goes wrong, the backout plan is executed immediately. After implementation, the system is verified to be working correctly (e.g., ping test, service check).
Close and Review the Change
After implementation and verification, the change record is updated with results, any deviations from the plan, and lessons learned. A post-implementation review (PIR) may be conducted for major or failed changes. The CMDB is updated to reflect new configurations. Finally, the change is formally closed, and all documentation is archived for audit purposes.
In a large enterprise, change management is often enforced through a ticketing system like ServiceNow. For example, a network team needs to update firewall rules to allow a new vendor application. They submit an RFC detailing the rule changes, risk (medium), and a backout plan to revert the rules. The CAB, which includes a security officer, reviews and approves the change after confirming the vendor's IP addresses are whitelisted. The change is scheduled for Saturday night to minimize business impact. The network engineer implements the change, verifies connectivity, and updates the CMDB. Without this process, the firewall change could accidentally block critical traffic, causing an outage.
Another scenario: A help desk technician receives multiple reports of a Windows update causing blue screens. They identify the need for a rollback (an emergency change). They submit an RFC with high priority, and the ECAB approves it within 30 minutes. The technician executes the rollback during a brief maintenance window, and the issue is resolved. The post-implementation review notes that the update should be tested on non-production systems first.
A common misconfiguration is skipping the backout plan. For instance, a server upgrade fails because the technician didn't document how to revert to the old OS. The server remains down for hours while the team scrambles to restore from backup. This highlights why the backout plan is mandatory. Another issue is change collisions—two teams scheduling changes that conflict (e.g., both rebooting the same server). A centralized change schedule prevents this.
Performance considerations: In large organizations, the CAB may meet weekly, so changes can be delayed. Emergency changes bypass this but may cause fatigue if overused. Automation tools can enforce approvals and scheduling, reducing manual overhead. The key is balancing risk and agility.
The 220-1102 exam tests change management under Objective 4.2 (Operational Procedures). Expect scenario-based questions where you must identify the correct next step or document. The most common wrong answers are:
"Implement the change immediately" – Candidates forget that approval is required first. The correct answer is to submit an RFC or obtain CAB approval.
"Skip testing for low-risk changes" – The exam emphasizes that all changes should be tested if possible, even standard changes.
"The change implementer is also the approver" – This violates segregation of duties. The approver must be independent.
"Post-implementation review is always required" – PIR is typically for major or failed changes, not all changes.
Specific numbers and terms: The exam may ask about the composition of the CAB (e.g., includes security officer, IT manager, business rep). Know that standard changes are pre-approved, normal changes require CAB, and emergency changes require ECAB. The backout plan is a required component of every RFC. Maintenance windows are scheduled during low-usage periods.
Edge cases: The exam might present a scenario where a change is needed to fix a critical security vulnerability. The correct answer is to treat it as an emergency change, not skip the process entirely. Another edge: if a change fails, the technician should follow the backout plan, not try to fix it on the fly.
How to eliminate wrong answers: If an option says "implement without approval," it's wrong. If it says "document after implementation," that's wrong—documentation should be done before. Look for answers that include "submit RFC," "CAB approval," "backout plan," or "maintenance window." The process is always: plan, approve, implement, verify, document.
Change management is a formal process to control and document changes, reducing risk and ensuring stability.
The process sequence: RFC → CAB review → Approval → Planning → Testing → Implementation → Verification → Closure.
Standard changes are pre-approved; normal changes require CAB; emergency changes require ECAB.
A backout plan is mandatory for every change.
The CAB approves changes but does not implement them.
Post-implementation review is not required for all changes.
Documentation (RFC, change log, CMDB updates) is critical for audit and compliance.
These come up on the exam all the time. Here's how to tell them apart.
Normal Change
Requires full CAB approval.
Scheduled during standard maintenance windows.
Follows the complete change management process.
Typically planned days or weeks in advance.
Low to medium urgency.
Emergency Change
Requires ECAB approval (expedited).
Implemented as soon as possible, often outside maintenance windows.
Follows a streamlined process with less documentation.
Response time is minutes to hours.
High urgency (e.g., security breach, critical outage).
Mistake
Change management is only for large infrastructure changes.
Correct
Change management applies to any modification that could affect service stability, including configuration changes, software patches, and hardware replacements. Standard changes cover low-risk tasks, but they are still documented and tracked.
Mistake
The CAB is responsible for implementing changes.
Correct
The CAB only reviews and approves changes. Implementation is performed by the designated implementer (e.g., system administrator, network engineer). The CAB does not have hands-on access to production systems.
Mistake
Emergency changes bypass all approval.
Correct
Emergency changes still require approval, but from the Emergency CAB (ECAB) instead of the full CAB. The process is expedited, but not eliminated.
Mistake
A backout plan is optional for simple changes.
Correct
A backout plan is mandatory for every change, regardless of complexity. It ensures that the change can be reverted safely if issues arise.
Mistake
Post-implementation review is required for all changes.
Correct
PIR is typically conducted for major changes, failed changes, or changes with significant impact. Standard or minor changes may only require a note in the change record.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The first step is identifying the need for a change and documenting it in a Request for Change (RFC). This includes describing the change, its justification, scope, and potential risks. Without an RFC, the change cannot be reviewed or approved.
Normal changes are approved by the Change Advisory Board (CAB), which includes representatives from IT, security, operations, and business units. The CAB reviews the RFC and either approves, rejects, or requests modifications.
A backout plan is a documented procedure to revert a change to its previous state if the change fails or causes issues. It is important because it minimizes downtime and ensures a safety net. Without it, recovery can be chaotic and prolonged.
A standard change is pre-approved and low-risk, such as password resets or adding users. It follows a predefined procedure without needing CAB approval. A normal change is higher risk and requires full CAB review and approval.
A PIR is typically required for major changes, failed changes, or changes that had significant impact. It assesses whether the change achieved its objectives and identifies lessons learned. Minor successful changes may not need a formal PIR.
No, implementing a change without proper approval violates change management policy and can lead to disciplinary action. Even emergency changes require ECAB approval. Unauthorized changes increase risk of outages and security incidents.
If a change fails, the implementer should immediately follow the backout plan to revert the system to its previous state. Afterward, the incident should be documented, and the change should be marked as failed in the change log. A post-implementation review may be conducted to determine root cause.
You've just covered Change Management Process — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?