Cybersecurity and Operational Resilience
You Cannot Recover While the Incident Is Still Spreading
A working backup can restore data. It cannot tell an organization whether compromised accounts, devices, remote sessions, or vendor connections are safe enough to reconnect.
By Leetroy Fraser | Bitralynx SolutionsPublished
After ransomware disrupts scheduling, case notes, email, shared files, or a program application, the pressure to restore service starts immediately. That pressure is understandable. Staff still need to support people, document services, process payroll, coordinate care, and keep programs moving.
But restoration is not the first recovery decision. The first decision is whether the organization has contained the incident enough to restore without giving the attacker another path into the environment.
Backups answer what can be restored. Containment determines whether it is safe enough to restore.
The previous Bitralynx Solutions article, Having Backups Is Not the Same as Being Resilient, established that recovery must work at the service level, not only at the file or server level. This article addresses the gate that comes before that service can return: what must be true before the organization reconnects it?
A clean backup can still return an attacker to production
A backup may contain a usable copy of data and still be only one safe component inside an unsafe environment.
The attacker may retain an employee or administrator account. A cloud session may still be active. A remote-management tool or vendor connection may provide continued access. Another device or location may remain compromised. The selected backup may also contain malicious code or may have been created after the original intrusion.
This is why restoring a file is not the same as restoring trust.
The National Institute of Standards and Technology defines containment as preventing an incident from expanding. Its current incident-response guidance says organizations should verify the integrity of backups and other restoration assets before use, restore essential services in an appropriate order, check restored assets for signs of compromise, address root causes before production use, and confirm that restoration was adequate before a system goes online.
Source: NIST SP 800-61 Revision 3, published April 2025.
HHS guidance for HIPAA regulated entities follows the same operating sequence. It tells organizations to determine the scope of a ransomware incident, whether it remains active, and whether it has propagated before moving through containment, eradication, and recovery.
Source: HHS Ransomware and HIPAA Fact Sheet.
Human-services containment can interrupt care as well as stop an attack
Containment is not simply a technician disconnecting one computer.
A residential program may rely on shared workstations across shifts. Community staff may connect from the field. Several locations may use the same Microsoft 365 environment, identity service, phone system, case-management platform, or electronic health record. A single compromised account can affect more than one device, program, or building.
The organization therefore faces a real tradeoff. Disconnect too little and the incident may continue. Disconnect too much without a continuity plan and staff may lose the minimum tools they need to support clients safely.
The answer is not to avoid disruptive containment. It is to decide in advance who can disable accounts, revoke sessions, isolate a site, suspend vendor access, take an application offline, activate a downtime process, and approve a phased return.
NIST recommends assigning the authority required for incident-response responsibilities before an incident. CISA likewise tells ransomware victims to identify affected systems, isolate them, and prioritize critical systems for restoration on a clean network.
Sources: NIST SP 800-61 Revision 3 and the CISA StopRansomware Guide.
Four questions define a defensible restore-readiness gate
Waiting for perfect certainty is rarely practical. A complex investigation may continue while essential services need to return. What executives need is a defined threshold for phased restoration.
1.What is contained?
The known affected accounts, devices, systems, locations, and connections have been identified. The paths most likely to support continued spread have been isolated, disabled, or restricted.
2.What is trusted?
The identities, devices, administrative tools, backups, and configurations used for recovery have been checked. Recovery is not being performed through the same potentially compromised account or workstation.
3.What returns first?
Restoration follows the effect on essential services and their dependencies. Identity, connectivity, communications, documentation, scheduling, payroll, billing, and program applications return in a deliberate order.
4.What will show that recovery is holding?
Logs, alerts, validation checks, and staff testing are in place to detect renewed malicious activity and confirm that the actual service works.
This gate does not replace technical investigation. It converts technical findings into an executive decision the organization can explain and defend.
The restoration threshold must be assigned before the incident
A restore-readiness gate only works when the people using it understand their responsibilities.
The executive incident sponsor must know which disruptions require authorization. Program and operations executives must define the minimum capability each essential service needs. The technology incident lead must coordinate containment, investigation, recovery, vendor actions, and monitoring. Privacy, compliance, finance, and communications resources must be brought in when the incident affects records, contractual duties, payroll, billing, insurers, or external notices.
Smaller organizations may assign several of these responsibilities to the same person. That is workable if the decisions, backups, alternates, and escalation paths are documented before the incident.
The organization should also know which outside providers can isolate accounts or systems, what evidence they can provide, and which approvals they require. A contract that says a vendor supports recovery does not establish how that recovery will be coordinated at 2:00 a.m. during a multi-site outage.
Recovery begins when trust is sufficient, not when every fact is known
The goal is not to bring every system back as fast as possible. It is to restore essential services in a controlled order without restarting the incident.
That requires judgment. Restoring too early can reintroduce the attacker or the original weakness. Waiting for complete certainty can extend a disruption beyond what programs can safely tolerate. A defined restore-readiness gate gives the organization a defensible way to move between those risks.
The better executive question is not only, “Can we restore from backup?” It is, “Can we show that the environment is trusted enough to restore, what must return first, and how we will know that recovery is holding?”
Containment is the bridge between a usable backup and a trustworthy service recovery. The final article in this series brings that bridge together with service priorities, safe downtime work, privacy, vendor coordination, restoration order, and testing in one operational resilience model for human-services organizations.
Sources
Can you show that your environment is trusted enough to restore?
Bitralynx Solutions works with nonprofit human-services and behavioral-health organizations on containment, restore-readiness decisions, and recovery that returns essential services in a deliberate order.
Backup and recovery readiness for human-services organizations