Having Backups Is Not the Same as Being Resilient

A nonprofit can have successful backups every night, store most of its data in the cloud, and still be poorly prepared for a serious technology outage.

That is the distinction executives should care about.

Human-services and behavioral-health organizations do not exist to keep servers online. They exist to support people. When technology fails, the meaningful question is not whether last night’s backup completed or whether a vendor says the application is hosted in the cloud.

That is the difference between having backups and being resilient.

Start with the service, not the backup report

A backup report is written in technical terms. A human-services organization operates in program terms.

A residential program needs staff to communicate, document services, and reach the information required to support people safely. A behavioral-health clinic needs clinicians to see schedules, reach the records they are authorized to use, and document care. Community-based staff may depend on mobile access, Microsoft 365, case-management systems, phones, and identity services while working away from a central office.

The technology matters because the service depends on it. The technology is not the outcome.

If the case-management database is restored but staff cannot sign in, the service is not recovered. If the clinical application is online but the site cannot reach it, the service is not recovered. If the system is available but staff do not know the approved downtime or recovery process, the organization is still improvising.

A technically successful restore can still leave a program unable to work.

Cloud-hosted does not automatically mean recoverable

This is where another common assumption enters the conversation.

• “Our files are in OneDrive.”
• “Our EVV is hosted by the vendor.”
• “Our EHR is cloud-based, so the provider handles the backup.”

Those arrangements can absolutely reduce risk. Cloud platforms may provide redundant infrastructure, version history, deleted-file recovery, ransomware recovery features, or provider-managed backups.

But cloud storage and vendor-hosted software do not answer the recovery question by themselves.

Microsoft’s own ransomware recovery guidance, for example, tells OneDrive users to clean infected devices before restoring files so restored data is not encrypted again. CISA recommends that organizations using cloud services understand the shared-responsibility model, back up cloud data where appropriate, and evaluate the backup and recovery options offered by SaaS providers.

For an executive, the issue is simpler than the technology behind it:

• What exactly can the vendor restore?
• How far back can it restore?
• How long should recovery take?
• What happens if the provider itself is unavailable?
• What does the program do while the service is down?

Where the data lives matters. Whether the organization can recover the service matters more.

Not every program can tolerate the same outage

Once recovery is framed around services, executives can make a more useful decision: which services can tolerate disruption and for how long?

A central administrative office may be able to work around an application outage for several hours. A residential program, crisis service, behavioral-health clinic, or another time-sensitive operation may not have the same flexibility.

That difference matters in organizations with 24-hour services, multiple locations, shared workstations, mobile employees, and limited technical staff available after normal business hours.

A single recovery target for “the network” or “the servers” does not capture those realities.

The result is not a technical priority list. It is an organizational recovery order.

Critical services are chains

Once the organization knows what has to return first, the next question is what each service depends on.

A behavioral-health application may depend on identity, internet connectivity, a database, licensing, cloud services, and integrations. A shared workstation may depend on the device, the site network, identity services, multifactor authentication, and the employee’s account before the application itself even matters.

If a required link is unavailable, restoring the final database may not restore the service.

CISA recommends identifying critical systems and their interdependencies before an incident so restoration priorities are understood before the organization is operating under pressure.

This is what turns a list of backups into a recovery plan.

A recovery test should prove that staff can work

The next step is to test recovery at the same level.

Restoring a file proves the file can be recovered. Starting a server proves the server can start. Neither proves that a program can operate.

For a behavioral-health clinic, a meaningful test asks whether clinicians can authenticate, see the right schedules and records, and reach the application from the place where care is delivered.

For a residential or community program, it may mean confirming that shared workstations, identity, connectivity, documentation systems, and communications work together.

HHS contingency-planning guidance makes a similar distinction for organizations subject to HIPAA. Data backup is one component. Disaster recovery, emergency operations, criticality analysis, and testing are also part of the planning model.

The broader lesson is straightforward: the organization needs evidence that recovery works, not just evidence that backups ran.

Resilience includes the hours before recovery is complete

Even a good recovery process takes time.

During that time, staff still need direction and programs still need a safe way to operate.

That may mean temporary documentation procedures, alternate communications, defined escalation paths, accessible contact information, or other downtime processes appropriate to the service.

The goal is not to recreate every system manually. It is to know the minimum capabilities the organization needs to keep essential work moving without forcing staff to invent workarounds during an incident.

For executives, this is where technology resilience becomes operational resilience. An outage can quickly become staff downtime, documentation backlog, delayed billing, overtime, missed handoffs, or program disruption if the organization has not decided what happens while systems are unavailable.

The questions executives should be asking

You do not need to administer backup software to evaluate whether the organization is prepared.

1. Which programs have the least tolerance for downtime?
2. What technology and vendors does each critical service depend on?
3. For cloud and SaaS systems, what recovery capability are we actually buying?
4. What comes back first, and what has to be restored before it?
5. When did actual staff last test a full service recovery?
6. What is the approved process while a critical system is unavailable?
7. What evidence can our IT provider show that recovery actually works?

If the answers are mostly product names, backup status screens, or assumptions about what a cloud vendor will do, the organization may have backup coverage without having a recovery capability.

Having backups is not the same as being resilient

Backups answer whether recoverable copies exist. Cloud platforms and SaaS providers may add important protection and recovery features.

Resilience answers the larger operational question: can the organization keep essential services moving when technology fails, and can it return those services to normal operation in a deliberate, tested order?

For nonprofit human-services and behavioral-health organizations, the consequences of downtime do not stop with IT. They reach staff, clinicians, supervisors, finance teams, documentation, communications, billing, and ultimately the people the organization exists to support.

Sources

• Microsoft Support, How to detect ransomware and recover files using OneDrive
• CISA, #StopRansomware Guide
• HHS, Ransomware and HIPAA fact sheet