A Disaster Recovery Plan Should Tell You How Work Gets Back Up and Running
Imagine your team starts the day and suddenly cannot access Microsoft 365, shared files, or another system people rely on to do their work. The first question is usually not technical. It is practical: what do we need to get running first, and who is responsible for making that happen?
That is what a useful disaster recovery plan should answer.
For a charity, disaster recovery is not just about keeping backups somewhere. It is about having a clear way to restore the systems and information the organization depends on after an outage, cyber incident, equipment failure, or other disruption. It sits alongside broader continuity planning, but its focus is narrower: getting technology and data back into a usable state.
The plan should be specific enough that staff and your IT provider are not figuring out the recovery process for the first time while systems are already unavailable. That means knowing which systems matter most, how quickly they need to return, where recoverable copies of important data exist, and who is expected to take each step.
Those expectations are also part of the bigger picture when evaluating managed IT support for a charity. Disaster recovery works much better when the organization and its provider already agree on what needs to happen before something goes wrong.
Start With What Your Charity Actually Needs to Recover
A disaster recovery plan becomes much more useful once it reflects how your charity actually works. Instead of starting with every piece of technology you own, start with the systems people depend on to keep the organization moving.
That might include Microsoft 365 or Google Workspace, shared files, accounting and payroll, your donor or fundraising system, a case-management platform, your website, or other tools tied closely to programs and administration. The exact list will vary from one organization to another, which is why a generic recovery checklist is rarely enough.
The next step is deciding what needs to come back first. Not every system has the same urgency. If staff cannot sign in to Microsoft 365, access shared documents, or reach the system used for payroll, the impact is likely to be immediate. An old archive or a rarely used internal tool may be able to wait.
This is where the plan should connect technology to actual operations. Ask what work stops when a system is unavailable, who depends on it, and whether there is a temporary workaround. That gives you a practical recovery order instead of treating every application as equally important.
It can also uncover dependencies that are easy to miss. A fundraising system may technically be online, for example, but staff still cannot use it if their email accounts, authentication tools, or shared files are unavailable. A good recovery plan looks at those connections so the order of restoration makes sense in the real world.
Define How Quickly You Need Things Back and How Much You Can Afford to Lose
Once you know which systems matter most, the next question is how quickly each one needs to be available again.
Two terms often come up here: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). The language sounds technical, but the ideas are straightforward.
RTO is about time. How long can your charity reasonably operate without a particular system?
RPO is about data. If you had to restore from a backup, how much recent information could you afford to lose?
Those answers will not be the same for every system. During a fundraising campaign, for example, losing several days of recently updated donation records could create a lot of reconciliation work. An old archive that rarely changes may be much less urgent.
The goal is not to set the fastest possible recovery target for everything. Faster recovery usually requires more planning, more capable backup systems, and sometimes more cost. What matters is choosing targets that match the real impact of being without that system.
This is also where vague expectations become clearer. Saying “we need our files back quickly” is hard to plan around. Saying “staff need access to current shared files within four hours, and we should not lose more than one business day of changes” gives your team and IT provider something concrete to work toward.
Backups Need Their Own Recovery Instructions
Having backups is important, but a disaster recovery plan should go further than simply confirming that they exist. It should explain what is backed up, where those copies are kept, who can restore them, and how recovery would actually happen.
For a charity, that may include shared files, Microsoft 365 or Google Workspace data, accounting information, databases, website data, and any other systems the organization cannot easily recreate. The plan should also note how often backups run and how long copies are kept where that matters.
Just as important, backup access should be limited. If the same accounts that manage everyday systems can also delete or alter every backup copy, a single compromised account can create a much bigger recovery problem. Depending on the system, keeping protected or isolated copies can make recovery more reliable.
Cloud services can also create a false sense of certainty. Using Microsoft 365, Google Workspace, or another hosted platform does not automatically mean every file, email, or application can be restored in the way your charity expects. Retention, version history, vendor recovery options, and any separate backup service should be understood before an incident happens.
The most useful test is simple: could someone actually restore the information if they needed it? Periodically restoring a sample of files or data confirms that backups are not just being created, but are usable when recovery is required.
Write Down Who Does What When Something Goes Wrong
A recovery plan can be technically sound and still fall apart if nobody is clear on who is supposed to act. For charities with a small internal team, that matters even more because responsibility is often shared between staff, leadership, outside vendors, and an IT provider.
The plan should name who is responsible for the key decisions and actions. That includes who decides the recovery plan should be activated, who contacts the IT provider, who can authorize a restore, who communicates with staff, and who reaches out to important software vendors if a third-party platform is affected.
It is also worth identifying who has access to emergency administrator accounts and other credentials needed for recovery. Those details should not depend on one person being available. If the only person who can approve access or find a critical password is away, the recovery process can stall even when the technology itself is ready to be restored.
Contact information and recovery instructions should also be available somewhere outside the systems they are meant to recover. If your emergency contacts, vendor details, and recovery steps live only in a shared drive that is currently unavailable, they are not very useful in the moment.
The goal is not to create a complicated chain of command. It is to make sure everyone involved knows their part, and that the organization can still reach the right people and information when its normal systems are not available.
Make Sure Your IT Provider's Responsibilities Match the Plan
A recovery plan can look complete on paper and still leave an important gap if your charity and its IT provider are making different assumptions about who is responsible for what.
For example, your team may assume backups are being monitored because the provider manages your Microsoft 365 environment. The provider may only be responsible for user support and account administration. You may expect recovery testing to happen regularly, while the contract only covers restores when someone specifically requests one.
Those differences are easier to deal with before an incident. Your plan should make clear who is responsible for backup management, monitoring failed backups, restoring data, testing recovery procedures, contacting third-party vendors, and supporting the organization during a serious outage.
This is also where the service agreement matters. If disaster recovery is important to your charity, the responsibilities in the plan should line up with what the provider has actually committed to deliver. That is one reason IT contract red flags are worth looking at closely before you sign: vague wording around backups, recovery, response expectations, or third-party systems can leave too much open to interpretation.
The goal is not to make the contract unnecessarily complicated. It is to make sure the recovery plan reflects the support your charity will actually receive, rather than the support everyone assumes is included.
A Plan You Have Never Tested Is Still an Assumption
A disaster recovery plan should not depend on everything working exactly as expected the first time it is needed. Testing is how you find out whether the plan actually works.
That does not mean your charity needs to shut down systems and run a full-scale disaster exercise every few months. Smaller, focused tests can still reveal useful gaps. You might restore a sample set of files, confirm that emergency contacts are current, walk through what would happen during a Microsoft 365 outage, or check that the right people can access the credentials needed for recovery.
A simple tabletop exercise can also be valuable. Pick a realistic scenario, such as losing access to shared files for a day, and work through what everyone would do. Who notices the issue first? Who contacts IT? Which systems come back first? How do staff continue working in the meantime? Where does leadership get updates?
These exercises often uncover ordinary problems rather than dramatic ones: an old phone number, a former employee still listed as a contact, a backup that takes much longer to restore than expected, or a system that turns out to be more important than anyone realized.
The plan should also be reviewed whenever something significant changes, such as moving to a new platform, changing IT providers, adding a major system, or restructuring staff responsibilities. A recovery plan is useful when it reflects the charity you are running now, not the organization you had two years ago.
A Good Recovery Plan Makes the Next Step Clear
A disaster recovery plan is useful when it turns a difficult situation into a series of clear, manageable steps. Your team should know what needs to be restored first, how recovery will happen, who is responsible, and what support is available when normal systems are not.
That kind of clarity also makes technology easier to manage day to day. When systems, responsibilities, backups, and provider expectations are understood before something goes wrong, recovery becomes part of responsible IT management rather than something the organization has to figure out under pressure.
