4.2 Given a scenario, apply change management procedures.
📘CompTIA A+ Core 2 (220-1202)
1. Change Request Forms
- A change request form is the first step in change management.
- It is a document used to formally request a change to an IT system.
- Includes essential information like:
- Who is requesting the change
- What the change is
- Why the change is needed
- Impact on systems and users
- Purpose: Provides a clear record of the request and ensures all changes are tracked.
Example in IT: A user requests an update to the company email system to add a new security feature. This request is logged in a change request form.
2. Purpose of the Change
- Explains why the change is needed.
- Could be for:
- Security updates
- Bug fixes
- New features or hardware
- Helps decision-makers understand the importance of the change.
3. Scope of the Change
- Defines how big or small the change is.
- Answers questions like:
- Which systems will be affected?
- How many users will see the change?
- Helps assess the potential risk and complexity.
4. Change Type
Changes are classified based on how urgent and standard they are:
- Standard Change
- Pre-approved, low-risk, routine.
- Examples: Regular software patching, password policy updates.
- Does not require full approval each time.
- Normal Change
- Non-routine changes that require evaluation and approval.
- Examples: Installing new servers, upgrading database software.
- Evaluated for risk and impact.
- Emergency Change
- Must be applied immediately due to an urgent issue.
- Examples: Fixing a critical security breach or server crash.
- Usually bypasses some normal approval steps but still documented.
5. Date and Time of Change
- Important to schedule changes to minimize disruption.
- Change Freeze: A period when no changes are allowed (often during holidays or peak business periods).
- Maintenance Windows: Pre-planned periods where updates, patches, or system changes occur.
Example: Applying OS updates to company servers between 2 AM–4 AM when users are not online.
6. Affected Systems / Impact
- Identifies what systems, devices, or applications will be affected.
- Determines who will be impacted (users, departments, or external clients).
- Helps IT plan downtime, backups, and communication.
7. Risk Analysis
- Evaluates possible negative effects of the change.
- Assign a risk level:
- Low: Minimal impact, easily reversible
- Medium: Some users affected, may cause minor downtime
- High: Critical systems affected, could cause major downtime
- Helps IT teams prepare mitigation strategies.
8. Change Board Approvals
- Most IT organizations use a Change Advisory Board (CAB):
- Team of IT staff and management who review and approve changes.
- Ensures risks are understood and mitigated.
- Only approved changes are implemented.
9. Implementation
- The actual execution of the change.
- Could involve:
- Installing software updates
- Reconfiguring network settings
- Deploying new hardware
- Should follow documented procedures to reduce errors.
10. Peer Review
- Another IT professional checks the change before or after implementation.
- Ensures the change:
- Follows standards
- Is safe
- Will not negatively affect systems
- Acts as a quality control step.
11. End-User Acceptance
- After implementation, users confirm the system works correctly.
- IT collects feedback to ensure:
- The change meets requirements
- No new issues are created
- Helps close the change request formally.
✅ Key Takeaways for Exam
- Always document changes from request to implementation.
- Understand types of changes: standard, normal, emergency.
- Schedule changes to minimize disruption: maintenance windows, change freeze.
- Evaluate risk, impact, and approvals.
- Include peer review and end-user acceptance to ensure quality.
- The goal of change management is controlled, safe, and trackable changes in IT systems.
