Operational Resilience Is an Operating Model, Not an IT Checklist

A human-services organization can have a backup plan, an incident-response plan, a continuity plan, a privacy policy, and several vendor contracts, then discover during an outage that none of them tells people how to work together.

The gap appears in the handoffs. Technology staff may isolate a system without knowing which program cannot tolerate the interruption. Program staff may improvise a workaround without knowing how sensitive information should be handled. A vendor may restore an application before identity or network access is trusted. An executive may hear that a system is online before staff can complete the work the service requires.

Operational resilience is not a collection of plans. It is one operating model for the decisions made across the entire disruption.

The first article in this series explained why service-level backup and recovery matters. The second established why containment must support recovery. The complete model connects those ideas through five decisions.

1. 01Prioritize
2. 02Contain
3. 03Continue
4. 04Restore
5. 05Prove

Prioritize the service before prioritizing the technology

The first decision is not which server or application is most important. It is which service the organization must keep providing and what minimum capability that service requires.

A residential program, behavioral-health clinic, day habilitation service, care-management operation, finance office, and administrative team may all depend on technology. They do not have the same tolerance for disruption.

Each essential service needs a defined operational priority, maximum workable downtime, minimum safe workflow, and dependency chain. That chain may include staff, locations, devices, identity, connectivity, applications, data, and vendors.

This changes the recovery order. A clinical application does not help if staff cannot authenticate. A restored case-management database does not restore a program if the site cannot connect to it. Payroll is not recovered if timekeeping, banking access, or approvals remain unavailable.

Service priority gives the CEO, COO, program executives, finance team, and technology resources a shared basis for deciding where limited time and outside support should go first.

Contain enough of the incident to reestablish trust

The second decision is whether the organization has contained the incident enough to begin a phased restoration.

Containment may require disabling accounts, revoking sessions, isolating devices, restricting vendor access, separating locations, or taking a critical application offline. Those actions can protect the organization and interrupt program operations at the same time.

That is why authority matters. The person coordinating the technical response needs to know which actions can be taken immediately and which require executive approval. Program executives need to know when a service must shift to downtime procedures. Outside providers need defined escalation contacts and permission boundaries.

NIST recommends synchronizing business-continuity and incident-response plans because cyber incidents can undermine business resilience. It also says recovery criteria should be applied to the known and assumed characteristics of the incident when deciding when recovery begins.

Source: NIST SP 800-61 Revision 3, published April 2025.

Containment therefore cannot be a technical side process. It is the operating decision that establishes whether identities, devices, administrative tools, backups, network paths, and vendor connections are trustworthy enough for the next service to return.

Continue essential work without creating a second incident

Recovery takes time. Programs still need an approved way to operate while normal systems are unavailable.

This is where a technology outage can become a second privacy, confidentiality, documentation, or service incident. Under pressure, staff may turn to personal email, text messages, unapproved spreadsheets, consumer file-sharing tools, photographs, or paper notes that the organization cannot control, reconcile, retain, or securely destroy.

The intent is often reasonable. Staff are trying to keep services moving. The risk comes from asking them to improvise without an approved path.

For HIPAA regulated organizations, the Security Rule requires contingency procedures for backing up electronic protected health information, restoring lost data, and continuing critical business processes while protecting that information in emergency mode. The rule also requires security-incident procedures and appropriate access, integrity, authentication, and transmission safeguards.

Source: HHS Summary of the HIPAA Security Rule, last reviewed August 7, 2026.

Organizations that handle substance-use disorder records may also be subject to 42 CFR Part 2. HHS states that compliance with the 2024 Part 2 Final Rule was required by February 16, 2026, and that Part 2 programs must report breaches of unsecured Part 2 records. The exact obligations depend on the organization and the records involved.

Source: HHS Part 2 Overview, last reviewed February 13, 2026.

The operating principle is broader than any one rule: downtime does not suspend the responsibility to protect sensitive information.

An approved downtime process should tell staff what minimum information to collect, which forms or channels to use, how temporary records are secured, how access is limited, how the records are reconciled with the official system, and who can authorize an exception. Those choices must be supplied and practiced before the outage.

Restore services in dependency order with vendors inside the plan

Once the incident is contained enough and essential work has a safe temporary path, restoration should follow service priorities and dependencies.

The application visible to staff may sit at the end of a longer chain. Identity, internet access, network segmentation, trusted devices, licensing, data, integrations, and vendor services may all need to function first.

Bringing the final application online before those dependencies are trusted can create a technically available system that staff still cannot use safely.

Vendors must be part of this order. For each critical provider, the organization should know the emergency contact, escalation path, isolation and restoration capabilities, evidence the provider can supply, actions the organization must complete first, and the fallback if the provider is unavailable.

A contract is not the same as an operating plan. The organization still needs named contacts, tested escalation paths, current exports or recovery options where appropriate, and a clear boundary between what the vendor will do and what the organization must do.

NIST’s current recovery guidance calls for selecting and prioritizing recovery actions, verifying restoration assets before use, restoring essential services in the appropriate order, working with responsible staff to confirm successful restoration, and monitoring restored systems to verify that recovery was adequate.

Source: NIST SP 800-61 Revision 3.

Prove the service works, then improve the operating model

A dashboard turning green does not prove that a service has recovered.

The service is recovered when authorized staff can complete the work the program depends on, the information is accurate, the necessary connections are trusted, temporary records have been reconciled, and monitoring shows no sign that the incident has resumed.

That proof should include technical validation and confirmation from actual staff. It should also preserve the decisions made, actions taken, delays encountered, vendor performance, unresolved risk, and changes assigned after the incident or exercise.

Testing does not need to begin with a full organizational disaster exercise. A human-services organization can test one essential service at a time. Remove access to a dependency, activate the downtime process, restore the service, reconcile the temporary records, and record what failed.

That test connects all five decisions. It shows whether the service priority is correct, containment authority is clear, downtime work is safe, dependencies and vendors are understood, and recovery can be proved.

Resilience is the agreement that holds the plans together

“Our backups are successful” is not a complete resilience statement.

A stronger answer is: We know which services must continue, who can contain the incident, how staff work safely during downtime, what must be trusted before restoration, what returns first, which vendors must act, and what evidence proves the service works.

That answer does not come from a single product or binder. It comes from an agreement among the executives, program staff, technology resources, privacy and compliance resources, finance staff, communications resources, and vendors who will make decisions during the disruption.

For nonprofit human-services and behavioral-health organizations, operational resilience is the ability to keep essential services moving safely while an incident is contained, restore the supporting technology in a trusted order, and prove that the service works afterward.

That is the operating model behind the entire series.

Sources

• NIST, SP 800-61 Revision 3, Incident Response Recommendations and Considerations
• HHS, Summary of the HIPAA Security Rule
• HHS, Part 2 Overview