Change Management — 220-1202 Study Guide

Change management: deliberate, approved, reversible

A technician is about to push a new group policy to every workstation, or upgrade the accounting app over the weekend. The change may be perfectly correct and still take down the business if it behaves unexpectedly and there is no fast way back. Change management is the set of practices that stop that from happening: it makes every change deliberate, approved, and reversible instead of ad hoc. Three terms recur throughout: a group policy is a Windows setting pushed centrally from a server, production means the live systems people depend on at this moment, and a maintenance window is an agreed slot when disruption is tolerated. The page follows the change lifecycle in order, names the artifact a change owes at each point in it, and ties each scenario to the standing document that records it. On the CompTIA A+ Core 2 exam objectives^[1] it is objective 4.2, one of two operational disciplines that share this page, the other being objective 4.1, the documentation that records the work, and it sits inside the wider practice of IT service management. Two seams with the sibling pages are worth settling before you start: this page owns the incident report you write afterwards while safety and communication owns the incident response you carry out at the scene, and this page only requires that a rollback exists while backup and recovery owns how you actually build and test one.

Documented business processes

Underneath any single change sit three standing practices, the documented business processes every change is expected to follow:

Rollback plan. The pre-written path back to the previous known-good state if the change fails. It is also called a backout plan; the two names mean the same thing, and the exam uses both. You write it before you implement, not after something breaks.
Sandbox testing. Proving the change works in an isolated, non-production copy of the environment first, so a bad change is caught off the production floor. A sandbox is a safe, walled-off test space; nothing you do there touches live systems or data.
Responsible staff member. The single named person accountable for the change from request through to closing it out. One owner, not a committee, so there is never confusion about who drives it and who answers for the outcome.

Miss any one of these and a routine change can turn into an outage nobody planned for and nobody can quickly undo. The next section is the step-by-step process that carries these three practices out.

The change request lifecycle, step by step

Objective 4.2 lists the parts of change management rather than a numbered procedure, but they fall into a natural working order, and that dependency is what items turn on: you approve and plan the way back before you ever implement. The common wrong answer is the technician who jumps to the middle, implementing before the risk was analyzed or before anyone approved it. The figure below traces the same working order top to bottom, with the backout branch hanging off implementation.

1. Change request

Every change starts as a written request, usually a standard request form, so there is a record of what was proposed and by whom. A complete request states the purpose of the change (the reason it is needed: a security patch, a new feature, a fix), the scope (exactly what it touches and, just as important, what it does not), the affected systems and impact (which systems, services, and users feel it, and the expected disruption), and the date and time, ideally inside a maintenance window that minimizes disruption.

2. Risk analysis

Before anyone signs off, you assess what could go wrong and how badly, then assign a risk level (commonly low, medium, or high). The risk level drives how much scrutiny the change needs: a high-risk change to a core system earns a closer review and a firmer backout plan than swapping a desktop wallpaper.

3. Plan the change and the way back

Planning has two halves, and both are graded. The plan for change is the step-by-step of how you will implement it. The backout plan (the rollback plan from the previous section) is how you undo it and return to the last known-good state if it fails. This is also where you test the change in a sandbox, so the plan is proven rather than hoped for.

4. Change board approval

A change board (often a change advisory board, or CAB) reviews the request, the risk, and the plans, then approves, defers, or rejects it. This approval is the gate: you do not implement a normal change without it. The board exists so no single person pushes a risky change unchecked.

5. End-user acceptance

The people who use the affected systems have to accept the change: they are told what is changing, when, and how it affects them, and for user-facing changes they confirm it works for them afterward. Skipping this is how a technically successful change still generates a flood of tickets on Monday morning.

6. Implement the change

Carry out the change per the plan, inside the agreed window. If it fails here, you do not improvise: you execute the backout plan and restore the previous state. The whole point of writing that plan in stage three was to make this moment calm instead of frantic.

7. Verify, then document

Confirm the change did what it was meant to and broke nothing else, then document the change: what was done, when, by whom, the outcome, and whether the backout plan was needed. That record closes the loop and feeds the knowledge base for next time. Documentation is a real, graded step, not an afterthought.

The change lifecycle, numbered as a working order not a published sequence: approval and a written backout plan come before implementation; a failed change triggers the backout, not improvisation.

Ticketing systems

A user reports a problem, and the shop needs a record of it that outlives the conversation. Objective 4.1 covers documentation and support systems, and the exam tests which fields the ticketing record holds and when you reach for it.

A ticketing system records every support request from open to close. A well-formed ticket captures user and device information (who reported it and on which machine, tying the ticket to the asset record), a description of the problem (the symptom in the user's words plus what you observe), a category and severity (what kind of issue it is, and how urgent or impactful, which drives prioritization), an escalation level (when it moves to a higher tier or a specialist, and to whom), and progress notes and a resolution (clear updates as you work, and finally how it was fixed).

That written record is a skill of its own: clear, concise problem descriptions, progress notes, and a stated resolution^[1] let the next technician pick up the ticket, or find it months later, without guessing. The interpersonal side of communication, how you speak with the user, lives in safety and communication; here the skill is writing the record.

Asset management and the procurement life cycle

The other operational record tracks property rather than work, and it follows each device from the purchase order to the shredder.

Asset management is the inventory of hardware and software the organization owns, usually held in a database system rather than a spreadsheet once it grows past a few dozen devices. Each asset carries an asset tag and ID (a physical label and a unique identifier that tie the device to its record), an assigned user (who currently holds it), procurement details (when and how it was acquired), and warranty and licensing status (the hardware warranty and any software license or entitlement attached, so renewals and audits are not a surprise). Software license types themselves are covered in safety and communication; here they are simply a field on the asset record.

The procurement life cycle is the arc every asset travels, from purchase to disposal, and the inventory record follows it the whole way. The figure below walks that arc from procurement to disposal, in the working order the inventory record follows. Disposal is not just discarding hardware: a retired device is wiped or destroyed so no data leaves with it, which is why the last stage loops back to the security practices in encryption and access control.

An asset moves from procurement to disposal, a working arc rather than a published sequence; the record tracks its tag, owner, warranty, and license the whole way.

The document library: policies, procedures, and maps

The previous two sections covered the operational records you touch daily, the ticketing system and the asset inventory. Beyond those, a shop keeps a library of standing documents. A new hire needs provisioning, a user asks what they are allowed to install, or you need to trace how two offices connect: each sends you to a different document here. Exam questions turn on matching that kind of scenario to the right document type, so group them by the job they do: operational records, maps and procedures, and policies and reports. Those three families are the generating model rather than a closed list of documents: any standing document a shop keeps sorts into one of them by the job it does, and the types named below are the ones exam scenarios reach for most, among others.

Maps and procedures

A network topology diagram is a map of how devices, segments, and links connect. You read it before a change to see what the change touches, and during a fault to trace the path a packet takes.

Standard operating procedures (SOPs) are step-by-step instructions for a repeatable task, so it is done the same way every time regardless of who does it. The objectives call out three: the procedure for a custom installation of a software package, the new-user setup checklist (what to provision when someone joins: account, group membership, hardware, and access), and the end-user termination checklist (what to revoke when someone leaves: disable the account, reclaim the device, and remove access). The termination checklist is a security control as much as a procedure, because a forgotten active account is a way back in.

Policies and reports

An acceptable use policy (AUP) states the rules for how users may use company systems, networks, and data, and what is prohibited. Users typically sign it, and it is what the organization points to when someone's use crosses the line.

Regulatory and compliance requirements are the external rules the organization must meet, whether legal or industry-specific, documented so the team knows what applies. A splash screen is one visible piece of compliance: a banner shown at logon or on a site that states terms, warnings, or required notices before a user proceeds.

An incident report records what happened during a security or safety incident, when, and how it was handled. Here you write the report; the step-by-step response process (first-responder duties and preserving evidence) is covered in safety and communication.

The knowledge base ties it together

The knowledge base sits across all of these: a searchable store of articles and known fixes that turns one technician's solved problem into every technician's shortcut, and lets users self-serve. Documenting a resolved ticket, the last step of the troubleshooting method, is exactly what feeds it.

The IT documentation library in three families: operational records, maps and procedures, and policies and reports.

How the exam frames these questions

Operational-procedures items read as short workplace scenarios, and two instincts win most of them. When the stem describes a planned change, pick the step that must come before implementing, never jumping ahead to implement. When it describes an information need, name the document type that records it.

The scenario	Right answer	Tempting wrong answer
A change is planned; what comes first?	Submit the request and analyze risk; get approval before you implement	Implement it now because it is a small change
The change might fail; what must exist?	A backout (rollback) plan to restore the last known-good state	A second change ready to patch the first if it breaks
Who signs off on a normal change?	The change board (CAB), after reviewing risk and the plans	The technician decides alone to save time
Users will be affected; what is owed?	End-user acceptance: notify and confirm before and after	Skip it; the change is technically complete
Where is a laptop's model, owner, and warranty?	Asset management / inventory, by its asset tag and ID	The ticketing system
A recurring issue has a known fix; where?	The knowledge base	Re-troubleshoot it from scratch each time
A new hire needs provisioning; what guides it?	The new-user setup checklist, an SOP	Do it from memory
A departing employee's access; what guides it?	The end-user termination checklist	Handle it later when there is time
A logon banner shows required warnings; what is it?	A splash screen, part of compliance	The acceptable use policy the user signs

A few reversals recur. Implementing before approval is almost always wrong: the change board's sign-off is the gate. Rollback plan and backout plan are the same thing under two names, so an item that offers both is not testing a difference between them. Asset details (model, owner, warranty, tag) live in the inventory, not the ticket, even though a ticket references the device. And documenting the change is a real, graded step, so a "the change is done, now what" stem wants verify and document, not close it silently. When the scenario shifts to conduct, privacy, or an active incident response, it leaves this page for safety and communication; when it needs an actual backup method, it belongs to backup and recovery.

Which IT document answers which question

Document type	What it records	Reach for it when
Ticketing system	Who reported what, device and user details, category, severity, escalation, and how it was resolved	You take or track a support request from open to close
Knowledge base / article	Reusable, searchable fixes and how-to articles	You need a known solution, or want to save one for reuse and self-service
Asset management / inventory	Hardware and software owned, asset tags and IDs, assigned users, procurement, warranty, and licensing	You need to know what a user has, its age, or its warranty and license status
Network topology diagram	How devices, segments, and links connect on the network	You need to see the network layout before a change or during a fault
Standard operating procedure (SOP)	Step-by-step instructions for a repeatable task	A task must be done the same way every time, such as onboarding or a custom software install
Acceptable use policy (AUP)	The rules for how users may use company systems and data	You define or enforce what users are and are not allowed to do
Incident report	What happened during a security or safety incident, when, and how it was handled	An incident occurred and must be recorded for review and compliance

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Change management makes changes deliberate, approved, and reversible

Change management replaces ad-hoc changes with a controlled process: every change is documented, risk-assessed, approved, and given a way back before it touches production. The goal is not bureaucracy but avoiding self-inflicted outages, so the exam frames it as choosing the controlled step over the fast one.

The rollback plan and the backout plan are the same thing

A rollback plan, also called a backout plan, is the pre-written path back to the last known-good state if a change fails. CompTIA uses both names for one concept, so an item offering both is not testing a difference between them.

Trap Treating the rollback plan and the backout plan as two separate documents; they are one plan under two names.

10 questions test this

Write the backout plan before you implement, not after it breaks

The backout plan has to exist before the change goes live, because once a change has failed in production there is no time to design a recovery. Having the way back ready is what turns a failed change into a quick restore instead of an incident.

Trap Implementing a change first and working out how to undo it only if it fails; the backout plan is a planning-stage deliverable.

4 questions test this

Test a change in a sandbox before it reaches production

Sandbox testing proves a change works in an isolated, non-production copy of the environment, so a bad change is caught off the live floor. The sandbox is walled off, so nothing done there touches real systems or data.

Trap Testing the change directly on production because it looks small; the point of the sandbox is to fail safely, away from users.

Every change has one named responsible staff member

A single named person is accountable for the change from request to close, so there is never confusion about who drives it or who answers for the outcome. This is ownership by one person, distinct from the board that approves the change.

Approve and plan the rollback before you implement a change

A change works through a natural order: submit the request, analyze risk, plan the change and its backout, get change-board approval, get end-user acceptance, implement, then verify and document.

Trap Jumping to implementation before the change has been risk-assessed and approved; risk analysis, planning, and approval come first.

7 questions test this

A change request states purpose, scope, affected systems, and timing

The request form records why the change is needed (purpose), exactly what it touches and what it does not (scope), which systems and users are affected and the expected impact, and the date and time, ideally inside a maintenance window. This documented request is the starting point the rest of the process reviews.

2 questions test this

Risk analysis assigns a risk level that sets the scrutiny

Before approval you assess what could go wrong and how badly, then assign a risk level such as low, medium, or high. A higher risk level means a closer review and a firmer backout plan, so the level directly drives how much process the change needs.

1 question tests this

A technician must complete a change request form before deploying a new email client across all company workstations. Which of the…

The change board's approval is the gate before implementing

A change board, often a change advisory board (CAB), reviews the request, risk, and plans and approves, defers, or rejects the change. For a normal change you do not implement without that approval, which exists so no single person pushes a risky change unchecked.

Trap Letting a technician implement a normal change on their own authority to save time; the change board's sign-off is required first.

11 questions test this

End-user acceptance means users are told and confirm the change

The people who use the affected systems are notified what is changing, when, and how it affects them, and for user-facing changes they confirm it works afterward. Skipping acceptance is how a technically successful change still produces a wave of tickets.

4 questions test this

Documenting the change is a required final step, not optional

After verifying the change worked and broke nothing else, you record what was done, when, by whom, the outcome, and whether the backout was used. That record closes the loop and feeds the knowledge base, so a 'the change is done, now what' question wants verify and document.

Trap Closing out a completed change without documenting it; the record is a graded step of the process.

7 questions test this

A ticket captures user, device, problem, category, severity, and escalation

A ticketing system tracks a support request from open to close, recording who reported it and on which device, a description of the problem, its category and severity for prioritization, the escalation level, and progress notes ending in the resolution. Category and severity are what drive how the queue is prioritized.

8 questions test this

Ticket notes need clear, concise problem descriptions, progress notes, and a resolution

The written record is its own skill: a clear problem description, running progress notes, and a stated resolution let the next technician resume or find the ticket later without guessing. This record-keeping is separate from interpersonal communication, which is professionalism rather than documentation.

11 questions test this

Asset management records what you own, its tag, owner, warranty, and license

Asset management is the inventory of hardware and software, usually in a database once it grows, with each asset carrying an asset tag and unique ID, its assigned user, procurement details, and warranty and license status. When a question asks where a device's model, owner, or warranty lives, it is the inventory.

Trap Recording a device's owner, tag, or warranty in the ticket instead of the asset inventory; the ticket only references the device.

9 questions test this

Assets follow a procurement life cycle from purchase to disposal

An asset moves through procurement, tagging and inventory, assignment to a user, maintenance (warranty and licenses), retirement, and disposal, with the inventory record tracking it the whole way. Disposal is not just discarding hardware: the device is wiped or destroyed so no data leaves with it.

7 questions test this

The knowledge base turns one solved problem into everyone's shortcut

A knowledge base is a searchable store of articles and known fixes, so a resolved issue becomes reusable instead of re-solved, and users can self-serve. Documenting resolved tickets is what feeds it, which is why a 'known fix already exists' scenario points here.

Trap Re-troubleshooting a recurring issue from scratch when a knowledge base article already documents the fix.

15 questions test this

A network topology diagram maps how devices connect

A network topology diagram shows how devices, segments, and links connect, so you read it before a change to see what will be touched and during a fault to trace the path. It is a map, not a procedure or a policy.

8 questions test this

SOPs standardize repeatable tasks like new-user setup and termination

A standard operating procedure (SOP) gives step-by-step instructions so a repeatable task is done the same way every time, regardless of who performs it. The objectives name three: a custom software-install procedure, the new-user setup checklist for onboarding, and the end-user termination checklist for revoking a departing user's access.

Trap Skipping the end-user termination checklist so a departed employee's account stays active; the unrevoked account is an open door.

6 questions test this

An AUP is the signed rules for how users may use company systems

An acceptable use policy (AUP) states what users may and may not do with company systems, networks, and data, and users typically sign it. It is the document the organization points to when someone's use crosses the line.

A splash screen is a compliance notice banner, not the AUP itself

A splash screen is a banner shown at logon or on a site that states terms, warnings, or required notices before a user proceeds, and it is one visible piece of meeting regulatory or compliance requirements. It differs from the acceptable use policy, which is the signed rules document rather than a displayed banner.

Trap Calling a logon warning banner an acceptable use policy; the banner is a splash screen, while the AUP is the signed policy document.

An incident report is the record; incident response is the process

An incident report is a document type that records what happened during a security or safety incident, when, and how it was handled. It is distinct from the incident response process (first-responder duties, preserving evidence), which is a separate operational-procedures topic.

Trap Confusing the incident report you write with the incident-response process that governs handling; the report is the artifact, the response is the procedure.

1 question tests this

A technician made an unapproved configuration change that caused a two-hour outage of the company email system. After service is restored,…

Documenting every incident is what surfaces recurring problems

Recording each ticket and incident with its symptoms, root cause, and resolution turns individual fixes into data you can analyze: it exposes a problem that keeps recurring across many users, feeds accurate help-desk metrics, and drives the continuous improvement of SOPs after a post-incident review. Resolving issues without logging them destroys that visibility, so the same root cause gets treated over and over instead of fixed once.

Trap Treating each repeat of the same issue as an isolated ticket instead of reading the pattern behind them.

4 questions test this

An emergency change is expedited, not skipped

An urgent fix such as a critical security patch or a production-down outage follows the emergency change process, which streamlines approval through a smaller authorized body, often an Emergency Change Advisory Board (ECAB), instead of waiting for the next scheduled CAB meeting. The steps are compressed, not dropped: documented justification, risk assessment, and a change record are still required so the change stays accountable.

Trap Treating an emergency as license to apply the change with no approval or record.

5 questions test this

Escalate to the next tier with detailed notes when you run out of road

When a technician exhausts the standard troubleshooting or knowledge-base procedures, or a problem exceeds their access level or expertise, the correct next step is to escalate the ticket to the next support tier rather than keep guessing. Attach detailed notes of every step already taken so the higher tier does not repeat the work and can continue from where you stopped.

Trap Reaching for more trial-and-error fixes instead of escalating once the standard procedures are exhausted.

6 questions test this

A knowledge base is only useful if its articles are kept current

Knowledge base articles must be reviewed and updated whenever the underlying SOP, tool, or procedure changes, so technicians never follow outdated steps, and scheduling periodic reviews is how the repository stays reliable. A fixed article is saved with its revision date, while an article about a discontinued OS or tool is archived and labeled as legacy rather than left in active search results where it causes confusion.

Trap Deleting an outdated article outright instead of archiving it as legacy for anyone who still needs the history.

5 questions test this

Also tested in

References

CompTIA A+ Core 2 (220-1202) Certification Exam Objectives (V15, Document Version 3.0)