Incident response planning when you don't have a security team
7 min read
Most nonprofits, newsrooms, and small NGOs don't have a security team. Many don't even have a dedicated IT person. But they handle sensitive data — donor records, source materials, beneficiary information, legal files — and they face real threats.
When something goes wrong, the difference between a manageable incident and an organizational crisis often comes down to whether anyone had a plan. Here's how to build one that works for a small team with no dedicated security staff.
Why most incident response guides don't work for small organizations
Enterprise incident response frameworks assume you have a SOC, a CISO, an IR team, a legal department, and a communications team. They describe roles like "Incident Commander" and "Forensic Analyst" as if these are different people. For a 15-person nonprofit, they might all be the same person — and that person probably also manages the website and orders office supplies.
An effective IR plan for a small organization needs to be:
Short enough to actually read. If it's 40 pages, no one will open it during a crisis.
Specific enough to follow. "Assess the situation" isn't a step — it's a platitude. "Check if the compromised account has access to the donor database" is a step.
Honest about your resources. If you don't have forensic tools or log retention, your plan shouldn't assume them.
Tested at least once. A plan that's never been exercised is a document, not a capability.
The five things your plan actually needs
1. A call list — who does what
During an incident, the first question is always "who do I call?" Your plan needs a short, current list:
Primary responder: The person who makes initial decisions. This is usually whoever is most technically capable on staff. Name and phone number, not a role title.
Decision maker: The person authorized to take disruptive action — disable accounts, take systems offline, notify affected parties. Usually the ED or a senior leader.
External contacts: Your IT provider, your hosting provider, your security consultant (if you have one), your insurance carrier, legal counsel. Include after-hours contact information.
This list needs to be printed and accessible offline. During a serious incident, your email and internal systems may be the thing that's compromised.
2. A detection checklist — how you'd notice
Small organizations often don't have monitoring tools that would alert them to a breach. That means detection usually comes from someone noticing something wrong. Give your team a checklist of warning signs to watch for:
Unexpected password reset notifications
Login alerts from unfamiliar locations or devices
Files moved, deleted, or shared that shouldn't have been
Emails sent from staff accounts that the staff member didn't send
New forwarding rules or filters on email accounts
Reports from external contacts that they received suspicious emails "from" you
Unexpected multi-factor authentication prompts
Make it clear that reporting a concern is always the right call, even if it turns out to be nothing. The cost of investigating a false alarm is negligible compared to missing a real incident.
3. Containment steps — stop the bleeding
The first priority in any incident is to stop it from getting worse. For most small-organization incidents, this means:
Compromised account: Reset the password immediately. Revoke all active sessions. Check for forwarding rules, connected apps, and recent changes. Enable or re-verify MFA.
Compromised device: Disconnect from the network (WiFi and wired). Don't turn it off — if possible, leave it running for potential evidence. Use a different device to change passwords for any accounts accessed from the compromised device.
Ransomware or malware: Isolate the affected device immediately. Check whether backups are accessible and intact. Do not pay a ransom without consulting external expertise.
Data exposure: Identify what data was exposed and to whom. Determine whether notification obligations apply (funder requirements, regulatory requirements, or ethical obligations to affected individuals).
4. Communication templates — what to say
During an incident, you will need to communicate with multiple audiences: staff, leadership, funders, affected individuals, possibly media. Writing these communications from scratch during a crisis leads to delays, errors, and inconsistent messaging.
Pre-draft templates for:
Internal all-staff notification: "We are aware of a security incident affecting [system]. Here's what we know, here's what we're doing, here's what you should do."
Funder notification: Appropriate for grant-required reporting. Factual, measured, focused on response actions taken.
Affected individual notification: If personal data was exposed. Many jurisdictions have specific requirements for breach notification content and timing.
These don't need to be perfect — they need to exist so you're not starting from a blank page at the worst possible moment.
5. A post-incident review — learn from it
After the immediate crisis is handled, schedule a debrief within a week. Document:
What happened and how it was detected
What the response looked like in practice vs. what the plan said
What worked and what didn't
What changes need to be made — to the plan, to the tools, to the training
This is the step most organizations skip. Don't. It's how a single incident makes you more resilient instead of just more stressed.
Test it before you need it
A tabletop exercise doesn't need to be elaborate. Spend an hour walking through a scenario: "A staff member clicked a phishing link and their email account is sending messages to your donor list. Go."
Watch what happens. Who does everyone call? Does anyone know the password reset process for your email provider? Can anyone access the call list? Does the decision maker know they're the decision maker?
The exercise will expose gaps. That's the point. Fix them before the scenario is real.