Detect and report
One known channel, immediately
Whoever notices first - an employee, a monitoring alert, a locked file - reports it right away through one agreed channel, without trying to quietly fix or hide it first.
Incident response
The worst time to invent a plan is during the incident.
A suspected breach or ransomware event needs a sequence, not improvisation: who gets called first, who can disconnect a system, and who tells the team and any affected client. Here is what that sequence actually looks like.
The sequence
Five stages, in order, with a named owner for each.
Contain
Isolate fast, even if disruptive
Disconnect the affected device or account from the network quickly enough to stop it spreading, accepting the short-term disruption that containment causes.
Assess
Establish the facts first
Determine what was affected and what was not - the technical facts the rest of the response, and any legal notification decision, actually depend on.
Communicate
The right people, in the right order
Tell business leadership first, then employees, then any affected client or vendor - through a channel that does not depend on the system that might be compromised.
Recover and review
Confirm closed, not just quiet
Restore from a known-clean state, confirm the cause is actually closed rather than dormant, and hold a plain, blame-free review of what worked and what didn't.
Who does what
Four roles, so nobody waits on someone else to decide.
- Business leadership
- Declares the incident, approves any emergency spending or system shutdown, and makes the final call on notifying clients or the public.
- Managed IT team
- Contains the affected system, coordinates the technical assessment, and executes the agreed recovery steps.
- Employees
- Report what they noticed immediately, and follow the instruction they're given - including not touching the affected device themselves.
- Legal counsel
- Determines whether the event meets a legal reporting threshold and what any notification has to say - see the privacy-law compliance guide for that boundary.
Representative roles; actual assignments are confirmed in your own written plan and agreement.
Before you need it
Questions worth answering before a bad Tuesday, not during one.
- Does everyone know the one channel to report a suspected incident through, even if email or chat itself is down?
- Who is actually authorized to disconnect a device or system from the network without waiting for a meeting to approve it?
- Do we have a contact list for our own team, key vendors, and counsel that doesn't live only inside the system that might be affected?
- When was any part of this sequence last rehearsed, even as a short conversation around a table, rather than just written down?
Honest limit: this page does not promise a specific detection, containment, or recovery time, and no plan prevents every incident. A rehearsed sequence reduces confusion and wasted time during a real one - it does not guarantee an outcome.
Connect the work
See the baseline this plan builds on.
Reach the team
Tell us what needs an owner
Share your team size, current support setup, and the responsibilities you want clarified. We will use that to figure out whether an MSP introduction makes sense.
Online requests are not available right now. No message is sent from this page.