A change, a problem, and a question
An engineer tightens a client's conditional access policy one evening, as discussed with the office manager on the phone last week. The next morning, the sales director cannot sign in from a hotel abroad. He is not happy, and asks who authorised the change. The engineer says the office manager did. The office manager remembers a conversation, but not agreeing to anything specific.
There is no written change request, no statement of who would be affected, no rollback plan, and no recorded approval. The change was sensible. The process was not.
Why changes go unrecorded
Formal change management feels heavy for small clients, so MSPs skip it. But the absence of a light version means approvals live in memory.
- Changes are discussed in calls and chats, not written up.
- The person who approves is not always the person with authority.
- Impact on users is not spelled out before the change.
- Rollback plans exist in engineers' heads.
- Approvals are not linked to the ticket that made the change.
What unrecorded changes cost
| Missing element | Consequence |
|---|---|
| No written approval | Disputes about who agreed what |
| Wrong approver | A change agreed by someone without authority |
| No user impact stated | Surprised users and angry calls |
| No rollback plan | Longer outages when a change goes wrong |
| No change history | Harder troubleshooting later |
Who at each client may approve which kind of change is the client's decision. We record it and make sure the right person is asked.
A light change process we build
- A change request form in your PSA with a few required fields: what, why, who is affected, risk, plan, rollback and proposed time.
- Change categories you define (standard, normal, emergency), with standard pre-approved changes needing no sign-off, as agreed with each client.
- An approver list per client and category, so the request goes to someone with authority.
- Approval by email link or client portal, recording the approver, time and the exact version they approved.
- Scheduling blocked until approval is recorded, except for emergency changes, which need approval after the fact.
- A change calendar per client and a history linked to tickets, for troubleshooting and QBRs.
We keep it as light as possible. For a small client, a change request should take minutes to write and seconds to approve.
Changes, with a paper trail
The engineer writes the conditional access change request: all users to require MFA from compliant devices, sales team travelling next week affected, rollback by disabling the policy. It goes to the managing director, who is the approver for security changes at this client. She approves it with a note to wait until the sales team is back.
The change happens the following week. If someone asks who authorised it, the answer is a link. If something goes wrong, the rollback plan is already written. And at the QBR, the client sees a list of changes made during the quarter, which shows the work behind the scenes.
Standard changes keep the process from getting in the way. Adding a user to a distribution list, resetting MFA for a verified user, or approving a Windows feature update for a pilot group can be agreed once with each client as pre-approved, so engineers do not send approval requests for routine work. Only changes that alter security settings, network access or business systems go through sign-off, and each client can move items between the lists as trust builds.
Your engineers benefit as well. A recorded approval protects the engineer who made a sensible change at the client's request, and a written rollback plan means whoever is on call that night can undo it without phoning the person who made it.
Could your MSP use this?
- Changes are agreed on the phone and not written down.
- You have had a dispute about who approved a change.
- Approvals come from whoever answers, not from someone with authority.
- Rollback plans are not recorded.
- You cannot list changes made for a client last quarter.