Objective 4.2: Given a scenario, apply change management procedures

Cert: CompTIA A+ Core 2 (220-1202) V15 Domain: 4.0 Operational Procedures Weight: Part of the 21% Operational Procedures domain Depth: Given a scenario, apply. The candidate must execute change management: documented processes, rollback/backup plans, sandbox testing, request forms, change types, board approvals, implementation, peer review, acceptance.

What this objective tests

You should know the components of a proper change management process: documenting the proposed change, planning rollback, testing in sandbox, formal request submission, approval workflow, implementation, and post-change validation.

Key facts

Documented business processes:

• Pre-existing documentation of how IT processes work. Reference point for what's normal.

Rollback plan:

• Predefined procedure to undo the change if something goes wrong.
• Examples: snapshot before change, backup file copies, scripted reversal commands.
• Critical for any non-trivial change. If you can't rollback, you can't proceed safely.

Backup plan:

• Confirmed-good backup taken just before the change. Distinct from rollback plan (which is a procedure); backup is the data state.
• Verify the backup is restorable before starting (not just that it ran).

Sandbox testing:

• Test the change in a non-production environment that mirrors production.
• VM with same OS + config, isolated network, fake data.
• Catches problems before they hit users.

Responsible staff members:

• Named owners of the change: who implements, who approves, who's on standby for issues.

Request forms:

• Formal submission documenting the change: purpose, scope, type, schedule, impact, rollback, backup status, approvals.
• Standard for production changes in mid-size+ orgs.

Purpose of the change:

• Why are we doing this? Security patch, feature deployment, infrastructure upgrade, vendor-required change.

Scope of the change:

• What's affected: systems, users, services, integrations. Wider scope = more review.

Change type:

• Categorization that drives approval workflow and risk handling.

Standard change:

• Low-risk, well-understood, pre-approved (e.g., monthly Windows updates, routine cert renewals).
• Streamlined approval.

Normal change:

• Non-emergency, non-standard. Goes through full change management review.

Emergency change:

• Required immediately to prevent or recover from incident (security patch for active exploit, outage fix).
• Streamlined approval but documented after the fact.

Date and time of change:

• When the change will happen. Coordinate with stakeholders to avoid conflicts.

Change freeze:

• Period when changes are not allowed (holiday seasons, year-end financial close, major releases).
• Emergency exceptions still permitted.

Maintenance windows:

• Pre-defined recurring times when changes can happen (e.g., Sundays 2-6 AM).
• Less disruptive than ad-hoc timing.

Affected systems / impact:

• Documented list of systems, services, and users affected.
• Drives communication plan and acceptance testing scope.

Risk analysis:

• Probability and impact of failure scenarios. Risk = likelihood × impact.

Risk level:

• Low, medium, high. Often a matrix combining probability and impact ratings.
• Drives the approval level required.

Change board approvals:

• Change Advisory Board (CAB) reviews higher-risk changes. Members typically include IT leadership, security, ops, sometimes business stakeholders.
• Approve, deny, or request more information.

Implementation:

• Execute the change per the approved plan. Document each step in real time.

Peer review:

• Another tech verifies the change worked. Catches mistakes the implementer might not see.
• Especially valuable for high-risk changes.

End-user acceptance:

• Affected users confirm the change works for them. Closes the change.

Common gotchas

• No rollback plan. Change goes sideways; no clear path back. Drag-out incident.
• Backup "ran" but not verified restorable. Discover during the rollback attempt that the backup is corrupt. Always verify restorability before the change.
• Sandbox doesn't match production. Test passes in sandbox, fails in prod. Sandbox should mirror prod data shape, network, integrations as closely as possible.
• Emergency change skipped documentation. Six months later, no one remembers what was changed. Document after the fact at minimum.
• Change during freeze. Year-end financial close, someone deploys a "tiny patch," breaks reporting. Respect freezes.
• Peer review skipped to save time. Defect that peer review would have caught makes it to production.
• End-user acceptance not collected. "Change is complete" but users don't know how it affects them. Often surfaces as new tickets later.

Real-world context

Standard change workflow for a typical SMB MSP:

1. Initiate: Request form filled out (PSA, ServiceNow, or simple email/ticket).
2. Plan: Scope, schedule, rollback plan, backup plan, risk assessment documented.
3. Test: Sandbox or pilot group verification.
4. Approve: Manager or CAB sign-off depending on risk level.
5. Communicate: Notify affected users, stakeholders, on-call. Include rollback plan window.
6. Execute: Implement per plan. Document each step.
7. Verify: Peer review and end-user acceptance.
8. Close: Update CMDB, KB articles, runbooks. Mark ticket complete.

For smaller orgs, this scales down to "ticket says what we're doing and why; manager OK'd it; rollback plan in a note; done by Sunday morning." But the discipline of writing it down survives even at small scale.

Sources

• [CompTIA A+ 220-1202 Exam Objectives Version 4.0, Section 4.2](../../../../../../30-RevyTechJourney/CompTIA%20A%2B%20220-1202%20Exam%20Objectives%20%284.0%29.pdf)
• [ITIL: Change Management](https://www.axelos.com/certifications/propath/itil-4-master/itil-4-strategic-leader)
• [Atlassian: Change Management overview](https://www.atlassian.com/itsm/change-management)
• [NIST SP 800-128: Security-Focused Configuration Management](https://csrc.nist.gov/publications/detail/sp/800-128/final)