Most incident response guidance is written for organizations with a security operations center and an on-call rotation. That guidance is useless to an organization with six employees and no IT department, so it gets ignored, and the plan never gets written.
What follows is a sequenced plan. Five steps, ordered by priority. Most of them cost nothing, and the whole plan can realistically be built in a single afternoon.
During an incident, someone will need to decide whether to disconnect systems, pay a ransom, or notify clients before the full scope is known. If that person is not named in advance, these decisions get made by committee, under pressure, often too late.
- Name one person with the authority to make fast decisions during an incident, and one backup if that person is unreachable.
- If you have a board, agree in advance on what triggers board notification and how fast.
- Write both names down in the plan. Do not rely on it being obvious in the moment.
In the first hours of an incident, you will need phone numbers, not email addresses, because email may be exactly what the attacker controls. Assembling this list during a calm afternoon is far easier than assembling it during a crisis.
- List phone numbers for your IT or managed service provider, your cyber insurance carrier if you have one, an attorney familiar with breach notification law, and your bank's fraud line.
- Add your cyber insurance policy number and any incident hotline listed on the policy. Many carriers require notification within a specific window to preserve coverage.
- Keep this list somewhere accessible if systems are down: a printed copy in a desk drawer works.
Clients, donors, and staff will find out something happened. The only real choice is whether they hear it from you, on your terms, or from someone else, on theirs.
- Write one or two sentences describing what you owe clients or stakeholders in the event of a breach, and roughly how quickly.
- Check your state's breach notification law for specific timing requirements. Many have strict statutory deadlines tied to specific types of data.
- Decide who drafts and approves external communication during an incident, so it is not written from scratch under pressure.
Evidence gets destroyed by accident more often than by malice. A well-meaning staff member reboots an infected machine to "fix it," and in doing so erases the exact information an investigator needed.
- Write a simple instruction: if a system is suspected to be compromised, disconnect it from the network but do not turn it off or reinstall anything.
- Identify who is authorized to make changes to affected systems during an incident, so untrained good intentions do not overwrite evidence.
- If you use a managed service provider, confirm in advance whether they retain logs, and for how long.
A plan that has never been read by the people expected to use it is a document, not a plan. A short walkthrough now saves confusion later.
- Walk through a simple scenario with your team: "Someone clicks a phishing link and enters their password. What happens next?"
- Confirm everyone knows who the decision-maker is and where the call list lives.
- Put a reminder on the calendar to review the plan every six months, or after any staff change in a named role.
What this gets you
This plan will not prevent an incident. Nothing fully does. What it does is compress the most damaging period of any incident, the first confused hours, into a sequence of decisions that have already been made in advance.
When this plan is in place
Organizations with even a basic response plan consistently recover faster and at lower cost than organizations without one, regardless of the sophistication of their technical defenses. Once this plan exists, the natural next question is how to keep it alive: how often to test it, who else needs to know it exists, and how leadership stays engaged with it over time. That is the subject of next week's final post in this series.
Ready for a clearer picture of where you actually stand?
A 30-day Security Business Review gives you a clear picture of your highest-priority gaps and a practical roadmap you can act on. No enterprise complexity. No vendor pitches. Just defensible decisions.
Start a Conversation