The 48 Hours After a Breach: What MSPs Need to Have Ready
Most incidents aren't a technical failure. They're a response failure.
The initial compromise — the phishing email clicked, the unpatched system exploited, the credentials stuffed — is often the smaller problem. What turns a containable incident into a disaster is the twelve hours of confusion, the wrong people being called, the backups nobody had checked, the insurer who wasn't notified in time.
This is a minimal playbook. It won't cover every scenario, but it covers the decisions you need to have made before the phone rings at 2am.
The First Hour: Contain, Don't Investigate
The instinct when a breach is discovered is to understand what happened. Resist it. Investigation comes later. The first priority is stopping the bleeding.
Isolate affected systems — remove them from the network, but do not power them off. Powered-off systems lose volatile memory that may be critical evidence. If remote access isn't possible, call someone in.
Revoke credentials — compromised accounts need to be disabled immediately. If you don't know which accounts are compromised, start with admin and privileged accounts, then work down.
Preserve evidence — do not start remediation on affected systems until forensic copies are taken, or you've consciously accepted the trade-off. Evidence destroyed in the first hour is gone permanently.
Activate your incident response retainer or contact — if you have one. If you don't, this is the moment you'll regret not having one.
Hours 2–6: Who Needs to Know Right Now
The client's senior leadership
They need to be told factually, without speculation, what is known: what systems are affected, what has been done so far, and what you don't know yet. No guessing on data exposure until you have evidence.
Legal counsel
Many organisations don't realise they need legal involved until they've already said something inadvisable to a third party. Lawyer first, statements second.
Cyber insurer
Most cyber insurance policies require notification within a defined window — sometimes 24 or 48 hours. Missing it can jeopardise a claim. Find the policy, find the notification number, call it.
ICO (if personal data is involved)
Under UK GDPR, personal data breaches must be reported to the ICO within 72 hours of the organisation becoming aware, where the breach is likely to result in risk to individuals. This clock starts when the organisation knows — not when you've finished investigating.
The Checklist Nobody Has Until They Need It
Every MSP should have the following documented for each client, before an incident occurs:
- Emergency contact list — client-side (who makes decisions out of hours)
- Insurer name, policy number, and emergency notification number
- ICO reporting portal login or nominated DPO contact
- Legal counsel contact
- Backup status — where, when last tested, RTO/RPO
- Asset inventory — what systems exist and who manages them
- Credential store location — how to access it in an emergency
- Communication templates — holding statement, client notification, staff notification
That last item matters more than most people expect. In the middle of an incident, with a client panicking and a journalist potentially calling, having a pre-approved holding statement saves enormous time and prevents improvised statements that create liability.
"We are aware of a security incident and are working urgently to investigate and contain it. We will provide updates as more information becomes available."
That's it. That's the holding statement. Agree it with legal before you ever need it.
Hours 6–48: Remediation and Communication Rhythm
Once systems are contained and key stakeholders are engaged, shift to a structured rhythm:
Every 2–4 hours: internal situation report. What do we know? What are we doing? What do we still not know?
Every 6–12 hours: client update. Even if the update is "no new information, containment is holding." Silence is worse than a brief update.
Remediation sequence: restore from known-good backups where possible. Rebuild rather than clean infected systems where time allows — cleaned systems leave uncertainty. If rebuilding isn't possible, document the compromise fully and accept the risk consciously.
Post-incident review: within two weeks of resolution, conduct a structured review. What happened? What worked? What didn't? What changes are being made? This is not a blame exercise — it's the mechanism by which organisations actually learn from incidents.
The One Thing That Prevents Most of This
A tested backup.
Not a backup. A tested backup. One that has been restored to a test environment in the last 90 days and confirmed to work. The number of incidents we're aware of where backups either didn't exist, were also encrypted by ransomware, or failed on restore is not small.
If you're an MSP and you're not verifying client backup restores quarterly, that's the single highest-value change you can make today.