MSP Change Management: How to Handle IT Changes Without Breaking Things

Every IT change carries risk. A patch that fixes one vulnerability can break an application. A network change that improves performance can take down a service. A migration that modernises infrastructure can introduce downtime.

Change management exists to control that risk. Here is how it works in the MSP context and why it matters for your business.

Why Change Management Matters

Without change management, IT environments become unpredictable. Changes happen without documentation, without testing, without approval, and without rollback plans. When something breaks, nobody knows what changed or how to fix it.

For MSPs managing multiple client environments, the stakes are higher. A poorly managed change at one client can cascade across the MSP's entire portfolio.

The Cost of Poor Change Management

Outcome	Business Impact
Unplanned downtime	Lost revenue, productivity, customer trust
Data loss	Recovery costs, compliance penalties
Security vulnerabilities	Exposure to attack, breach costs
Configuration drift	Inconsistent environments, harder to troubleshoot
Compliance failures	Audit findings, regulatory penalties

Change Types in the MSP Context

Most MSP change management frameworks follow ITIL classification:

Standard Changes

Pre-approved, low-risk changes that follow an established procedure:

• Applying approved security patches during maintenance windows
• Creating new user accounts following established templates
• Resetting passwords
• Rotating API keys per schedule

Standard changes do not require individual approval because the risk has been assessed once and deemed acceptable for the defined procedure.

Normal Changes

Changes that require review and approval before implementation:

• Software upgrades and version changes
• Network configuration changes
• Server additions or modifications
• Firewall rule changes
• Application deployments

Normal changes require a Change Advisory Board (CAB) or designated approver to assess risk and approve the change.

Emergency Changes

Urgent changes needed to restore service or address critical security vulnerabilities:

• Emergency patching for actively exploited vulnerabilities
• Service restoration after outage
• Critical security incident response

Emergency changes follow an expedited approval process but still require post-implementation review and documentation.

The Change Management Process

A typical MSP change management workflow:

1. Request

The change is documented with:

• What is being changed
• Why the change is needed
• Expected impact and risk
• Rollback plan
• Requested implementation window
• Dependencies on other changes

2. Assessment

The change is assessed for risk and impact:

• Risk level — low, medium, high, critical
• Impact scope — which systems and users are affected
• Rollback feasibility — can the change be reversed?
• Testing requirements — does the change need testing first?
• Dependencies — what other changes or systems are involved?

3. Approval

The appropriate authority approves the change:

• Standard changes — pre-approved via documented procedure
• Normal changes — CAB or designated approver
• Emergency changes — expedited approval, post-implementation review

4. Implementation

The change is implemented according to the plan:

• During the agreed maintenance window
• With rollback procedures ready
• With communication to affected parties
• With monitoring for unexpected impacts

5. Review

After implementation, the change is reviewed:

• Did the change achieve its objective?
• Were there any unexpected impacts?
• Is the rollback still available if needed?
• Should this change become a standard change?

What Businesses Should Expect from Their MSP

Change Communication

Your MSP should notify you of changes that affect your environment. The level of notification depends on the change:

Change Type	Notification Expected
Standard	Monthly summary or available on request
Normal	Advance notice (typically 48-72 hours)
Emergency	Immediate notification, followed by incident report
Major	Formal change request with your approval required

Change Records

The MSP should maintain a change log that includes:

• Date and time of change
• What was changed
• Who authorised the change
• What was the expected outcome
• What actually happened
• Rollback actions if needed

Your Input

For changes that significantly affect your environment (major upgrades, migrations, security changes), you should have input into the decision. Your MSP should not make major changes to your environment without your knowledge and agreement.

Red Flags in MSP Change Management

Watch for these warning signs:

No Documented Process

If your MSP cannot describe their change management process, they probably do not have one. This means changes happen informally, without oversight, and without accountability.

Changes Without Notification

If you discover changes to your environment that you were not informed about, the MSP is not following basic change management. This is a trust violation.

No Rollback Plans

Every change should have a rollback plan. If your MSP implements changes without a way to reverse them, they are gambling with your environment.

"Emergency" Changes for Everything

Some MSPs classify all changes as "emergency" to avoid the normal approval process. If every change is urgent, nothing is urgent — and the process is being circumvented.

Configuration Drift

If your environment has accumulated undocumented changes over time, configuration drift has set in. This makes troubleshooting difficult and increases the risk of conflicts between changes.

How to Engage with Your MSP's Change Process

Request Visibility

Ask for access to the change log. You do not need to approve every standard change, but you should be able to see what has been changed and when.

Participate in CAB

For significant changes, request a seat at the Change Advisory Board or at least notification of CAB decisions. This gives you input into changes that affect your business.

Review Change Reports

Ask for monthly change reports summarising all changes made to your environment. This keeps you informed without requiring you to approve routine maintenance.

Establish Change Windows

Agree on maintenance windows with your MSP. Major changes should happen during low-impact periods (after hours, weekends) with advance notice.

Define Emergency Protocols

Agree on what constitutes an emergency and how emergency changes will be communicated. Even urgent changes should not happen without any notification.

Change Management and Compliance

For regulated industries, change management is not optional — it is a compliance requirement:

• Essential 8 — application control and patch management require controlled change processes
• ISO 27001 — includes specific requirements for change management controls
• SOC 2 — change management is a key trust service criteria
• PCI DSS — requires documented change management for cardholder data environments

Our Essential 8 Implementation Checklist includes change management as part of implementation planning.

The Bottom Line

Change management is not bureaucracy — it is the difference between controlled, predictable IT operations and chaotic, reactive firefighting. A good MSP will have a clear change management process and will welcome your engagement in that process.

If your MSP is making changes to your environment without documentation, notification, or approval, that is a problem worth addressing. Your IT environment is too important to be managed on the fly.

---

Use our MSP Health Score to evaluate your MSP's operational maturity, or our MSP Vendor Management Guide for broader relationship management strategies.