Keeping a backup doesn't prove it's clean. Your ransomware response checklist needs a separate decision about what can safely return to production.
I'd organize the response around the evidence needed for each next action. Contain the incident under your approved plan, preserve what the investigation needs, and authorize recovery against explicit criteria. Record when those decisions happen; elapsed time doesn't make a system safe.
At Detection, Contain Before Reconnecting Anything
CISA's StopRansomware guide puts identifying and isolating affected systems first. It recommends coordinated isolation and communication outside the affected systems. For an MSP, that means checking that the channel directing the response is usable before relying on it.
Use your authorized containment procedure. The action could affect the client's ability to operate, so the incident record needs the decision maker as well as the technician carrying it out. Don't improvise a different isolation command for every endpoint because the usual console is unavailable.
Ask the response specialist to direct evidence collection rather than delaying necessary containment to experiment with unfamiliar forensic tools.
The incident lead needs to know when an isolation action failed. Have the technician report the result, not just that the command was sent. A device still communicating after an attempted isolation changes what the lead must decide next.
While Containment Runs, Keep a Decision Record
I'd start the incident clock at the observed detection and keep later discoveries separate. Record the time of each action and who authorized it. If you later establish an earlier compromise, add that finding without rewriting the original detection record.
Restrict access to that record. A shared incident channel is not permission to circulate sensitive client material to everyone in the MSP.
Give each unresolved decision a named owner. Keep an assumption visibly different from an observation, especially when you don't yet know whether another client is affected. A blank scope field isn't evidence that the incident stopped at the first reported machine.
I'd use this short record alongside the technical log. It keeps the next owner from having to reconstruct the decision from a chat history.
| Record | What to Enter |
|---|---|
| Observation | What was detected, on which asset or service, and when it was observed. |
| Action | Who authorized and performed it, the time, and the verified result. |
| Unknown | What remains unconfirmed, who is investigating it, and the next update point. |
| Decision | Who can approve the next action and what evidence they need. |
Before Recovery, Establish the Order and the Authority
Bring the client's authorized leadership and response contacts into the recovery decisions through the arrangements already agreed.
The owner should confirm who can approve response spending and which client representative can decide business priorities. Have the designated adviser assess notification duties against the actual circumstances. Don't substitute a generic breach deadline from a checklist for that assessment.
Handle any ransom demand through the agreed response and decision process. A ransom note doesn't grant a technician change authority or permission to commit the client.
Recovery is like moving into a repaired house: carrying the furniture back doesn't tell you whether the broken lock was fixed. Use that distinction when business pressure to reconnect gets ahead of the technical findings.
Test the Recovery Point and Its Destination
For a hypothetical client with several available recovery points, have the recovery lead record why the selected point is suitable. Include what remains uncertain. Don't label the most recent point clean merely because its backup completed before encryption became visible.
It depends on the evidence about the compromise timeline, the integrity of the recovery point, and the state of the destination environment. If any of those is unresolved, put the missing test or decision on the recovery plan. Don't turn uncertainty into a promised completion time.
Have the technical lead document the recovery checks and the remaining restrictions. The client decision maker needs that information when considering a limited return to service.
After Restoration, Verify the Business Service
Have the client test the agreed business function. A server booting successfully and a client completing their work are different observations.
Record what has returned and what remains restricted. The communication owner should give the client the next update point and bring new problems back to the response lead. Keep investigative work visible after users regain access.
The model puts baseline security in every plan and favors fixing delivery before adding clients. Apply that discipline to the follow-up: assign the corrective work and check its completion. Don't treat an added product as completion of the incident review.
Before relying on this checklist, rehearse it against a service you support. Ask the lead to identify the evidence needed before reconnecting that service and the person who can authorize it. Fix the missing dependency while the answer can still wait.
mspoutpost.com/articles/use-a-ransomware-response-checklist-before-you-restore
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.