Ransomware response plan: from the first renamed file to the review

What this is, and what it is not

The first-hour ransomware playbook tells one person what to do in the next sixty minutes. This is the plan around it: the decisions that belong to somebody other than the analyst, the order the days after go in, and the conditions that have to be met before anything is restored.

It is a template. Your authority to isolate a production system, your insurer's panel of responders and your regulator's deadlines are not in it, and a plan that does not know them cannot be followed literally. Put them in before you need them.

Decide these before the incident

Every row here is a decision that takes an hour to make badly at 3am and five minutes to make well in advance.

Decision	Who owns it	Write down now
Isolating a production system without asking first	Incident lead	The systems they may isolate on their own authority, and the ones that need a named executive
Engaging an outside responder	Incident lead, with legal	The retainer, the phone number, and whether your insurer requires you to use theirs
Talking to the operator at all	Executive, with legal	That nobody does it informally, from any account, before that decision
Paying	Board or owner, with legal	That the security team does not make this decision and is not asked to
Declaring recovery complete	Incident lead and the system owner together	The checks in the recovery section below

CISA, MS-ISAC and federal law enforcement do not recommend paying. Payment does not guarantee decryption and does not guarantee that stolen data is deleted. Whether a payment is lawful depends on who receives it, which is a question for counsel rather than for the response team.

Phase 1: confirm, and start the clock

Goal: know that this is ransomware, and record when you knew.

1. Record the time of the first report in UTC, who made it and what they saw. Several notification deadlines run from when you became aware, and "some time on Tuesday" is not an answer a regulator accepts.
2. Confirm with two independent observations: a ransom note or renamed files on a host, and the destruction sequence in process logs (shadow copy deletion, backup catalogue deletion, recovery disabled).
3. Open the case record. Every action from here gets a time, a name and a reason. It is the only thing that lets you reconstruct your own response later.
4. Move coordination out of band. Assume email and chat on the affected tenant are readable by the operator until shown otherwise.

Phase 2: contain without destroying

Goal: stop the spread while keeping the evidence that explains it.

1. Isolate at the network, leave hosts powered on. EDR isolation, a switch port, a VLAN change. The CISA guide's position is to power down only if you cannot disconnect, because powering down loses what is in memory, and memory is where the encryptor, the operator tooling and occasionally the key are.
2. Isolate by blast radius, not by alert. If the operator had domain credentials, the affected set is everything those credentials reach. Start with file servers, hypervisors and backup infrastructure.
3. Protect the backups before you inspect them. Take the backup store off the network or make it read-only. Check whether it was reachable with any credential that was live on a compromised host.
4. Disable, do not delete, the accounts involved. A deleted account loses its SID history and its logon records in some tooling. Disable, reset twice where Kerberos is involved, and record the time.
5. Block the known infrastructure at the egress, and log the blocks. The block list is also a detection: a host that keeps trying is a host you have not found yet.

Phase 3: scope, and find the way in

Goal: a defensible answer to "how did they get in, where did they go, and what did they take".

Work backwards from the destruction sequence. It names a host and an account, and both are the end of a chain.

Question	Where the answer usually is
Which account ran the destruction commands, from where	Process creation (4688 or Sysmon 1) on the encrypting host, then logon events 4624 for that account
How that account was obtained	LSASS access on an earlier host, a Kerberoastable service account, or a credential in a script. See the event log cheat sheet
How they moved	Logon type 3 and type 10 between hosts, service installs (7045), remote scheduled tasks
The first host	Earliest anomalous logon or execution in the chain. Commonly an edge appliance, an exposed RDP or VPN without MFA, or a phished workstation
Whether data left	Egress volume by host in the days before encryption, archive creation in the USN journal, cloud storage and file transfer tooling in process logs

Capture memory from at least one affected host before anything else is done to it, then image at least one host in full. The questions about scope and theft arrive days later, from lawyers, and they are answered from images, not from memory of what the console showed.

Assume theft until you can show otherwise. Most current operations steal before they encrypt, and the notification duty usually follows the theft, not the encryption.

Phase 4: eradicate

Goal: remove every route back in, in one coordinated action.

Do this once and together. Removing persistence piecemeal tells the operator which of their footholds you have found.

1. Reset every credential that was live on a compromised host: users, service accounts, local administrators, and the KRBTGT account twice if a domain controller was reached.
2. Revoke cloud sessions and review OAuth grants, as in the cloud account playbook. A password reset does not invalidate a refresh token.
3. Remove persistence across the estate, not only on hosts that were encrypted: services, scheduled tasks, Run keys, WMI subscriptions, new local accounts, remote access tools installed as "IT support".
4. Close the entry point. Patch or withdraw the appliance, enforce MFA on the remote access route, remove the exposed service.
5. Rebuild domain controllers and other tier-zero systems from known-good media where they were reached. Cleaning them is a bet that you found everything.

Phase 5: recover

Goal: restore service into an environment the operator cannot return to.

Restore only when all of these are true, and record who confirmed each:

• The entry point is identified and closed.
• The credentials from phase 4 are reset and the resets have replicated.
• The backup being restored predates the operator's first known access, not just the encryption. Restoring last week's backup restores last week's implant.
• The restored system goes into a segment with monitoring in place before it carries production traffic.

Restore in business priority order that was agreed in advance, and keep heightened monitoring for at least thirty days. The detections that matter most in that window are the ones for the techniques this operator actually used.

Phase 6: notify

The clocks here vary by jurisdiction and sector and most started when you became aware. This is the list to take to counsel, not legal advice:

• Your insurer, usually first, and usually before engaging a responder they have not approved.
• Law enforcement. In the United States, CISA and the FBI ask for reports and can sometimes help with decryptors or with infrastructure intelligence.
• Data protection and sector regulators, where personal or regulated data was accessed.
• Affected individuals and customers, on the timetable counsel sets.
• Staff, plainly and early. They know something is wrong, and an absence of information gets filled.

Phase 7: review

Hold the review within two weeks, while people remember. NIST SP 800-61r3 folds lessons learned into continuous improvement rather than treating it as a closing ceremony, and the useful output is a short list of changes with owners and dates.

Ask four things: what was the earliest moment this could have been detected with the telemetry you already had, what evidence had expired by the time you needed it, which decision waited longest for somebody with authority, and which detection would you write now. Then write it.

What goes wrong, in order of frequency

1. Hosts are rebooted or reimaged before memory or an image is taken. The response destroys its own evidence.
2. Restoration starts before the entry point is known. See above.
3. Backups were reachable from the domain. The operator deleted or encrypted them first. Test restores, offline or immutable copies and separate credentials are the fix, and they are a fix for before.
4. The theft is discovered from the leak site. Nobody looked at egress because everybody was looking at encryption.
5. Nobody kept a timeline of the response itself, so the report to the regulator is reconstructed from chat logs.