A staff member opens the shared drive and finds donation records, grant files, and volunteer schedules renamed with a ransom note. The next few hours can feel chaotic, especially when your organization still has clients to serve and a board asking for answers. Nonprofit ransomware recovery is not just an IT task. It is a leadership decision process that protects people, services, donor trust, and the mission your team is working hard to advance.
The goal in the first 72 hours is not to get every computer back online as fast as possible. It is to stop the attack, understand what happened, restore only clean systems and data, and communicate with care. Moving too quickly can turn a contained incident into a longer outage.
Nonprofit ransomware recovery starts with containment
If ransomware is suspected, disconnect affected computers from the network immediately. Unplug the network cable, turn off Wi-Fi if possible, and separate the device from shared printers, file servers, and cloud-syncing folders. Do not let staff keep working on an infected computer just because they need one more document.
Do not wipe the device or start deleting files. Those actions can destroy evidence that helps determine how the attack started and whether data was taken before encryption began. Avoid repeatedly rebooting affected systems as well. Depending on the ransomware strain, a restart may interfere with forensic review or make recovery harder.
Your first response should focus on five actions:
- Isolate affected computers, servers, and network segments.
- Contact your managed IT provider or incident response team right away.
- Preserve screenshots of ransom notes, suspicious emails, and error messages.
- Disable compromised accounts and reset credentials from a known-clean device.
- Pause automated backup jobs if there is a risk they are copying encrypted files over good backup versions.
This is also the time to protect systems that may not yet show obvious signs of trouble. File shares, Microsoft 365 or Google Workspace accounts, backup consoles, remote-access tools, and domain administrator accounts deserve immediate attention. Ransomware actors often move through a network before they encrypt anything.
Keep the mission moving, safely
A nonprofit may need to continue intake, deliver services, process payroll, or communicate with donors while systems are down. Create a temporary manual process for the essentials. That may mean paper intake forms, a dedicated clean laptop for leadership, or a phone tree for staff and volunteers.
Be disciplined about what gets connected to the network during this period. A personal laptop, an old office computer, or a flash drive can reintroduce the threat if it is not checked first. Temporary workarounds should reduce operational pressure, not create another path into the environment.
Assess what was encrypted, accessed, or exposed
Encryption is visible. Data theft is not always visible. Many ransomware groups now copy files before locking systems and threaten to release donor information, employee records, client documents, or financial data if the organization does not pay.
Your IT team should establish a timeline: when the attacker first gained access, which accounts were used, what systems were reached, and whether data was transferred outside the network. Email logs, firewall records, endpoint security alerts, cloud audit logs, and backup-console activity all help tell that story.
The scope matters because recovery requirements vary. A nonprofit with only a few encrypted workstations may be able to restore quickly after confirming the threat is gone. An organization that stores health information, case notes, payment data, or personally identifiable information may need legal, insurance, and compliance guidance before it can accurately notify affected people.
Do not assume that an intact cloud account is safe simply because it still opens. Attackers may have created inbox rules, added forwarding addresses, registered unauthorized multifactor authentication methods, or downloaded files from shared storage. Cloud identity review should be part of the incident response, not an afterthought.
Restore from clean backups, not hope
Backups are the center of nonprofit ransomware recovery, but only if they are usable. A backup that has never been tested is a promise, not a recovery plan.
Before restoration begins, verify the backup date, confirm that the backup was created before the compromise, and scan restored data in an isolated environment. Check for more than the presence of files. Can staff open the donor database? Are permission settings intact? Does the accounting system reconcile correctly? Is the database application compatible with the restored server?
The recovery order should follow the organization’s real-world priorities. For one nonprofit, that may be client scheduling and case management. For another, it may be payroll, donor records, grant reporting, or the systems used to coordinate food distribution. Leadership should make those priorities clear so technical work supports the mission instead of restoring systems based only on convenience.
There is a trade-off between speed and certainty. Restoring a workstation image from last night can be fast, but it may bring back the same compromised configuration if the original entry point has not been fixed. Rebuilding critical systems from a clean baseline takes longer, yet it is often the safer route after a serious breach.
Paying a ransom is also a difficult decision, not a recovery strategy. Payment does not guarantee a working decryption key, deletion of stolen data, or protection from another demand. It can also create legal and insurance complications. Work with legal counsel, your cyber insurance carrier, and qualified incident response professionals before making any decision under pressure.
Communicate early without guessing
Silence creates uncertainty, but premature statements can create confusion. Start with a small incident team that includes executive leadership, IT, operations, and, when needed, legal counsel and insurance contacts. Decide who is authorized to communicate with staff, the board, clients, donors, vendors, and the public.
Your first internal message can be simple: the organization is investigating a technology security incident, affected systems are being secured, staff should not connect unknown devices or open suspicious messages, and updates will come through a designated channel. Give employees a practical way to report anything unusual.
For external audiences, communicate facts you can support. If there is no evidence yet that donor data was accessed, do not promise that it was not. If services are temporarily affected, explain what people should do instead and when they can expect another update. Clear, calm communication protects trust better than overly technical language or false certainty.
If notification obligations apply, timing and wording can be regulated. Medical, financial, and client-service organizations may have specific breach-reporting requirements. A local IT partner can help document the technical facts, but attorneys and compliance professionals should guide legal notifications.
Rebuild the environment that allowed the attack
Getting files back is only one part of recovery. The other part is closing the gap that made the incident possible. Common entry points include phishing emails, stolen passwords, unpatched remote access tools, outdated servers, weak administrator controls, and unmanaged personal devices.
Start by resetting credentials, especially for administrator, finance, and email accounts. Require multifactor authentication everywhere it is available. Review user access so staff and volunteers have only the permissions needed for their roles. Segment the network so one infected device cannot freely reach every server, camera, printer, and file share.
Endpoint protection, patch management, monitored backups, and email filtering work best as a coordinated system. None is perfect by itself. A small nonprofit may not need enterprise-scale complexity, but it does need layers that are practical to manage and regularly reviewed.
This is where a local managed IT relationship can make a meaningful difference. Benconnected helps Treasure Valley organizations assess the full environment, not just repair the computer that displayed the ransom note. A thorough review can identify aging systems, backup gaps, risky accounts, and overlooked network access before they become the next emergency.
Practice recovery before an attacker forces the test
The best time to find out whether a backup restores is not after a grant database is unavailable. Schedule recovery tests at least annually, and more often for systems that change frequently or support daily client services. Include a realistic scenario: a compromised email account, encrypted file share, unavailable cloud drive, or lost server.
A useful exercise answers practical questions. Who has authority to shut down systems? Where are emergency contacts stored if email is unavailable? Which vendor needs to be called first? How long can each department operate manually? What information must be documented for insurance?
Keep the plan short enough that people will use it. Store a printed copy of critical contacts and recovery steps somewhere accessible. Train staff to report suspicious messages without embarrassment. The person who pauses before clicking may protect far more than a single inbox.
When the pressure is on, your nonprofit deserves more than a vague backup promise or a distant call center. It deserves a recovery plan built around the people who depend on your services, tested before the next urgent call comes in.