# Change management

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/change-management

## Quick definition

Change management is a formal way to make sure that when you update or modify something in an IT environment, you do it safely and with minimal problems. It involves getting approval, testing the change, and having a backup plan if something goes wrong. This process helps prevent unexpected outages and security issues.

## Simple meaning

Think of change management like renovating a room in your house. You wouldn't just start knocking down walls without a plan. First, you would decide what you want to change, check if it's safe, and maybe get permission from your landlord if you're renting. Then you would gather the right tools and materials, schedule the work so it doesn't disrupt your family's daily life, and have a way to put things back if the renovation goes badly. Change management in IT is exactly the same idea. It is a step-by-step process that organizations follow when they need to make any change to their computer systems, networks, software, or security settings. This could be something as small as updating a password policy or as big as moving an entire database to a new server. The goal is to avoid causing problems for the people who use those systems. For example, if a company wants to update its email software, change management ensures that the update is tested first, that users are warned about possible downtime, and that there is a rollback plan in case the update breaks something. Without change management, a simple update could accidentally delete important files, lock everyone out of their accounts, or create a security hole that hackers could exploit. It is the difference between a smooth, planned update and a chaotic, risky one. Change management also includes documenting every change so that if something goes wrong later, the IT team can figure out what changed and fix it quickly. In short, change management is the safety net that keeps IT environments stable, secure, and reliable while still allowing for necessary improvements.

Another way to understand change management is to compare it to a pilot's pre-flight checklist. Before a plane takes off, the pilot goes through a detailed list of checks to make sure everything is working correctly. This checklist prevents accidents and ensures a safe flight. In IT, change management is that checklist for any modification to the system. It forces the team to think through every possible consequence before they act, reducing the chance of a crash. It also creates a record of all changes, much like a flight log, which helps with troubleshooting and auditing later. Without this checklist, IT teams would be flying blind, hoping that changes work out, but with no guarantee that they will. Change management turns that hope into a reliable, repeatable process that protects the business and its users.

## Technical definition

Change management, in the context of IT service management (ITSM) and IT governance, is a formalized process designed to control the lifecycle of all changes to an IT infrastructure. Its primary objective is to enable beneficial changes to be made with minimal disruption to IT services, while also ensuring that all changes are properly authorized, tested, documented, and reviewable. The process is deeply rooted in frameworks such as ITIL (Information Technology Infrastructure Library) and ISO/IEC 20000, which define specific roles, procedures, and categories for change management.

The change management process typically begins with the creation of a Request for Change (RFC). An RFC is a formal document that describes the proposed change, its rationale, the expected impact, the resources required, and a detailed implementation plan. The RFC also includes a risk assessment, which evaluates the potential negative effects of the change on system availability, security, and performance. Depending on the organization's size and structure, RFCs are submitted through a centralized system, often a service management platform like ServiceNow, Jira Service Management, or BMC Remedy.

Once an RFC is submitted, it goes through a review and authorization process. Changes are typically categorized by their risk level and urgency. Common categories include Standard Changes (pre-approved, low-risk changes like patching a known vulnerability following a defined procedure), Normal Changes (changes that require review by a Change Advisory Board or CAB), and Emergency Changes (high-urgency changes needed to fix a critical outage or security breach, which may be authorized by a smaller emergency committee and post-hoc reviewed). The CAB is a group of stakeholders, including IT managers, security officers, and business representatives, who assess the RFC against operational and security criteria. They may approve, reject, or require modifications to the change plan.

After approval, the change is implemented according to the plan. This phase includes building, testing, and deploying the change in a controlled manner. Testing is critical and often occurs in a staging environment that mirrors production, to verify that the change works as intended and does not introduce conflicts. A rollback plan is a mandatory component of every significant change, it details exactly how to revert the system to its pre-change state if the change fails or causes unexpected issues. Implementation may follow a change window, a pre-agreed period of low activity (such as late night or weekend) to minimize business impact.

Following implementation, the change enters the Post-Implementation Review (PIR) phase. The PIR evaluates whether the change achieved its objectives, whether any incidents occurred, and what lessons can be learned for future changes. All documentation, including the RFC, approvals, test results, and incident reports, are archived for auditing and compliance purposes. This documentation trail is essential for frameworks like ITIL, and for regulatory standards such as SOX (Sarbanes-Oxley), HIPAA, PCI DSS, and GDPR, which may require proof that system changes were controlled and auditable. In security-focused certifications like CISSP and Security+, change management is closely tied to the concept of configuration management and change control, which are part of the broader security governance and risk management domains.

From a technical implementation perspective, change management often integrates with version control systems (e.g., Git) for software changes, automation tools (e.g., Ansible, Puppet, Chef) for infrastructure changes, and CI/CD pipelines (e.g., Jenkins, GitLab CI) for continuous deployment. These tools help enforce the change management process by requiring approvals, running automated tests, and creating immutable audit logs. In network environments, change management governs router and firewall configuration changes to prevent outages or security gaps. In cloud environments (AWS, Azure, GCP), change management applies to changes in IAM policies, resource configurations, and network security groups.

change management is not a single step but a comprehensive lifecycle that balances the need for innovation and agility with the imperatives of stability, security, and compliance. It is a cornerstone of mature IT operations and a key topic across major IT certification exams.

## Real-life example

Imagine you are the manager of a busy restaurant. The restaurant has a set menu that customers love, and your kitchen staff know exactly how to prepare each dish. One day, the head chef decides to change the recipe for the most popular pasta dish, replacing a traditional tomato sauce with a new spicy cream sauce. Instead of just announcing the change during the dinner rush, the chef first discusses the idea with you. Together, you decide to test the new sauce during a slow Monday lunch shift, when there are fewer customers. You also make sure that extra ingredients for the old sauce are still available, just in case the new one is not well received. You inform the waitstaff so they can explain the change to customers and note their feedback. After the trial, you review customer comments and sales data. Customers like the new sauce, so you decide to adopt it permanently. You train the kitchen staff, update the menu, and store the old recipe in a file for future reference. This whole process, testing, evaluating, training, and documenting, is change management in action.

Now, map this back to IT. The restaurant is the company, the menu is the software or system, the head chef is the IT administrator proposing a change, you as the manager are the Change Advisory Board, the waitstaff are the help desk who communicate with users, the trial lunch shift is the staging environment test, and the saved old recipe is the rollback plan. Without this careful process, the chef could change the sauce during a Saturday night rush, upsetting customers who loved the old recipe, causing chaos in the kitchen, and hurting the restaurant's reputation. In IT terms, without change management, an admin could push a software update that breaks a critical business application, causing hours of downtime and lost revenue. The restaurant analogy makes it clear that change management is simply a way to handle necessary changes without causing unnecessary problems. It is about communication, preparation, testing, and having a safety net.

## Why it matters

Change management matters because IT environments are complex and interconnected. A seemingly minor change in one component can have cascading effects on other systems, users, or security controls. For example, changing a firewall rule to allow a new application could inadvertently expose an internal database to the internet, creating a data breach. Without change management, there is no formal mechanism to catch such risks before they become incidents.

In practical IT operations, change management directly reduces the frequency and severity of service outages. According to industry studies, a high percentage of IT incidents are caused by poorly planned or unauthorized changes. By enforcing a structured process, organizations can catch errors in the planning stage, ensure that sufficient testing is done, and maintain a clear record of what changed and when. This documentation is invaluable when troubleshooting post-change issues, as it allows engineers to quickly identify the root cause and either roll back the change or apply a fix.

Change management also supports compliance with legal and regulatory requirements. Regulations like HIPAA, PCI DSS, and SOX require organizations to demonstrate that they have controls in place to manage changes to systems that handle sensitive data. Auditors will ask to see change tickets, approval records, and test results. Without a formal change management process, an organization cannot prove that changes were reviewed and safe, which can lead to fines or loss of certification. Similarly, frameworks like ISO 27001 and NIST CSF include change control as a key security control.

From a career perspective, understanding change management is essential for IT professionals, especially those seeking roles in IT management, cybersecurity, or system administration. It is a core concept in the ITIL framework, which is widely used in enterprise IT. It is also a major domain in the CISSP exam under the Security and Risk Management and Asset Security domains. Security+ and A+ also cover change management, emphasizing its role in maintaining operational security and reliability. For learners, mastering change management demonstrates that you think beyond technical execution and consider the broader operational and governance context of IT work. It shows that you care about stability, security, and the business impact of your actions.

Finally, change management fosters a culture of accountability and continuous improvement. When every change is reviewed and documented, team members learn from past successes and failures. The post-implementation review process highlights what went well and what could be improved, leading to better processes over time. This creates a mature IT organization that can innovate quickly and safely, which is a competitive advantage in any industry.

## Why it matters in exams

Change management appears prominently across several major IT certification exams, each approaching it from a slightly different angle. For the CompTIA Security+ exam (SY0-601), change management is covered primarily in Domain 5: Security Operations and Monitoring. The exam expects you to understand the change management process steps (request, approval, testing, implementation, documentation) and how they relate to security controls. You may see questions about who should approve a change, what elements are required in an RFC, or the importance of a rollback plan. Another common area is change management as part of configuration management and patching. You might be asked to identify the correct sequence of steps or to recognize scenarios where a change was made without following the process, and the security implications of that.

The CompTIA A+ exam (220-1102) covers change management in Domain 3: Operational Procedures. While A+ is more focused on desktop support, the exam includes change management concepts as they apply to updating drivers, operating systems, and hardware in a corporate environment. Questions may test your knowledge of documenting changes, notifying users, and backing up data before making modifications. A+ also touches on change management in the context of life-cycle management for devices, such as replacing a laptop or upgrading RAM in a workstation. The emphasis is on the practical, procedural side of change management rather than high-level governance.

The ISC2 CISSP exam covers change management across several domains, most notably Domain 1: Security and Risk Management and Domain 3: Security Architecture and Engineering. In CISSP, change management is treated as a fundamental governance mechanism that supports risk management. You are expected to understand change management as a formal control used to ensure that changes do not weaken security controls or introduce vulnerabilities. The exam may tie change management to the concept of separation of duties, where the person who requests a change should not be the same person who approves or implements it. You may also see questions about change management in the context of software development, such as how it integrates with the Software Development Life Cycle (SDLC) and version control. CISSP often presents change management in scenario-based questions where you must choose the best policy or procedure to prevent a security incident.

Beyond these specific exams, change management is also a key topic in ITIL Foundation (though not listed as a related exam, it is implied for many learners). For the exams listed, the depth of knowledge required varies. Security+ and A+ are at the awareness/application level, while CISSP requires a deeper, analytical understanding of change management as part of an overall security governance program. In all cases, the exam approach is practical: you need to know not just the definition but how to apply the process in a given situation. Common exam traps include confusing change management with configuration management (which focuses on baselines and asset states) or with patch management (a specific type of change). Understanding these distinctions is critical to scoring well.

To prepare for change management questions, learners should memorize the standard steps: request, review, approve, test, implement, document, and review. Understand the roles involved (requester, change manager, CAB, implementer). Know the difference between standard, normal, and emergency changes. Be able to identify the most important element of a change plan (the rollback plan). Practice scenario-based questions where you must decide whether a change was handled correctly. With this foundation, you will be well-prepared for change management questions on any of the related exams.

## How it appears in exam questions

Change management questions in certification exams typically fall into three categories: scenario-based, definition-based, and process-order questions. Scenario-based questions present a situation where an IT professional makes a change that disrupts services or introduces a security issue. The question then asks you to identify what went wrong, what should have been done, or what the next step should be. For example, a question might describe a system administrator who updates a critical server without notifying the team, and the update causes the server to crash. The correct answer would point out the lack of change management process, such as failing to get approval or not having a rollback plan. These questions test your ability to recognize the absence or failure of change management controls.

Definition-based questions are straightforward: they ask you to define change management, list its steps, or identify its purpose. These are common in A+ and Security+ exams, where you might be asked, What is the primary purpose of change management? or Which document describes a proposed change in detail? The correct answer would be event management (no), incident management (no), change management (yes) or Request for Change (RFC). These questions test your recall of terminology and core concepts.

Process-order questions ask you to arrange the steps of change management in the correct sequence. For instance, a question might present five steps (test the change, get approval, implement, create an RFC, perform a post-implementation review) and ask for the correct order. These questions are common in ITIL-related content but also appear in Security+ and A+ where process flow is emphasized. Learners must remember that the RFC comes first, then review and approval, then testing, then implementation, and finally review.

Troubleshooting-oriented questions in A+ may present a scenario where a user's application stops working after a system update. The question might ask what the technician should check first. The correct answer would be to review recent changes to the system, which ties back to the change management log. This highlights the importance of documentation in the change management process. In more advanced questions (CISSP), you might be asked to evaluate the risk of a proposed change based on its impact and urgency. The question may present two potential changes and ask which should be approved first, testing your ability to prioritize risk.

Another common pattern is the best practice question. For example, What is the most important component of a change plan? The exam expects the rollback plan because without it, a failed change cannot be undone quickly, leading to extended downtime. Or, Who should approve a change that affects multiple departments? The correct answer is the Change Advisory Board (CAB), not the individual department head. These questions test your understanding of roles and responsibilities.

Finally, some questions specifically target the difference between standard, normal, and emergency changes. You might be given a description of a change (e.g., applying a critical security patch to a firewall that is under active attack) and asked which category it falls into. The correct answer would be emergency change, because of the urgency and potential impact. Understanding the category is important because it determines the approval process. For learners, the key is to practice with sample questions from each exam to get comfortable with the phrasing and logic of change management questions. Use official exam objectives and practice tests to identify common question types.

change management questions test your ability to apply the process to realistic IT situations. They require you to know the steps, the terminology, the roles, and the rationale behind each part of the process. Memorizing the framework and practicing scenario analysis will give you a strong advantage.

## Example scenario

You are a junior system administrator at a mid-sized company that manufactures sporting goods. The company uses a custom inventory management application that runs on a Windows Server. The application has a known bug: when certain product codes are entered, the application crashes and must be restarted, causing a few minutes of downtime each time. Your senior colleague, Maria, has received a patch from the software vendor that supposedly fixes this bug. Maria wants to apply the patch immediately because she is tired of dealing with the crashes. However, the company has a change management policy that requires all changes to server software to go through a formal process.

Maria creates a Request for Change (RFC) in the company's service management system. She describes the change: apply the vendor patch to the inventory server. She notes the risk level as medium because the patch directly modifies core application files. The expected benefit is that the bug will be fixed, reducing downtime. The rollout plan includes downloading the patch, running a backup of the current server state, applying the patch during the scheduled maintenance window (Sunday 2 AM), and then testing the application by entering the buggy product codes. The rollback plan is to restore from the backup if the patch fails.

The RFC goes to the Change Advisory Board, which meets every Thursday. The board approves the change, noting that the patch should be tested in the staging environment first, even though the policy technically allows skipping that step for vendor-supplied patches. Maria tests the patch on a non-production server that mirrors the live environment. The test is successful; the bug is fixed and no new issues appear. On Sunday at 2 AM, Maria implements the patch on the production server. She runs the test again, and it works perfectly. She documents the change in the system, noting the date, the patch version, and the successful test results.

After the change, there are no further crashes. The help desk receives no complaints. One week later, Maria participates in the Post-Implementation Review meeting and reports that the change was successful and had no negative impact. The board closes the RFC. The entire process ran smoothly, and the company benefits from a more stable inventory system. This scenario shows each step of change management in action: RFC creation, risk assessment, testing, approval, scheduled implementation, rollback availability, documentation, and post-review. It also highlights that even a simple patch benefits from the structure of change management, preventing rushed decisions and ensuring that the change is safe and effective.

## Common mistakes

- **Mistake:** Skipping the testing phase for minor changes, assuming they are too small to cause problems.
  - Why it is wrong: Even a small change, like updating a single configuration file or installing a minor patch, can have unforeseen effects. A seemingly innocuous change might conflict with another setting or cause a cascading failure. Skipping testing removes the safety net and can lead to downtime or security vulnerabilities.
  - Fix: Always test any change in a non-production environment that mirrors production as closely as possible. If a staging environment is not available, at minimum verify the change manually on a test machine before applying it to production.
- **Mistake:** Confusing change management with incident management and assuming they serve the same purpose.
  - Why it is wrong: Change management is a proactive process to plan and control changes before they are implemented to prevent incidents. Incident management is a reactive process to restore normal service after an incident has already occurred. They are related but distinct functions. Using incident management to handle changes bypasses the planning and approval steps needed to prevent the incident in the first place.
  - Fix: Use change management for planned modifications to the environment. Use incident management for unplanned interruptions to service. If a change leads to an incident, that is a sign that the change management process was inadequate, and you should investigate why.
- **Mistake:** Failing to include a rollback plan in the RFC, assuming the change will always work.
  - Why it is wrong: No change is guaranteed to succeed. Without a rollback plan, if a change fails or introduces issues, the IT team must figure out how to revert the change on the fly, which increases downtime and the risk of further errors. A rollback plan is a safety net that ensures you can quickly return to a known stable state.
  - Fix: Every RFC, especially for normal and emergency changes, must include a clear, written rollback plan. The plan should specify the steps to revert the change, who is responsible, and how long it will take. Test the rollback plan in staging if possible.
- **Mistake:** Approving emergency changes too easily without any post-implementation review.
  - Why it is wrong: Emergency changes are approved quickly because of urgency, but they bypass the full CAB review. This can lead to poor decisions if not properly managed. Without a post-implementation review, the organization loses the opportunity to learn from the emergency and improve the process for the future.
  - Fix: All emergency changes must be approved by an authorized group, even if it is a smaller emergency committee. After the change, a post-implementation review must be conducted as soon as possible to document what was done, why, and whether it could have been handled as a normal change. This review helps refine the process and educate the team.

## Exam trap

{"trap":"Choosing 'Get approval from the system administrator' as the first step in a change process.","why_learners_choose_it":"Learners often think that the person directly responsible for the system should have the final say on a change. In a small organization, this might be the case, but formal change management requires separation of duties. The administrator is typically the requester, not the approver. Learners choose this option because it seems practical and efficient, but it violates the principle of independent oversight.","how_to_avoid_it":"Remember that change management includes a separation of duties. The requester (who wants the change) should not be the sole approver. The approval should come from a designated change manager or a Change Advisory Board (CAB) that represents multiple stakeholders. In exam questions, look for options involving a CAB, a change manager, or a formal review board, as those are typically the correct approval sources."}

## Commonly confused with

- **Change management vs Configuration management:** Change management focuses on the process of controlling and approving changes to IT systems, while configuration management focuses on establishing and maintaining a consistent baseline (like a detailed inventory) of all hardware, software, and configurations. Configuration management answers what is supposed to be, while change management controls how you get there. They work together: change management updates configuration management records. (Example: When you install a new operating system patch, change management covers the approval and testing process. After the patch is applied, configuration management updates the inventory record to show the new patch level.)
- **Change management vs Patch management:** Patch management is a specific type of change that focuses on acquiring, testing, and installing software patches. Change management is the broader umbrella process that governs any change, including patches, hardware upgrades, configuration tweaks, and policy updates. All patch management should follow the change management process, but change management also covers non-patch changes. (Example: A patch management policy might require that all critical security patches be deployed within 48 hours, but the change management process would still require an RFC, testing, and a rollback plan for each patch deployment.)
- **Change management vs Incident management:** Incident management is the process of responding to and resolving unplanned service interruptions (incidents). Change management deals with planned modifications. The key difference is proactive vs reactive. A common confusion is that after an incident, teams often make emergency changes, which should still be managed through the change management process, not just the incident management one. (Example: When a server crashes (incident), incident management works to get it back online. If the fix requires a configuration change, that change itself should go through emergency change management to document what was changed and to plan for a permanent solution.)

## Step-by-step breakdown

1. **Create and submit a Request for Change (RFC)** — This is the formal start of the process. The person or team proposing the change documents the RFC, which includes details like the reason for the change, the systems affected, the risk assessment, the implementation plan, and the rollback plan. Creating a thorough RFC ensures that all stakeholders have the information they need to evaluate the change.
2. **Review and categorize the change** — The change manager or a designated team reviews the RFC to determine the category: standard, normal, or emergency. Categorization is based on risk, urgency, and impact. This step ensures that the appropriate level of scrutiny is applied. For example, a standard change (like a well-known software patch) may be pre-approved, while a normal change requires CAB review.
3. **Obtain formal approval from appropriate authority** — Based on the category, the RFC is sent for approval. Normal changes go to the Change Advisory Board (CAB) for a vote. Emergency changes may be approved by a smaller emergency committee or a designated manager. This step ensures that the change is evaluated by people with enough perspective to judge its business impact and risk. Separation of duties is maintained here.
4. **Plan and prepare for implementation** — Once approved, the implementation team prepares for the change. This includes scheduling a change window (a low-traffic time), preparing the test environment, communicating the change to users and stakeholders, and ensuring all resources (tools, permissions, backup) are ready. Proper planning minimizes disruptions and ensures that the team is not caught off guard.
5. **Implement and document the change** — The change is executed according to the approved plan, strictly within the scheduled change window. The implementer follows the documented steps, including any testing procedures. After implementation, the team documents the actual changes made, including the time, date, specific configuration changes, and any deviations from the plan. Documentation is critical for future troubleshooting and auditing.
6. **Conduct a post-implementation review (PIR)** — After a predetermined period (often one to two weeks), the change is reviewed to determine whether it achieved its objectives, whether any incidents resulted, and what lessons can be learned. This step closes the loop and feeds into continuous improvement. For emergency changes, the PIR also evaluates whether the emergency process was followed correctly and whether the change could have been handled as a normal change.

## Practical mini-lesson

Change management is one of the most important operational controls in any IT environment. In practice, the success of change management depends as much on culture as it does on process. Even the best-written policy will fail if the IT team does not fully embrace it. As a professional, you need to understand not only the steps but also the why behind them, and how to implement them in a real-world setting.

First, let's talk about the Request for Change (RFC). In a small company, an RFC might be an email or a simple form. In a large enterprise, it is typically created in an IT service management tool like ServiceNow. The RFC must be detailed enough for someone else to understand and execute the plan. The most important sections are the risk assessment and the rollback plan. Many professionals rush through these, but that is a mistake. A well-thought-out risk assessment identifies dependencies and potential failure points. For example, if you are updating a web server, consider whether the change will affect load balancers, reverse proxies, or database connections. Also consider the security implications: could the new version introduce new ports or protocols that alter firewall rules? The rollback plan should be step-by-step and tested. In the real world, rollback plans often fail because they were never tested or because the team assumed they could just 'undo' the change without knowing what the previous state was.

Second, categorization matters. Standard changes are those that are low risk and have been performed many times before. For example, applying a monthly security update to a standard Windows server can be a standard change if you have a documented procedure. This speeds up the process. Normal changes require CAB approval. In practice, CAB meetings can become bottlenecks, so it is common to have different levels of CAB (e.g., a local CAB for departmental changes and an enterprise CAB for infrastructure-wide changes). Emergency changes are for situations like a critical security vulnerability that is being actively exploited. The key to emergency changes is that they must be documented and reviewed afterwards; otherwise, the process can be abused to bypass controls.

From a configuration perspective, change management is often integrated with version control and automation. For example, when using Terraform for cloud infrastructure, every change to the configuration can be submitted as a pull request (RFC), reviewed by peers (CAB), tested in a staging environment (plan/apply), and documented automatically (Terraform state files). This is a powerful pattern called Infrastructure as Code (IaC), which enforces change management automatically. Similarly, for network devices, changes are often made through a centralized management platform that logs every command executed and can roll back to a previous config.

What can go wrong? A common failure mode is scope creep: a change that starts as simple but expands as the implementer decides to fix other things while they are at it. This increases the risk and bypasses the original RFC approval. The fix is to always stick to the approved scope. If you see something else that needs fixing, create a new RFC. Another failure is poor communication: users and stakeholders being unaware of a change that affects them. Always send a notification in advance, even if it is just a brief email. A third failure is inadequate testing. Even with testing, production environments can differ from staging. Consider using a phased rollout (canary deployment) or feature flags to limit the blast radius of a change.

Finally, as a professional, you should keep a personal log of every change you make, even in an informal setting. This habit will serve you well in audits and troubleshooting. When something breaks, the first question is always, What changed? Being able to answer that quickly will save hours of work. Change management is not bureaucracy for the sake of it; it is the documentation of your work and the safety net for your career.

## Memory tip

Think 'RRATI' for the core steps: Request, Review, Approve, Test, Implement. Remember that the rollback plan is the unsung hero; if a change goes wrong, you will be grateful you had one.

## FAQ

**What is the difference between a standard change and a normal change?**

A standard change is low-risk, pre-approved, and follows a documented procedure, like applying a routine software patch. A normal change requires individual review and approval by a Change Advisory Board because it is higher risk or has broader impact. The key difference is the level of pre-authorization and the review process.

**Can an emergency change be made without any approval?**

No. Emergency changes still require approval, but the process is accelerated. Typically, an emergency change is approved by a designated emergency change manager or a small committee, rather than the full CAB. The change must be documented and undergo a post-implementation review to ensure it was handled correctly.

**Why is a rollback plan so important in change management?**

A rollback plan is essential because no change is guaranteed to succeed. If a change fails or introduces unexpected issues, the rollback plan provides a clear, pre-defined path to revert the system to its previous stable state. This minimizes downtime and reduces the risk of further errors that could occur if the team has to improvise a fix under pressure.

**Who should be on a Change Advisory Board (CAB)?**

A CAB should include representatives from various stakeholder groups, such as IT operations, security, development, business units, and possibly finance for costly changes. The goal is to have diverse perspectives to evaluate the risk, impact, and business value of each proposed change. The CAB should not include the person who proposed the change to maintain separation of duties.

**How does change management relate to IT security?**

Change management directly supports IT security by ensuring that all changes are reviewed for security implications before implementation. This helps prevent unauthorized configuration changes that could introduce vulnerabilities, and it ensures that security controls like firewall rules, IAM policies, and encryption settings are properly maintained and audited. It is a key security control in frameworks like ISO 27001.

**What happens if a change is made without following the change management process?**

Making a change outside the process is called an unauthorized change. It bypasses all risk controls, testing, and approval. This can lead to service disruptions, security breaches, and compliance violations. Organizations typically have policies that may result in disciplinary action for such changes, and they may be flagged during audits. The change should be documented as an incident and the system reviewed for any damage.

## Summary

Change management is a structured, formal process that governs how modifications to IT systems are planned, approved, implemented, and reviewed. Its primary goal is to enable beneficial changes while minimizing the risk of service disruption, security incidents, or compliance failures. The process starts with a Request for Change (RFC), which is then categorized, reviewed, and approved by the appropriate authority. After testing and implementation, a post-implementation review ensures that the change achieved its objectives and that lessons are learned.

Change management matters because it protects the stability and security of IT environments. It reduces downtime, supports regulatory compliance, and fosters a culture of accountability. For IT certification exams, change management is a core topic in Security+, A+, and CISSP, among others. Exam questions test your ability to apply the process to scenarios, recognize proper documentation, and identify the roles and responsibilities involved. Common mistakes include skipping testing, forgetting the rollback plan, and confusing change management with incident or configuration management.

For learners, the key takeaway is that change management is not optional bureaucracy; it is a fundamental control that separates professional, mature IT operations from chaotic, reactive ones. On exam day, remember the steps: Request, Review, Approve, Test, Implement, and Review. Always prioritize the rollback plan and separation of duties. When you see a scenario question about a change that went wrong, the solution almost always involves a missing or broken change management step. Master this concept, and you will be better prepared for your exams and your career.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/change-management