The outcome of a ransomware incident is largely determined in the first few hours. Who decided what, and in which order, affects the days to resumption of care more than the elegance of the technical recovery.
First response is hard because contradictory demands arrive at once. To stop the spread you want to disconnect — but disconnecting stops clinical care. You want to preserve evidence, yet powering down destroys some of it. You want to restore quickly, but restoring before the cause is known invites reinfection. Starting to think about these on the day is too late.
This article lays out the first response on a timeline, and shows how much of it can only be executed if decided in advance. It stays on the defender's side and does not describe attacker techniques.
Disclaimer: This article is general information. Real incident response varies greatly with the situation, contracts, and legal duties. Act on the advice of specialist responders, the relevant authorities, and counsel.
The First Hour: Stop the Bleeding, Preserve the State
The goal of the first hour is not root cause analysis. It is containment and preservation.
| Elapsed | Action | Decision-maker |
|---|---|---|
| 0–10 min | Confirm the event. One endpoint or many? Are core systems affected? | Finder / duty lead |
| 10–20 min | Declare an incident. Activate the response structure and call tree | Duty lead / safety manager |
| 20–40 min | Disconnect the affected scope: segment the network, cut external links | IT staff, under pre-delegated authority |
| 30–60 min | Brief clinical departments. First decision on outpatient, inpatient and emergency intake | Department heads / director |
| Within 60 min | Start the log. Write time-stamped facts | A dedicated scribe |
"Should we power off?" is the first dilemma. Powering down destroys information that exists only in memory, making later investigation harder; if encryption is in progress, it may limit the damage. Disconnection from the network should take priority — pull the cable, disable wireless — while leaving power on and awaiting specialist instruction is a workable default. The point is less which rule you pick than that you decide it in peacetime and write it into the plan.
Decide the prohibitions with equal weight: no continuing work on suspect endpoints, no repeated reboots, no reconnecting backup devices "to check", no following instructions on the ransom screen, no definitive statements outside the organisation before facts are confirmed.
Designing the Disconnection Decision
Disconnection and stopping clinical care are the same decision, which is exactly why criteria and authority must be set in advance.
What you can disconnect depends on how the network is built. A single flat segment leaves only one option: stop everything. Separated departmental, core, administrative and device networks let you contain. That is a peacetime design problem — see Network Segmentation and Asset Management.
What you need at hand — all of it outside the affected systems, on paper or offline:
| Artefact | Why |
|---|---|
| Network diagram | To know instantly what stops if you cut where |
| System and device inventory with owners and maintainers | Who to call to stop it, and to bring it back |
| Departmental dependencies | Understanding the knock-on effect on labs, imaging, pharmacy |
| Inventory of external connections (VPN, maintenance lines, online claims, regional exchange) | So no path is missed |
On perimeter devices as an entry point see Managing VPN Device Vulnerabilities; on recurring failure shapes see Learning from the Structure of Incidents.
Facing the Ransom Demand
Start from the premise that paying guarantees nothing. Decryption tools may not arrive, may not restore everything, and further demands may follow. Where data has also been stolen, payment carries no guarantee that the stolen data is destroyed.
| Consideration | How to think about it |
|---|---|
| Certainty of recovery | Payment does not ensure it. Recovery rests on rebuilding from backups |
| Inviting repeat attacks | Being known as an organisation that pays is itself a risk |
| Legal and regulatory exposure | Depending on the recipient of funds, legal issues may arise. Consult counsel, police and the authorities |
| Accountability | Public-facing healthcare providers will be asked to justify the decision itself |
| Breach handling | Reporting duties arise independently of whether you pay |
Do not build a plan that assumes payment. The spine of the plan is: from backups, in what order, over how many days. See Backup Design: the 3-2-1 Rule and A BCP for Cyberattacks. Ransom payments are also treated inconsistently by insurers — see Cyber Insurance for Healthcare Providers.
Calling for Outside Help
Few incidents can be handled alone. List who to call, in what order.
| Contact | What you ask for | Confirm in peacetime |
|---|---|---|
| EHR and departmental system vendors | Impact assessment, recovery procedure, workarounds | Out-of-hours intake and response time |
| Network and device maintainers | Performing disconnection, preserving logs | Whether they attend on site, and how fast |
| Specialist incident responders | Investigation, containment, recovery support | Whether a contract exists. Without one, engagement is slow |
| Police cybercrime contact | Reporting the crime, advice | The local contact point |
| Public health centre / local authority | Impact on clinical services | Reporting route and forms |
| Personal Information Protection Commission | Breach reporting | Whether reporting is required, and deadlines |
Finding a specialist after the fact costs days. Decide the relationship in advance, or confirm what support is bundled into maintenance contracts and insurance. For reporting duties see Reporting a Personal Data Breach.
Keeping Records
Records slip during response, yet their presence determines everything downstream: investigation, reports, insurance claims, public statements, prevention.
Appoint a dedicated scribe. People running the response will not write reliably. Capture four things:
- Events — what was observed, when, where. Separate fact from inference
- Decisions — who decided what and why, including rejected options
- Communications — who was contacted when, what was said, what was asked
- Technical preservation — logs, screen photographs, device states, captured before overwriting
Logs disappear once retention lapses. See Log Management and Audit Trails and Reviewing EHR Access Logs. Prepare record templates in peacetime in a form that can be filled in on paper — a spreadsheet on the shared drive is unavailable precisely when you need it.
Deciding to Resume
After containment comes "when do we restore?" Rushing here causes reinfection. Set the conditions in advance:
- The intrusion path is identified and closed
- The backup used is confirmed to predate compromise
- No malicious code remains on the systems being restored
- Credentials have been rotated comprehensively, including administrator and maintenance accounts
- Restoration is staged, under heightened monitoring
Then hold a review and feed it back into the plan. A real incident is the best drill material: where people hesitated, what information was missing, who could not be reached. Closing that loop into Incident Response Planning is part of first response.
Conclusion
- The first hour is for containment and preservation, not diagnosis. Fix the order and the decision-makers in advance
- Prioritise network disconnection; decide your power-off policy in peacetime and write it down
- Your disconnection options are set by network design. Keep diagrams and inventories on paper or offline
- Payment guarantees nothing. Plan around rebuilding from backups
- Choose your specialist responders before you need them
- Appoint a dedicated scribe and record events, decisions, communications and technical evidence in a paper-capable format
A first-response procedure only works if it reflects your own network and contracts. Pottech advises on governance and procedures from the standpoint of designing and operating medical information systems — contact us. For evaluating a supplier's own response capability, see What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
- Personal Information Protection Commission
Note: concrete response steps vary with the incident, the system architecture, and contractual relationships. This article presents general reasoning; act on the advice of specialists and the relevant authorities.