Nonprofit Recovery Readiness: A Board Checklist

Nonprofit recovery readiness means knowing which services must resume, who can authorize their return, and what evidence shows they are usable and trustworthy. A successful backup job answers only part of that question. Leaders also need access, staff availability, vendor coordination, communication channels, and a controlled way to reconcile work completed during an outage.

This is a governance guide for executive directors, finance leaders, and trustees. It is not a technical restoration manual. The aim is to help a nonprofit test whether its recovery promises survive realistic constraints without exposing live information or disrupting services.

NIST’s Guide for Cybersecurity Event Recovery emphasizes resource prioritization, realistic tests, playbooks, and continuous improvement. The publication dates to 2016; it remains a useful planning reference, not evidence of a newly reported incident. NIST, SP 800-184

Educational disclaimer: These are defensive planning recommendations, not individualized incident-response, legal, insurance, or business-continuity advice. Targets and examples are illustrative, not mandatory standards or guarantees. Use qualified advisers to design safe tests and determine applicable obligations. Sources were accessed October 26, 2026.

Define nonprofit recovery readiness around the mission

Start with essential services rather than a list of applications. Ask what people depend on the nonprofit to deliver: meals, shelter referrals, appointments, payroll, donor acknowledgments, or reporting to a funder. Describe the consequence of each service being unavailable.

A system can be operational while the service is still interrupted. Staff may lack a working login, a required integration may remain down, or yesterday’s appointments may not be present. Recovery should therefore be accepted by the service owner, not declared solely from a technical dashboard.

NIST’s Cybersecurity Framework 2.0 is designed for organizations of any size, sector, or maturity and describes outcomes rather than prescribing one implementation. Use that framing to connect technology decisions with mission priorities and management accountability. Do not claim that following a checklist certifies the organization. NIST, CSF 2.0

Agree on tolerances in plain language

For each essential service, ask two separate questions: how long can it be unavailable, and how much recent work could need to be reconstructed? These discussions inform recovery time and recovery point objectives, respectively. They are planning targets, not a provider’s automatic promise.

A short interruption might be acceptable for an archive but unacceptable for an appointment roster needed that morning. Similarly, losing a recent copy of a generic brochure differs from needing to reconstruct a day of payment records. Choose targets based on consequences and validate whether available resources can support them.

If the target is unrealistic, disclose the gap. Management may need a different workflow, vendor commitment, additional resources, or a consciously accepted limitation. An ambitious number written in a plan is not readiness evidence.

Map dependencies before asking about backups

For each essential service, identify the applications, identities, devices, people, vendors, and reference information it needs. Include less visible dependencies such as multifactor authentication enrollment, access to support contacts, subscription administration, and the ability to approve a payment.

A recovery contact list stored only in an unavailable email account is not usable during that outage. Keep appropriately protected offline copies of the basic plan and relevant contact information. Avoid turning an offline plan into an uncontrolled list of passwords or sensitive personal records.

CISA’s StopRansomware Guide recommends maintaining and exercising incident-response and communications plans, including hard-copy and offline availability. It also recommends offline, encrypted backups of critical data and regular testing of backup availability and integrity. Those recommendations support a layered recovery discussion, not a conclusion that one backup arrangement fits every nonprofit. CISA, StopRansomware Guide

A practical dependency table can expose hidden gaps:

Essential service	Dependency to confirm	Evidence of readiness
Client appointment coordination	Staff access and current schedule	Authorized user completes a safe test workflow
Payroll preparation	Provider availability and approval roles	Backup approver and escalation route verified
Donation acknowledgment	Donor records and communication tools	Sample records and templates checked
Financial reporting	Ledger, supporting documents, and review	Totals and representative records reconciled
Incident communication	Independent contact route	Management can reach the designated team

The test should verify the service, not merely show that a file exists. A readable exported document may still omit attachments, history, permissions, or information necessary to continue the actual workflow.

Separate recovery access from everyday availability

Ask who can initiate a recovery when the usual administrator is absent. Identify an authorized alternate and document how that person obtains assistance and proves authority. Check that the arrangement is compatible with the vendor’s real account-recovery process.

Review access dependencies with qualified technical support. If the organization’s main identity service is unavailable, can the authorized team reach the recovery resources it needs? If a former employee remains the only subscription administrator, the plan already has an operational weakness.

Emergency access deserves controlled use. Establish approval, logging, protection, and a process for reviewing or revoking temporary privileges afterward. Do not create casually shared credentials in the name of preparedness.

Likewise, ask where backup encryption keys or other required recovery material are managed and which authorized roles can access them. Management need not handle technical secrets directly, but it needs credible evidence that recovery does not depend on one person’s memory.

Test more than the backup status message

CISA explicitly recommends testing backup procedures and the availability and integrity of backups in disaster-recovery scenarios. That is a stronger standard of evidence than accepting a green job-status indicator. CISA, StopRansomware Guide

Arrange a safe, scoped exercise with the provider or qualified support team. Use nonproduction environments and minimized or synthetic information wherever feasible. Agree on authorization, boundaries, stop conditions, and how any sensitive test material will be protected and removed afterward.

Ask the service owner to check representative work. Can an authorized staff member locate a record, understand its history, and complete the expected task? Do permissions still match roles? Are required documents present? Is the recovered information recent enough for the agreed tolerance?

Record elapsed time, missing dependencies, required assistance, and the difference between the expected and actual result. NIST’s recovery guide specifically includes testing, improvement, and informative metrics as part of recovery planning. Use the exercise to discover limitations, not stage a demonstration that cannot fail. NIST, SP 800-184

Keep tabletop and restoration tests distinct

A tabletop exercise checks decisions through discussion. It can reveal who declares an incident, who contacts the insurer, and how management communicates while normal channels are unavailable. It does not prove that data can actually be restored.

A restoration exercise checks technical and operational usability. It does not, by itself, prove that leaders can coordinate a real incident. Plan both forms of evidence, with an exercise frequency chosen for the nonprofit’s risks, change rate, and resources rather than an invented universal requirement.

Clarify what each vendor is responsible for

A provider’s infrastructure recovery and the nonprofit’s business recovery are not identical. Ask what is included in the contract, what the provider tests, and what the customer must do. Distinguish service availability from data export, historical recovery, and reinstating access.

Useful questions include:

• Which recovery commitments apply to the purchased service tier?
• What information can be restored, and what might be excluded?
• Who may request restoration or access recovery?
• What support route works outside normal business hours?
• What evidence is available from recent recovery exercises?
• What happens if an integration or another provider remains unavailable?
• How are recovery charges, account closure, and export limitations handled?

Keep answers and unresolved questions in a vendor register. Where a commitment matters to an essential service, seek appropriate written confirmation rather than relying on a salesperson’s general reassurance.

Do not assume that an advertised backup means the nonprofit can retrieve any historical version on demand. Test the specific capability needed. If the provider cannot support it, make the limitation visible to the service owner and board.

Plan a controlled period of reduced service

Some essential work may need to continue before all systems return. Agree on the minimum acceptable workflow and who authorizes it. Preserve privacy and normal approval boundaries as far as possible; an outage should not become a reason for unrestricted spreadsheets or unreviewed payments.

Define how temporary records are identified, protected, reconciled, and transferred into the authoritative system. Assign responsibility for detecting duplicate entries, missing actions, and inaccurate summaries. Record what could not be completed rather than presenting partial operations as full service.

Use the financial statements guide as context for understanding why restored totals still need review. A ledger that opens is not the same as a reconciled financial position. Recovery planning should also connect to the reports your nonprofit board should receive, including unresolved operational and reporting limitations.

Hypothetical example: access fails before payroll approval

An illustrative community organization loses access to its main identity service the day before payroll approval. The payroll provider is available, but the usual approver cannot sign in. No actual incident is being described.

The team activates its documented escalation route. The authorized alternate works with the provider through its established process, while management determines which deadline risks require attention. Staff do not share passwords or quietly redefine who may approve payments.

The exercise reveals that the alternate’s authority had never been confirmed with the provider. Management assigns an owner and deadline to correct the arrangement, then repeats the relevant test. That failure is useful: it exposed a dependency that a backup report could never identify.

Define who can declare recovery complete

After a suspected security incident, restoration and safe return are separate decisions. Qualified responders should advise on containment and the trustworthiness of the environment. Business owners should confirm usable services and reconciled information. Counsel and other advisers should address notification and preservation obligations as appropriate.

Do not assume that restoring files settles possible confidentiality impacts. CISA’s guide explains that ransomware incidents can also involve data theft and extortion. Recovering availability does not establish whether information was disclosed or what legal response is required. CISA, StopRansomware Guide

Document the acceptance criteria, decision-maker, remaining restrictions, and follow-up work. Communications should distinguish verified facts from unresolved questions. Avoid declaring “everything is secure” when the team has only confirmed that an application is running.

Give trustees a recovery evidence checklist

A useful board review asks for evidence against these questions:

• Have essential services and acceptable disruption targets been approved?
• Are dependencies and alternate responsible people documented?
• Can the recovery team reach its plan without normal email access?
• Have safe restoration and decision-making exercises been completed?
• Are provider responsibilities and exclusions understood?
• Is temporary work reconciled before normal reporting resumes?
• Are failed tests assigned owners, deadlines, and retests?

Summarize the last exercise, what did not work, and what remains outside tolerance. If an issue requires funding or a service change, present the decision explicitly. Recovery readiness is an ongoing management capability: make it measurable enough that the board can distinguish a reassuring promise from a tested plan.

Sources

• National Institute of Standards and Technology: Guide for Cybersecurity Event Recovery, SP 800-184, December 22, 2016. Accessed October 26, 2026. Used for durable recovery-planning principles, not current incident statistics.
• Cybersecurity and Infrastructure Security Agency: StopRansomware Guide, including preparation, backup testing, and response-planning recommendations; the retrieved page links the September 2023 guide. Accessed October 26, 2026.
• National Institute of Standards and Technology: The NIST Cybersecurity Framework (CSF) 2.0, February 26, 2024. Accessed October 26, 2026. Guidance does not establish a certification or a recovery guarantee.