Despite your best security efforts, breaches and cyber incidents happen. Ransomware locks your data and demands payment. A phishing email gets through and staff wires funds to a fraudulent account. A disgruntled employee accesses systems they shouldn't. A vendor breach exposes your data. The question isn't if an incident will happen, but when and how prepared you'll be. Organizations with incident response plans recover faster, minimize damage, and communicate effectively. Organizations without plans panic, make mistakes, and face worse outcomes.

An incident response plan documents your procedures for detecting, investigating, containing, and recovering from security incidents. It assigns responsibilities, establishes timelines, and clarifies communication. Having the plan documented before an incident allows your team to act decisively rather than figuring out next steps during a crisis. This article walks through creating an incident response plan appropriate for nonprofits without extensive IT resources.

Components of an Incident Response Plan: What to Document

A nonprofit incident response plan doesn't need to be complex. It should be clear, specific, and practical. Core components include: incident response team with roles and contact information, detection and reporting procedures, investigation steps, containment procedures, recovery procedures, communication protocols, and post-incident review processes.

Your incident response team should include your IT person or vendor (or someone who manages technology), your ED or someone with authority to make decisions, your communication person or someone who handles external communications, someone from finance or operations (in case financial systems are affected), and potentially legal counsel. Document names, roles, and contact information. Make sure people know they're on this team and understand their role.

Document your detection procedures. How will you know if an incident is happening? Who monitors systems for unusual activity? What are signs of a breach or attack (unusual account activity, system slowdowns, data access alerts, ransom notes)? Create a simple guide for staff to recognize potential incidents and report them. Designate someone to receive reports and coordinate response.

Document investigation steps. When an incident is reported, what do you do first? Typically: secure the affected systems (isolate them if necessary), photograph the screen if there's a ransom note or suspicious message, preserve evidence (don't delete logs or evidence thinking you're cleaning up), contact your IT vendor or external incident response service, notify leadership, and gather information about what happened.

Document containment procedures. If a system is compromised, how do you prevent further access? Do you disconnect it from the network? Do you change passwords? Do you force logout of all sessions? Document your specific steps. Containment is about stopping the attacker and preventing spread while you investigate.

Document recovery procedures. Once you understand what happened, how do you restore systems? From backups? By rebuilding from scratch? Who has authority to approve restoration? What testing happens before systems are back in production? Recovery procedures vary based on the system, so be specific to your environment.

Incident Communication: Internal and External

During an incident, communication is critical. Internal communication ensures staff know what's happening and how to help. External communication (with constituents, donors, regulators) is important for transparency and trust. Document your communication procedures in advance.

Internal communication should address: What happened (in language the team understands)? What systems are affected? How long will the incident take to resolve? What should staff do (keep working, stop using certain systems, follow special procedures)? What's the communication timeline (when will you provide next update)? Frequent communication reduces uncertainty and fear. Designate one person to provide updates so messages are consistent.

External communication depends on the type of incident. For incidents not involving data exposure (ransomware, service outage), you might communicate "We experienced a technical issue affecting [systems]. We're investigating and expect to have service restored by [time]." For incidents involving data exposure, you must notify affected parties. Follow state breach notification law requirements. Be transparent about what happened and what people should do to protect themselves.

Create breach notification templates in advance. If a breach happens, don't write the notification while panicked. Have a template addressing: what information was exposed, when the breach occurred, when it was discovered, what steps the organization is taking, what steps affected people should take (freeze credit, change passwords), contact information for questions, and information about credit monitoring if offered. Have a lawyer review templates to ensure compliance with legal requirements.

Coordination With External Services: When to Call for Help

Most nonprofits don't have incident response expertise in-house. It's worth planning how you'll get external help if you need it. Options include your IT vendor (if you have one), incident response firms, law enforcement, forensic experts, and legal counsel.

Include your IT vendor or service provider in your plan. If you use cloud services or have a managed service provider, clarify what they'll do in case of incident. What response time can you expect? Will they investigate? Will they contact law enforcement? What costs will you incur? Discuss this before an incident so you know what to expect.

Have incident response firm contact information readily available. Incident response firms investigate breaches, collect evidence properly (important for law enforcement involvement), contain incidents, and help with recovery. Getting an expert early minimizes damage. You might not need them for every incident, but for serious breaches, expert help is valuable. Identify potential firms and understand their capabilities and costs.

Involve law enforcement if the incident involves criminal activity. If ransom is demanded (ransomware), if there's financial fraud, or if you've been hacked, contact local FBI field office's cyber division or FBI's Internet Crime Complaint Center. Law enforcement can help, and reporting creates an official record. They also track trends and might have information about attackers.

Involve legal counsel. Breach notification law is complex. Involving counsel early ensures compliance. They also help with external communications to minimize liability and help with any regulatory investigations.

Post-Incident Review: Learning From What Happened

After you've contained an incident and restored systems, conduct a post-incident review. What happened? How did the attacker get in? What could have prevented the incident? What should you change going forward? This review turns an incident into a learning opportunity.

Assign someone to lead the review. Gather everyone involved: IT staff, affected staff, leadership. Without blame or judgment, discuss what happened. What security gaps existed? What policies or practices didn't work? What did work? Document findings and recommendations. Create an action plan to address vulnerabilities discovered.

Common findings from incident reviews are outdated systems, missing security updates, weak password practices, lack of multi-factor authentication, lack of access controls, inadequate monitoring, or lack of incident response preparedness. Use the specific incident to justify fixing these problems. When you improve security based on incidents, you're making your organization genuinely more secure.

Document your post-incident reviews. If you're ever sued or investigated, documentation of what happened and what you learned shows responsible incident response. It demonstrates you took the incident seriously and made good-faith efforts to improve.

Frequently Asked Questions

Should we pay ransomware demands?

Generally no. Paying funds the attackers and encourages more attacks. Most guidance from law enforcement and security experts recommends against payment. Additionally, the ransomware decryption keys you get might not work perfectly. Your best defense is regular backups so you can restore from backup without paying. If you do consider paying, consult law enforcement and a lawyer first. Some ransomware payments violate sanctions laws. Don't pay without expert consultation.

How do we know if we've been breached?

Signs include: suspicious login activity, data access alerts, unusual system behavior, ransom notes, complaints from donors about suspicious activity on their accounts, notice from law enforcement or regulatory agencies, or reports from security researchers that your data appeared on darknet marketplaces. Additionally, dark web monitoring services can alert you if your data appears being sold. Set up monitoring and train staff to recognize signs of incidents. The sooner you detect an incident, the sooner you can respond.

Who should have access to our incident response plan?

Everyone on the incident response team should have access. Additionally, your board might have one copy and your lawyer might have one for reference. Don't publicize it widely—you don't want attackers knowing your response procedures. But people who need to execute the plan need access. Store it somewhere accessible even if email and normal systems are down. Consider a printed copy in a secure location.

How often should we test our incident response plan?

Test it at least annually, ideally more frequently. Assign someone to run a tabletop exercise where the team walks through responding to a hypothetical incident. Does everyone know their role? Are contact numbers current? Does the plan make sense in practice? Testing identifies problems before a real incident happens. It's much better to discover that your backup phone number is outdated during a test than during an actual breach.