This chapter covers change management procedures, a core part of the CompTIA A+ 220-1102 Operational Procedures domain (Objective 4.2). Change management is a formal process for controlling modifications to IT systems, ensuring changes are planned, tested, approved, and documented. Expect approximately 5-10% of your exam questions to touch on change management, either directly or in scenario-based questions about troubleshooting, security, or operational procedures.
Jump to a section
Change management is like a hospital's surgical checklist. Before a surgeon makes an incision, the entire team pauses to verify the patient's identity, the correct surgical site, and that all necessary equipment is sterile and available. This checklist is not optional—it is a formal, documented process that ensures every step is followed, risks are assessed, and communication is clear. Similarly, in IT, change management is a formal process for making modifications to IT infrastructure. Just as a checklist prevents wrong-site surgery, change management prevents unauthorized or risky changes that could cause outages or security breaches. The process includes planning, approval, testing, and rollback procedures, mirroring the surgical team's verification, consent, and contingency planning. Without it, changes are made haphazardly, leading to 'complications' like system downtime or data loss. The checklist forces discipline, ensures accountability, and provides a record of what was done—just as change management documentation creates an audit trail. In both cases, the goal is to minimize risk and ensure that when something goes wrong, the team knows exactly how to revert to a safe state.
What is Change Management and Why Does It Exist?
Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. In IT, it specifically refers to the process of managing changes to computer systems, networks, software, and configurations in a controlled and systematic way. The primary goal is to minimize the risk of disruption to services while maximizing the benefits of making changes.
Without change management, IT environments become chaotic. Unauthorized changes—often called 'rogue changes'—can lead to configuration drift, security vulnerabilities, and unexpected outages. For example, an administrator might update a firewall rule to fix a temporary issue but forget to revert it, leaving a security hole. Change management prevents this by requiring that all changes go through a defined lifecycle: request, review, approve, implement, and review.
The Change Management Process: Step-by-Step Mechanism
The typical change management process follows a lifecycle that ensures every change is justified, assessed for risk, tested, and documented. The exact steps may vary by organization, but the core stages are:
Request for Change (RFC): A formal request is submitted describing the change, its rationale, and expected outcomes. The RFC includes details like the change category (standard, emergency, normal), priority, and affected systems.
Change Assessment: A change advisory board (CAB) or designated approvers review the RFC. They evaluate the risk, impact, resource requirements, and potential conflicts with other changes. A risk assessment is performed to determine the likelihood and severity of adverse effects.
Change Approval: Based on the assessment, the change is approved, rejected, or returned for modification. Approval levels depend on risk: low-risk changes may be pre-approved (standard changes), while high-risk changes require CAB approval.
Change Implementation: Once approved, the change is scheduled and implemented according to the plan. Implementation often includes a rollback plan—a set of steps to revert the change if something goes wrong.
Post-Implementation Review (PIR): After a defined period (e.g., 24-72 hours), the change is reviewed to confirm it achieved its objectives without adverse effects. Lessons learned are documented.
Key Components and Roles
- Change Advisory Board (CAB): A group of stakeholders (IT managers, security officers, business representatives) that reviews and approves changes. The CAB meets regularly to discuss RFCs. - Emergency Change Advisory Board (ECAB): A subset of the CAB that can approve urgent changes outside of normal meeting times. - Change Manager: The person responsible for overseeing the change management process, ensuring compliance, and maintaining records. - Request for Change (RFC): The formal document that initiates the process. - Change Schedule: A calendar of planned changes to avoid conflicts. - Rollback Plan: A documented procedure to undo a change if it fails or causes issues. - Change Categories: - Standard Change: Low-risk, pre-approved changes (e.g., applying routine patches). - Normal Change: Changes that require assessment and approval. - Emergency Change: Urgent changes needed to fix critical issues (e.g., security patch for an active breach). Emergency changes bypass normal approval but require retrospective documentation.
Configuration and Verification Commands
While change management itself is a process, it often involves tracking configuration changes. On Windows systems, you can use the following commands to verify system state before and after changes:
systeminfo – Displays detailed system configuration.
msinfo32 – Opens System Information GUI.
reg query – Queries registry values.
gpresult /h report.html – Exports Group Policy results.
sfc /scannow – Checks system file integrity.
dism /online /cleanup-image /restorehealth – Repairs system image.
On Linux:
- uname -a – Kernel version.
- lshw – Hardware list.
- dpkg --get-selections – List installed packages.
- systemctl list-units – List services.
- diff – Compare configuration files before and after.
How Change Management Interacts with Related Technologies
Change management integrates with other ITIL processes:
Incident Management: A change may be initiated to resolve an incident. Conversely, a poorly planned change can cause incidents.
Problem Management: Root cause analysis of problems may lead to changes. Problem management provides input to change management.
Configuration Management: The configuration management database (CMDB) stores information about all IT assets and their relationships. Changes update the CMDB.
Release Management: Changes are often bundled into releases. Release management coordinates the rollout of multiple changes.
Security Management: Security changes (e.g., patching vulnerabilities, modifying firewall rules) must follow change management to avoid introducing new risks.
Common Traps and Wrong Answers
Candidates often confuse change management with version control or backup procedures. While version control tracks changes to code, change management governs the process of making changes to live systems. Another trap is assuming all changes require CAB approval—standard changes are pre-approved. Emergency changes do not require prior approval but must be documented after the fact. The exam also tests the distinction between a rollback plan and a backup: a rollback plan is a set of steps to revert a change, while a backup is a copy of data used in disaster recovery.
Exam-Specific Values and Terms
RFC: Request for Change – the formal document.
CAB: Change Advisory Board – approves normal changes.
ECAB: Emergency Change Advisory Board – approves emergency changes.
Standard Change: Pre-approved, low-risk.
Emergency Change: Urgent, bypasses normal approval.
Post-Implementation Review (PIR): Conducted after a change to assess success.
Rollback Plan: Must be included in every RFC.
Change Schedule: Prevents scheduling conflicts.
Change Window: A designated time period when changes can be implemented (e.g., maintenance window).
Step-by-Step Walkthrough of a Change
Let's walk through a typical normal change: upgrading a critical database server.
Step 1: Submit RFC – The database administrator submits an RFC detailing the upgrade, including the new version, expected downtime, and rollback steps.
Step 2: CAB Review – The CAB meets, reviews the RFC, assesses risks (e.g., compatibility issues), and approves the change with conditions (e.g., must be done during maintenance window).
Step 3: Implementation – The administrator performs the upgrade during the approved window, following the implementation plan. A rollback plan is ready in case of failure.
Step 4: Post-Implementation Review – After 24 hours, the administrator confirms the server is stable and performance improved. The PIR is documented.
Real-World Considerations
In large enterprises, change management is often automated through IT service management (ITSM) tools like ServiceNow or Jira Service Management. These tools enforce workflows, send notifications, and maintain audit trails. Common mistakes include:
Skipping the rollback plan – leads to extended downtime if the change fails.
Not assessing dependencies – a change to one system may affect others.
Ignoring change windows – implementing changes during peak hours increases risk.
Failing to update the CMDB – causes inaccurate asset records.
Conclusion
Change management is not just bureaucratic overhead; it is a critical practice that protects the stability and security of IT environments. On the CompTIA A+ 220-1102 exam, you will be expected to understand the purpose of change management, the roles involved, and the steps in the process. You should be able to identify when a change requires CAB approval, what constitutes a standard vs. emergency change, and why rollback plans are essential. Knowing the terminology (RFC, CAB, PIR) and the order of steps will help you answer scenario-based questions correctly.
Request for Change (RFC)
The process begins when someone identifies a need for a change—e.g., a patch, upgrade, or configuration tweak. They fill out an RFC form that describes the change, its reason, expected impact, and a rollback plan. The RFC is submitted to the change manager or directly into the ITSM system. This step ensures that changes are not made arbitrarily; every change has a documented justification. The RFC includes the change category (standard, normal, emergency) and priority (low, medium, high, critical). For example, a low-priority cosmetic change might be deferred, while a critical security patch is expedited.
Change Assessment and Risk Analysis
The change manager or CAB reviews the RFC to assess its risk, impact, and resource requirements. They evaluate the probability of failure and the potential consequences. A risk matrix (e.g., low/medium/high) helps determine the approval path. For instance, a change to a core router might be high-risk, requiring full CAB approval, while a change to a test server might be low-risk. The assessment also checks for conflicts with other scheduled changes. If the change is high-risk, a more detailed implementation plan may be required. The outcome is a recommendation to approve, reject, or modify the RFC.
Change Approval
Based on the risk assessment, the change is approved or rejected. Standard changes are pre-approved by policy. Normal changes require CAB approval, often during a scheduled meeting. Emergency changes may be approved by the ECAB via an expedited process (e.g., phone call or email). Approval includes setting the change window—a specific time when the change will be implemented, often during off-peak hours to minimize business impact. The change manager documents the approval decision and communicates it to the requester. If rejected, the RFC is closed with a reason.
Change Implementation
Once approved, the change is implemented according to the plan. The implementer follows the step-by-step procedure, including any pre-change checks (e.g., backing up configurations, verifying current state). The rollback plan is ready to execute if the change fails or causes unexpected issues. During implementation, the change manager may monitor progress and update the change schedule. After implementation, the system is tested to confirm functionality. If the change fails, the rollback is executed immediately. The status of the change is updated in the ITSM system.
Post-Implementation Review (PIR)
After a defined period (typically 24-72 hours), a post-implementation review is conducted. The change owner evaluates whether the change achieved its objectives, whether any issues occurred, and whether the rollback plan was adequate. Lessons learned are documented to improve future changes. The PIR may also involve verifying that the CMDB is updated with the new configuration. If the change caused an incident, the incident is linked to the change record. The PIR closes the change lifecycle. For emergency changes, the PIR includes a retrospective approval process.
Enterprise Scenario 1: Patching a Critical Vulnerability
A large financial institution discovers a critical vulnerability in its web application firewall (WAF) that could allow remote code execution. The security team submits an emergency change request to apply a vendor patch. The ECAB is notified via an emergency meeting and approves the change within 30 minutes. The change is implemented during a maintenance window at 2 AM to minimize user impact. The rollback plan involves reverting to the previous WAF configuration. After implementation, the team runs vulnerability scans to confirm the patch is effective. A post-implementation review the next day documents the success and updates the CMDB. Without change management, the patch might have been applied without testing, causing compatibility issues that could take down the firewall.
Enterprise Scenario 2: Upgrading a Core Switch
A university IT department plans to upgrade a core switch to support increased bandwidth. This is a normal change with medium risk. The RFC is submitted two weeks in advance, including a detailed implementation plan and rollback steps. The CAB reviews it during a weekly meeting, approves it, and schedules the change for a Saturday morning window. The network team backs up the switch configuration and pre-stages the new OS image. During implementation, they follow the plan: upload the new OS, reboot, and verify connectivity. The rollback plan is to reload the previous OS if the new one fails. After the change, they run connectivity tests and update the CMDB. The PIR confirms the upgrade improved performance and no issues occurred.
Common Misconfigurations and Pitfalls
No rollback plan: Without a rollback plan, a failed change can cause extended downtime. Always include a rollback procedure.
Skipping testing: Implementing a change without testing in a staging environment can lead to unforeseen issues.
Poor communication: Failing to notify stakeholders about planned downtime can cause confusion and complaints.
Inadequate documentation: Without proper records, future troubleshooting becomes difficult.
Scale and Performance Considerations
In large enterprises with thousands of changes per month, automation is key. ITSM tools enforce workflows, send reminders, and maintain audit trails. Change windows are strictly enforced to prevent conflicts. High-risk changes may require multiple approvals and additional testing. The change manager monitors the change schedule to avoid overlapping changes that could cause cascading failures.
What the 220-1102 Exam Tests (Objective 4.2)
The CompTIA A+ 220-1102 exam expects you to understand the purpose and process of change management. Specifically, you need to know:
The basic steps: RFC, assessment, approval, implementation, review.
The roles: change manager, CAB, ECAB, requester.
The types of changes: standard, normal, emergency.
The importance of a rollback plan.
The difference between change management and other processes (e.g., incident management).
Common Wrong Answers and Why Candidates Choose Them
'All changes must be approved by the CAB.' – Incorrect. Standard changes are pre-approved. Emergency changes are approved by the ECAB retrospectively.
'Change management is only for major changes.' – Incorrect. Even small changes should follow the process to prevent configuration drift.
'A backup is sufficient as a rollback plan.' – Incorrect. A rollback plan includes specific steps to revert the change; a backup may be part of it but is not the whole plan.
'Change management is optional.' – Incorrect. It is a best practice and often mandated by compliance standards.
Specific Numbers, Values, and Terms That Appear on the Exam
RFC: Request for Change.
CAB: Change Advisory Board.
ECAB: Emergency Change Advisory Board.
Standard Change: Low-risk, pre-approved.
Emergency Change: High urgency, bypasses normal approval.
Post-Implementation Review (PIR): Conducted after change.
Rollback Plan: Must be included in RFC.
Change Window: Scheduled time for implementation.
Edge Cases and Exceptions
Emergency changes do not require prior approval but must be documented and approved retrospectively.
Standard changes are pre-approved but must still be recorded.
Change rejection can occur if the risk is too high or resources are unavailable.
Change cancellation can happen if the need disappears or the change becomes obsolete.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When you see a scenario question about a change, ask yourself:
Is this a standard, normal, or emergency change? Match the approval process accordingly.
Does the scenario mention a rollback plan? If not, that's a red flag.
Is the change being made without documentation? That violates change management.
By understanding the process flow, you can eliminate answers that suggest skipping steps or bypassing approvals incorrectly.
Change management is a formal process that includes RFC, assessment, approval, implementation, and PIR.
Standard changes are pre-approved; normal changes require CAB approval; emergency changes bypass normal approval but need retrospective ECAB approval.
A rollback plan must be included in every RFC to revert the change if it fails.
The Change Advisory Board (CAB) approves normal changes; the Emergency CAB (ECAB) handles emergency changes.
Post-Implementation Review (PIR) is conducted after a change to evaluate success and document lessons learned.
Change management helps prevent unauthorized changes, reduces downtime, and ensures compliance.
All changes, including standard changes, must be documented in the ITSM system.
Emergency changes are not unapproved; they are approved in an expedited manner.
These come up on the exam all the time. Here's how to tell them apart.
Standard Change
Pre-approved by policy
Low risk, routine (e.g., patch Tuesday updates)
No CAB approval needed
Scheduled in advance
Full documentation required
Emergency Change
Approved retrospectively by ECAB
High urgency, often security-related
Bypasses normal approval process
Implemented immediately or within hours
Documentation completed after implementation
Mistake
Change management is only for large organizations.
Correct
Change management is beneficial for any IT environment, regardless of size. Even small organizations can benefit from documenting changes to avoid configuration drift and reduce downtime. CompTIA A+ expects you to know that change management is a best practice for all IT operations.
Mistake
A backup is the same as a rollback plan.
Correct
A backup is a copy of data that can be restored, while a rollback plan is a set of steps to revert a change to its previous state. A rollback plan may include restoring from backup, but it also includes actions like reconfiguring settings or reloading firmware. The exam tests the distinction: a rollback plan is more comprehensive.
Mistake
Emergency changes do not need any approval.
Correct
Emergency changes bypass the normal approval process but still require retrospective approval from the ECAB. They must be documented and reviewed after implementation. The exam emphasizes that emergency changes are not 'unapproved'—they are approved in an expedited manner.
Mistake
Change management is the same as incident management.
Correct
Incident management deals with restoring service after an outage, while change management proactively controls modifications to prevent incidents. They are related but separate ITIL processes. The exam may test your ability to distinguish between them.
Mistake
Standard changes do not need to be documented.
Correct
Standard changes are pre-approved, but they still require documentation in the ITSM system. This ensures an audit trail and helps with trend analysis. The exam expects you to know that all changes, including standard ones, must be recorded.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The purpose of change management is to ensure that changes to IT infrastructure are made in a controlled, systematic way to minimize risk and disruption. It provides a framework for planning, testing, approving, implementing, and reviewing changes. By following change management, organizations can avoid unauthorized changes, reduce downtime, maintain security, and comply with regulations. On the CompTIA A+ exam, you should understand that change management is a key operational procedure.
A standard change is a low-risk, pre-approved change that can be implemented without CAB approval (e.g., applying routine patches). An emergency change is urgent and required to fix a critical issue (e.g., a security breach). Emergency changes bypass the normal approval process but must be approved retrospectively by the ECAB. Both types require documentation, but emergency changes are documented after implementation. The exam tests your ability to classify changes based on risk and urgency.
Approval depends on the change type. Standard changes are pre-approved by policy. Normal changes require approval from the Change Advisory Board (CAB), which includes stakeholders like IT managers, security officers, and business representatives. Emergency changes are approved by the Emergency Change Advisory Board (ECAB) in an expedited manner. The change manager oversees the process but does not necessarily approve changes. The exam may ask who approves a specific type of change.
A rollback plan is a documented set of steps to revert a change to its previous state if the change fails or causes issues. It is important because it provides a safety net, minimizing downtime and impact. Without a rollback plan, a failed change could lead to extended outages. On the exam, expect questions that emphasize the necessity of including a rollback plan in every RFC.
A Post-Implementation Review (PIR) is conducted after a change has been implemented and a defined period has passed (e.g., 24-72 hours). Its purpose is to evaluate whether the change achieved its objectives, identify any issues, and document lessons learned. The PIR also updates the CMDB and closes the change record. The exam may test your knowledge of when and why a PIR is performed.
Yes, a change can be rejected during the assessment phase if the risk is too high, resources are unavailable, or the change conflicts with other priorities. The RFC is then closed with a reason. The exam may present a scenario where a change is rejected and ask why.
While not legally required, change management is considered a best practice and is often mandated by compliance frameworks like ISO 20000, ITIL, or internal policies. The CompTIA A+ exam treats change management as a standard operational procedure that should be followed to ensure system stability and security.
You've just covered Change Management Procedures — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?