Change management
Write an after-hours change note the morning team can trust
A handover note that records what changed overnight, what was replaced, how success was checked, and which risks the morning team still needs to watch.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
An overnight change can finish at two in the morning and still leave the morning team guessing. The engineer knows what was replaced, which check passed, and which warning was expected, but that knowledge often stays in a chat thread. A short change note carries the same facts into the next shift in a form someone can act on. The note is not a project report, because it exists to help the next person decide what to do first.
Record the change before the window
Write the intended change, the systems affected, and the maintenance window before the work starts. Name the person performing the change and the person who approved it. List the users or services that will notice an interruption and the expected duration. A note written in advance is easier to trust than a summary reconstructed after a failed step.
Add the rollback plan and the point at which it will be triggered. Record the backup or snapshot that protects the change and where it is stored. Note any dependency on a vendor or a scheduled job that must be paused. The morning team needs to know what normal was supposed to look like before it can judge what actually happened.
Capture the state you replaced
Record the version, configuration, or certificate that was in place before the change. Save the relevant output rather than describing it from memory. If a setting was changed, note the old value and the new value in the same line. This detail is what makes a rollback quick when the change has to be reversed.
Photograph or export the dashboard that shows the service before the window. Note the baseline error rate, latency, and queue depth. Without a baseline, a normal spike looks like a new problem at eight in the morning. Keep the baseline beside the change record rather than in a separate monitoring tab.
Write the checks that prove success
List the specific checks that show the change worked, including the command or page used and the expected result. Include one check from the user's side, such as opening the application or sending a test message. Record the time each check ran and who ran it. A check that only confirms the service is running does not prove the user can work.
Separate the checks that passed from the checks that were skipped and explain why. A skipped check is an open risk, not a neutral detail. If a check failed and was fixed, record both the failure and the fix. The morning team should be able to repeat the same checks without asking what was meant.
Name the rollback trigger
State the condition that would have caused a rollback, such as an error rate above a stated level or a login failure for a named group. Record whether that condition occurred and what was done. If the change was kept despite a warning, say why. A vague statement that everything looked fine is not enough for the next person to judge.
Describe the rollback steps in the order they would be run and the expected time to complete them. Confirm that the rollback was tested or that it is a documented vendor procedure. Record any step that would require a second person or a vendor call. The morning team should not have to invent a recovery plan under pressure.
List the open risks
Write down what is still unverified, such as a scheduled job that has not run yet or a client that has not reconnected. Note the time when the next confirmation is expected and who will check it. Distinguish a known warning from a possible failure. The difference decides whether the morning team watches the service or starts troubleshooting.
Include any temporary workaround that is still in place and the date it should be removed. Record the owner of each open item and the ticket that tracks it. If a vendor is investigating, note the case number and the last response. Open risks are the part of the note the morning team will read first.
Hand over to the morning owner
Send the note to the named morning owner rather than a general channel where it can be missed. Ask for an acknowledgement so the handover is explicit. Put the most important fact in the first two lines, such as a service still degraded or a rollback pending. The rest of the note supports that headline rather than burying it.
Keep the note in the change record and link it from the ticket. If the morning owner finds a problem, they should be able to add a follow-up without rewriting the original. A short handover call is useful for a risky change, but the written note remains the record. The call confirms understanding, while the note preserves the evidence.
Close the note with evidence
After the morning checks, record the final state and close the note. Confirm that the temporary workaround was removed, the monitoring is quiet, and the user-facing check passed. Note any difference between the expected result and the actual result. A closed note with evidence is what makes the next change easier to approve.
Review a sample of change notes each month for gaps in the baseline, the checks, or the rollback trigger. Feed the pattern back into the change template rather than blaming the engineer who wrote the note. A template that asks for the right facts gets better notes. The measure is whether the morning team can act without calling the overnight engineer.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the asset, endpoint, change, physical access, and identity practices discussed in this guide. The NIST patch management planning guidance supports the change handover steps, and NIST digital identity guidance supports the contractor authentication checks. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the MFA enrollment review and the spare laptop loaner log before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what write an after-hours change note the morning team can trust means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review