Ransomware Response Plan: Who Does What in the First 24 Hours

Assign roles by person, with a named backup for each. For a small company, one person may hold two roles, but write it down:

• Incident lead: makes decisions, keeps the timeline and decides when to escalate.
• Technical lead: directs containment, investigation and recovery.
• Communications owner: handles messages to staff, customers, partners and the press, using approved wording.
• Legal and insurance contact: your attorney and your cyber insurer's claims line, since many policies require early notice and use of approved vendors.
• Scribe: records every action with a time, because the log matters for insurance, legal and lessons learned.

Add a contact card with mobile numbers for each role, your IT provider, your insurer, your outside counsel and a forensic firm if you have one. Print it and keep a copy somewhere that doesn't depend on your network, since email and chat may be down.

Speed matters, but so does not making things worse. A workable sequence:

1. Recognize and declare. Call it an incident, name the incident lead and start the timeline.
2. Isolate. Disconnect affected machines from the network and turn off wireless. Unplugging the network cable or using your endpoint tool's isolate function keeps evidence better than pulling power. Follow your responder's advice on shutdowns.
3. Contain the account side. Disable or reset compromised accounts and rotate privileged credentials from a clean device, not from an affected machine.
4. Protect the backups. Check that backup systems are not reachable from infected machines, and disconnect them if they are.
5. Preserve evidence. Don't wipe or reimage machines yet. Photograph ransom notes and save sample encrypted files.
6. Call for help. Notify your insurer, your attorney and an incident response firm, then IT and leadership.

Use out-of-band communication, such as personal phones or a separate chat workspace, in case attackers are reading company email.

Decide the process ahead of time, not the answer. Payment is a legal, financial and ethical decision, and it never guarantees that data comes back or that the attackers don't return. It may also carry legal risk depending on who is behind the attack and where you operate, so involve your attorney and insurer before any contact with the attackers, and consider whether law enforcement should be notified.

Your plan should say who has authority to decide, who must be consulted first and that nobody negotiates alone. The best position to be in is one where clean, tested backups make the question much less urgent.

Prepare short, factual templates for each audience and let counsel review them before use:

• Staff: what happened, what to do and not do, and how to report anything odd.
• Customers: what is affected, what you're doing and when you'll update them. Don't speculate about cause or scope.
• Regulators and contractual notifications: notification duties depend on your jurisdiction, the data involved and your contracts, so ask your attorney which apply and how fast.
• Insurer: follow the notice and vendor requirements in your policy.

Keep updates on a schedule, even when the update is that nothing has changed. Silence creates more speculation than a plain progress note.

Recovery is where a second infection happens if you rush. Work through this order:

1. Establish how the attackers got in, and close that path first: a stolen credential, an exposed remote access service or an unpatched system.
2. Rebuild affected systems from known-good images rather than cleaning them in place.
3. Restore data from backups you've verified are clean, testing in an isolated network before reconnecting.
4. Reset all credentials, including service accounts and API keys, and enforce multi-factor authentication.
5. Reconnect in stages while monitoring closely, with endpoint detection running on every restored device.
6. Hold a review within two weeks and update this plan.

Detection tooling such as CrowdStrike or SentinelOne can help with isolation and visibility, and a disaster recovery plan defines how fast you need each system back. The general incident response plan covers non-ransomware events.

The preparation list is short and effective: keep at least one backup copy offline or immutable, test a full restore, enforce multi-factor authentication on email and remote access, patch internet-facing systems promptly, and deploy endpoint detection with someone watching it. Run a two-hour tabletop exercise once a year using a realistic scenario, and fix whatever it exposes. Your answers here will also help when customers send a security questionnaire.