Resource
Incident response planning
An incident response plan exists so that decisions get made calmly in advance rather than at three in the morning by whoever answered the phone. Most of it is not technical. The parts that fail during real events are almost always the human sequence nobody wrote down.
What the plan has to answer
Six questions. If the document cannot answer all six, it is a description rather than a plan.
| Question | Who decides |
|---|---|
| Has an incident occurred?Someone has to make the call to start the process | A named person, with a named deputy |
| Who is contacted first?Insurer requirements often dictate early steps | Predefined list |
| Who can isolate systems?Waiting for approval at 3am costs more than a false positive | Agreed in advance |
| How are staff told?Email and phones may both be unavailable | Alternate channel |
| Who speaks externally?Multiple versions of events cause lasting damage | One named person |
| When does notification start?Statutory clocks usually begin at discovery | Legal or compliance owner |
The first hour
What you do immediately affects both recovery and, if you carry a policy, the insurance position.
- Disconnect affected machines from the network but do not power them off, because memory holds evidence
- Do not delete anything, including ransom notes and suspicious emails
- Contact your IT provider and your insurer before taking further action
- Preserve logs before anything is rebuilt or restored
- Assume credentials are compromised and plan a coordinated reset
- Start a written timeline immediately, because reconstructing it later is unreliable
Why discovery starts the clock
Nearly every notification requirement, state and federal, runs its timeframe from the moment you discover an incident rather than from the moment you finish understanding it.
That turns detection speed into a compliance matter. A business that finds an incident in hours begins its process with the full statutory window available. One that finds out weeks later, often from a customer or a bank, starts with the window already consumed.
It is also why an untested plan is worse than none. False confidence during the one hour that matters is expensive, and a plan naming a person who left two years ago provides exactly that.
Common questions
Answered before you ask.
How long should the plan be?
Short enough that someone can follow it under pressure. A few pages naming people, phone numbers, decision authority and the first six steps beats a forty page document nobody opens. Keep a printed copy, because a plan stored only on the network is unavailable during precisely the events it was written for.
Who should be on the contact list?
Your IT provider, your cyber insurer, legal counsel, and whoever internally can authorise decisions and spending. Include mobile numbers rather than desk numbers and confirm them annually. Add law enforcement contact details so nobody is searching for them during an event.
How often should we test it?
A walkthrough at least annually and after any material change to the environment or the team. It does not need to be an elaborate simulation. Sitting six people around a table and talking through a scenario for an hour surfaces most of the gaps.
Related
Read next.
Cybersecurity services
Endpoint detection, email security, monitoring and user training.
Managed detection and response
24 by 7 human review of security alerts, with authority to contain.
IT compliance for Washington State businesses
RCW 19.255 breach notification and the My Health My Data Act, which most national guidance misses.
Backup and disaster recovery
Immutable backups with tested restores and a defined recovery window.
IT contracts and SLAs explained
Auto renewal, out clauses, and who owns your data and documentation.
Start with the assessment, not the contract.
We document what you have, test whether your backups restore, and give you the findings in writing. Yours to keep either way.