Change Management | A+ Core 2

A+ Core 2 — 220-1102 | Domain 4.1

Change
Management

Structured process for requesting, approving, implementing, testing, and documenting changes to IT systems — reducing outages and ensuring accountability.

19 Slides Domain 4.1 RFC • CAB • Rollback • Documentation Exam 220-1102

Slide 2 of 19

Why Change Management?

Uncontrolled changes are the leading cause of preventable outages.

Control Risk

Every change to a production system carries the risk of unintended consequences. Change management evaluates that risk before the change is made, not after the outage page fires at 2 AM.

Maintain Accountability

Documentation tells you who changed what, when, and why. Without it, troubleshooting a post-change failure involves guessing. The change log is your incident timeline.

Enable Rollback

A planned rollback procedure means failures have a defined recovery path. "We can revert in 15 minutes" is only true if the rollback was designed before the change window opened.

A network engineer pushes an ACL change to a core switch at 5 PM Friday without a change ticket. VoIP breaks for an entire floor. No one knows what changed. It takes 4 hours to identify and reverse the modification. Change management exists to prevent exactly this.

Slide 3 of 19

Change Management Lifecycle

Six stages in a circular flow — each stage gates entry to the next.

Slide 4 of 19

Request for Change (RFC)

The formal document that initiates the change management process.

Required Fields

Change description, justification (business reason), scope of impact, affected systems, requester name and contact, proposed change window, rollback procedure, approval status, and post-change verification method.

Change Types

Standard: pre-approved, routine, low-risk (e.g., scheduled patch). Normal: requires full CAB review and approval. Emergency: bypasses normal review; performed immediately; documented retroactively; approved by emergency CAB or single designated authority.

Scope of Change

Defines what will and will not be modified. Prevents scope creep during implementation. If something is not in the RFC scope, it should not be changed — even if the technician spots something else that "could be improved."

Exam Tip

The A+ exam distinguishes between documenting changes before (RFC) and after (change log). Questions about "what should be filed before making a change" point to the RFC. Questions about "what should be updated after a change" point to documentation / change log.

Slide 5 of 19

Change Advisory Board (CAB)

Cross-functional group that reviews, prioritizes, and approves or rejects change requests.

CAB Composition

IT management, system owners, network/security architects, business unit representatives, and service desk leads. The composition ensures technical, operational, and business perspectives are represented in the approval decision.

CAB Responsibilities

Assess technical risk and impact. Evaluate the rollback plan adequacy. Confirm the change window does not conflict with business-critical periods. Approve, defer, or reject the RFC. Document the decision with rationale.

Approval Criteria

Adequate justification, low risk rating, complete rollback plan, non-conflicting change window, qualified implementer identified, testing procedure defined.

Emergency CAB

Smaller group (often 2-3 senior members) that can convene quickly for urgent changes. Same standards apply; faster process. The change is still documented retroactively in full.

Rejection

Rejected RFCs are returned to the requester with documented reasons. The requester addresses the deficiencies and resubmits. A rejected RFC does not authorize any change activity.

Slide 6 of 19

Change Windows

Pre-approved time slots when changes can be implemented with minimal business impact.

Selecting a Change Window

Choose periods of lowest user activity: late nights, weekends, holidays. Avoid end-of-quarter for financial systems, exam weeks for education, peak season for retail. The CAB verifies window selection against the business calendar.

Change Freeze Periods

Defined periods during which non-emergency changes are prohibited. Examples: year-end financial close, peak retail season (Black Friday), election infrastructure lockdowns. Freeze periods are published in advance by IT leadership.

Change Type	Typical Window	Advance Notice
Standard (pre-approved)	Any scheduled maintenance window	None (pre-approved by policy)
Normal	Weekend or off-hours window	5-10 business days minimum
Emergency	Immediate — any time	Retroactive documentation required

A technician has an approved RFC scheduled for Saturday 2 AM. At 1:55 AM they discover the primary backup is incomplete. The correct action: do not proceed. Notify the change owner. Reschedule. Never implement without a verified fallback position.

Slide 7 of 19

Rollback Decision Tree

Post-implementation: either document success or execute rollback.

Slide 8 of 19

Rollback Planning

A rollback procedure must be defined before the change window opens — not improvised during an incident.

What to Capture Before

Current configuration exports, registry exports, database backups, configuration snapshots, VM checkpoints or snapshots, network device running configs (copy run start, then export). Document the "before" state completely.

Rollback Trigger Criteria

Define in advance: what constitutes failure? Specific error codes, service unavailability for more than X minutes, failed verification test, business unit reports loss of function. Ambiguous criteria lead to delayed decisions during outages.

Rollback Time Estimate

The RFC must estimate rollback duration. Change windows are sized to include: implementation time + testing time + rollback time (if needed) + buffer. A 2-hour change with a 1-hour rollback needs a 4-hour window minimum.

A firmware update to a storage array fails mid-flash. The rollback procedure in the RFC describes restoring from the pre-change firmware backup on the management controller. Without this pre-documented procedure, the team is improvising on production storage during an outage.

Slide 9 of 19

Risk Assessment

Evaluate likelihood and impact before the CAB makes an approval decision.

Risk Rating Components

Likelihood: probability the change causes an unintended effect. Impact: severity if it does — how many users affected, how critical the system, can business operations continue. Risk score = Likelihood x Impact.

Affected Systems Analysis

List every system that directly or indirectly depends on what is being changed. A firewall rule change can affect hundreds of application flows. A DNS change can break authentication. Map the dependencies before finalizing the RFC.

Risk Level	Likelihood	Impact	CAB Action
Low	Unlikely	Minimal disruption	Approve with standard review
Medium	Possible	Moderate service impact	Approve with mitigation plan
High	Probable	Major service disruption	Require full CAB review, off-hours window
Critical	Likely	Business-stopping impact	Defer until risk can be reduced

Slide 10 of 19

Testing & Verification

Every change must include a defined success criterion and a verification method.

Pre-Change Testing

Test changes in a staging or lab environment before production. Confirm the implementation procedure works as expected. Identify problems before the production change window, not during it.

Post-Change Verification

Run the verification checklist defined in the RFC. Confirm: services are running, performance is normal, no error events in logs, affected business processes function correctly. Verification is not complete until all checklist items pass.

Smoke Testing

Quick functional test immediately after implementation. Validates the primary intended outcome before comprehensive testing. Examples: can users authenticate, can the application start, does the service respond on its expected port.

Verification vs. Monitoring

Verification is point-in-time testing during the change window. Monitoring is ongoing post-implementation observation for delayed effects (memory leaks, gradual performance degradation, deferred errors). Both are required for high-risk changes. The RFC should specify the monitoring duration.

Slide 11 of 19

Change Documentation

Complete documentation closes the loop and populates the organizational knowledge base.

Change Log

Chronological record of all changes: what was changed, when, by whom, what RFC authorized it, and the outcome. Referenced during incident investigation to identify "what changed before this broke."

CMDB Updates

Configuration Management Database. A CMDB tracks the state of all IT assets and their relationships. Every successful change must update the relevant CMDB records to reflect the new configuration state. Stale CMDB data is worse than no CMDB.

Network Diagrams & Runbooks

Network diagrams, server build documents, and procedure runbooks must be updated to reflect changes. Documentation that diverges from reality creates false confidence and delays troubleshooting.

Six months after a firewall rule change, a security audit asks for the justification. The RFC and change log are pulled: change ticket CT-2024-0847, approved by CAB on 2024-08-12, implemented by J. Torres, RFC cites business requirement from ticket BIZ-1122. Compliance satisfied. Without the change log, no answer exists.

Slide 12 of 19

Emergency Changes

Urgent changes that cannot wait for normal CAB review — same standards, faster timeline.

What Qualifies

Active security breach requiring immediate remediation. Production outage with no viable workaround. Data loss event in progress. Life-safety system failure. The threshold must be defined by policy — not by a technician deciding something is urgent enough.

Emergency Process

1. Notify designated authority (ECAB member or change manager). 2. Obtain verbal or emergency ticket approval. 3. Implement the change. 4. Document the RFC and rationale retroactively within 24-48 hours. 5. Full CAB post-implementation review.

Emergency Change Abuse

Emergency change status should require explicit authorization — not self-declared. Organizations that allow engineers to self-declare emergencies see the emergency channel become the path for skipping process. Track emergency change frequency; a rising trend indicates process breakdown.

Exam Distinction

The exam distinguishes emergency changes (process bypassed with authorization, documented after) from unauthorized changes (no process, no authorization, no documentation). Emergency is controlled fast-path. Unauthorized is failure. Both differ from standard and normal changes.

Slide 13 of 19

Scope Creep & Unauthorized Changes

The most common way change management fails in practice.

Scope Creep

A technician during a patch window notices another "quick fix" and applies it without a separate RFC. The unauthorized change introduces a conflict that takes hours to diagnose because it was not documented and is not in the change log.

Unauthorized Change Definition

Any modification to a production system not covered by an approved RFC. Includes "fixing while I'm in there," undocumented configuration changes, and changes made outside the approved window. All are violations regardless of technical outcome.

A+ Exam Rule

If an exam question asks what is wrong with a technician who "also updated the driver while patching the OS" without a separate RFC — the answer is unauthorized change / scope creep. The technical result does not matter; the process violation does.

During an approved server patch window, a technician reconfigures the NIC teaming settings because they noticed it was suboptimal. The server reboots after patching and loses network. The NIC change — not the patch — caused the issue. Troubleshooting is delayed because only the patch is in the change log.

Slide 14 of 19

Change Type Comparison

Standard, Normal, Emergency, and Unauthorized — know each type and its implications.

Type	Pre-Approval	Documentation	CAB Review	Example
Standard	Policy pre-approved	Before + after	Not required	Weekly patch deployment
Normal	RFC + CAB approval	Before + after	Required	Firewall rule addition
Emergency	ECAB / authority approval	After (within 24-48 hrs)	Post-implementation review	Security breach remediation
Unauthorized	None	None (by definition)	N/A	Ad hoc config change

Exam Note

The A+ exam focuses on Normal and Emergency. Know: Normal requires CAB before. Emergency requires authorization and retroactive documentation. Unauthorized requires disciplinary follow-up. Standard is routine (pre-approved category, not a separate process).

Slide 15 of 19

Ticketing & Tracking Systems

Change management depends on a formal tracking system — not email, chat, or memory.

ITSM Platforms

ServiceNow, Jira Service Management, Remedy, ConnectWise. These platforms provide RFC workflows, approval routing, change calendar, CMDB integration, and audit trails. The A+ exam does not test specific platforms, but tests the concepts they enforce.

Change Calendar

Visual schedule of all planned changes. Prevents change collisions (two teams modifying the same system in the same window). Shows freeze periods. Allows stakeholders to see what changes affect their systems and when.

Ticket Lifecycle

Draft → Submitted → Under Review → Approved / Rejected → Scheduled → In Progress → Completed → Closed. Each state transition is timestamped and attributed. The full lifecycle is preserved for audit.

A+ Exam Context

Questions may describe a help desk scenario where a technician "makes a change without creating a ticket." The answer will always be that a ticket should be created to document the change. Even a minor configuration adjustment to a production system warrants a ticket.

Slide 16 of 19

Communication Plan

Stakeholders must be notified before, during, and after a change.

Pre-Change Notification

Notify affected users and business units in advance: what is changing, when the change window is, what service interruption to expect (if any), and who to contact if issues arise. Minimum notice: typically 48-72 hours for normal changes.

During-Change Updates

For extended windows, provide status updates at defined intervals. Notify immediately if the change is running longer than expected or if rollback is being initiated. Use a dedicated communication channel (incident bridge, status page, etc.).

Post-Change Notification

Confirm completion to all stakeholders: change successful, all services verified, any residual items tracked as follow-on work. Or: change rolled back, services restored, root cause analysis scheduled. Close the loop so users are not left wondering.

A VPN gateway is rebooted during a change window without advance notification. A remote employee presenting to a customer loses connectivity mid-presentation. The change was technically successful — but the lack of communication caused business impact. Communication is part of change management.

Slide 17 of 19

Change Management in Practical Scenarios

How change management principles appear in A+ lab and scenario questions.

1 OS upgrade: File RFC, document current build via systeminfo, take system image backup (rollback artifact), obtain CAB approval, schedule off-hours window, verify post-upgrade, update asset record.

2 Driver update: Even a driver update in production should have an RFC. Capture current driver version (Device Manager > Properties), test in staging, define rollback (roll back driver option in Device Manager).

3 Network config change: Export running config before. Document the exact commands to be entered. Define rollback commands. Test in a lab environment. Apply in window. Verify connectivity matrix post-change.

4 User reports an issue after a change: First check the change log for changes made in the past 24-72 hours. "What changed before this broke" is always the first diagnostic question after a change window.

5 Rollback required: Execute the documented rollback procedure. Do not improvise. After rollback, verify that the pre-change state is fully restored before declaring success and closing the window.

Slide 18 of 19

Exam Scenario Drills

Apply change management concepts to A+ question patterns.

1 Q: A technician updated firmware without a ticket. This is an example of what? Unauthorized change. Regardless of outcome, no RFC = unauthorized.

2 Q: A server patch causes a service to fail. What should be done immediately? Execute the rollback plan defined in the RFC. Then document what happened and schedule root cause analysis.

3 Q: What is the purpose of a change freeze period? Prevent non-emergency changes during high-risk business periods to reduce the chance of outages when the organization cannot absorb disruption.

4 Q: An emergency patch is needed now. Full CAB review takes 5 days. What is the correct process? Emergency change: notify ECAB/authority, get approval, implement, document retroactively within 24-48 hours.

5 Q: After a successful change, what must be updated? Change log, CMDB/asset records, network diagrams or runbooks if topology changed, and the RFC must be formally closed.

Slide 19 of 19

Change Management Summary

Key retention points for Domain 4.1.

The Six-Stage Lifecycle

Request (RFC) → Review (CAB) → Approve (authorized) → Implement (change window) → Test (verify) → Document (close RFC, update CMDB). Every stage must complete before the next begins.

The Non-Negotiables

1. RFC before any change. 2. Rollback plan before implementation. 3. Verify after implementation. 4. Document outcome. 5. Unauthorized changes are always wrong, regardless of outcome.

The Exam Pattern

Most Domain 4.1 questions follow one of three patterns: (a) identify the correct next step in the lifecycle, (b) identify what went wrong when a step was skipped, (c) match a change scenario to its type (standard/normal/emergency/unauthorized). Internalize the lifecycle and the three rules: RFC before, rollback plan before, document after.

Final retention check: Before any production change, ask three questions. Is there an approved RFC? Is there a tested rollback plan? Is the change window confirmed with stakeholders notified? If any answer is no — stop. That is change management in three questions.