How to respond to ransomware: a plan for small and mid-size firms

What are the steps to prepare for and respond to ransomware?

The same ten steps work for a 20-person practice and a 500-person company. The first four happen in calm weather; the rest happen on the night and the weeks after.

• 1. Price an outage day and agree a budget: revenue lost or delayed plus staff time lost, then outside response costs.
• 2. Name six roles, each with a deputy: decision-maker, incident lead, technical lead, privacy and legal lead, communications lead and scribe.
• 3. Build an out-of-band contact list (personal mobiles, a secure messaging group, your IT provider, insurer hotline, forensics and counsel) and print it.
• 4. Keep backups the attacker cannot reach: three copies, two kinds of storage, one offsite, one immutable or offline, and time a restore of each critical system every quarter.
• 5. On the night, declare a severity using the higher of business and data impact.
• 6. Disconnect affected devices without powering them off; cut internet and VPN if spread is possible; disable admin accounts from a clean device.
• 7. Call your insurer's breach hotline early, engage forensics and preserve evidence with a chain of custody.
• 8. Tell staff, clients and suppliers what you know, what you are doing, what they should do and when the next update comes.
• 9. Track every notification party and clock with counsel, and decide any extortion demand with a written record.
• 10. Hold a blameless after-action review within 14 days and turn every lesson into an owned, dated action.

What should you do in the first hour of a ransomware attack?

The first hour is when most damage is done or avoided, and when people are least able to think, so decide it in advance and run it from a card. In minutes 0 to 15, the incident lead takes charge, a scribe starts a timeline and the team moves to an out-of-band channel, because the attacker may be reading company email. Affected devices are disconnected from the network but not powered off. CISA's ransomware guide makes the same point: isolate affected systems, and power down only if you cannot disconnect them, because powering off can destroy volatile evidence.

In minutes 15 to 30, the decision-maker is told, your IT or detection provider joins, internet and VPN are cut if spread is possible, admin accounts are disabled from a clean device and backups are checked. In minutes 30 to 60, the insurer's hotline is called (policies often require it before you hire anyone), forensics is engaged, counsel is told if personal data may be involved, staff get a text and the next update time is set. The US Federal Trade Commission's guidance for business gives similar advice: take affected equipment offline, do not power machines off until forensic experts arrive, and do not destroy evidence.

How do you make backups that survive ransomware?

Attackers look for backups early and delete or encrypt the ones they can reach. The common 3-2-1 rule of thumb (three copies, two kinds of storage, one offsite) is a start. Against ransomware, add one copy that is immutable or offline, so it cannot be changed or deleted even by an administrator, and aim for zero errors in the last restore test. The UK's National Cyber Security Centre advises keeping offline backups separate from your network, keeping multiple copies in different locations, and testing that restores work; CISA recommends offline, encrypted backups tested regularly.

Then set two targets for each system with the person who runs the process: the recovery time objective (RTO), the longest the business can be without it, and the recovery point objective (RPO), how much recent work it can afford to lose. Sort systems into tiers (identity, backup console and firewall first, because everything depends on them) and define minimum viable operations: the smallest set of systems that lets the business keep its promises. Time every restore against its RTO.

What does a worked example look like?

Here is a fictional 120-person engineering consultancy in Brisbane. In a May restore test, its drawing register took 26 hours against an RTO of 24. In a real incident in August, identity took 16 hours against an RTO of 8 because the credential reset was done by hand. The firm still reached minimum viable operations 31 hours after the alert, because identity and the file server came back from copies the attacker could not touch.

Before the programme, the firm priced an outage day at A$98,134: half of A$92,300 daily revenue plus 60% of staff time for 120 people at A$95 an hour for 7.6 hours. Its estimate of an expected-case incident was A$1,553,876 without preparation and A$452,536 with it, against a programme cost of A$118,500 in year 1. Weighted by a 5% chance in its low case, the programme did not pay back in year 1, and the firm said so to its board.

How should you communicate during a cyber incident?

Every message to every audience answers four questions: what we know, what we are doing, what you should do, and when the next update will come. The last one matters most. A promised 8:30 update that arrives at 8:30, even if it says nothing has changed, buys trust you will need later. Do not speculate about the attacker, the data or the timeline, do not promise what you do not know, and never blame the person who clicked.

Order matters too. Staff come first, because they can make things worse by logging in; send them a short text by phone, not company email. Your insurer comes early. Clients with contract notice clauses must be told within the clause's time, and other key clients deserve a call before they read about it. Warn suppliers that criminals may send fake invoices or bank detail changes in your name. Use one spokesperson for the media. Write and approve the first staff text, the client holding statement and the media holding statement in advance, so they can go out at 3 a.m. without waiting for a signature.

When do you have to report a cyber incident or data breach?

It depends on the law, the facts and your contracts, and the rules differ by country. Under the EU GDPR, a controller notifies its supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people; the UK GDPR has the same 72-hour clock for reports to the ICO. In Australia, an entity that suspects an eligible data breach must take all reasonable steps to assess it within 30 calendar days and notify the regulator and the people at risk as soon as practicable once it believes one has occurred. In Canada, PIPEDA requires a report when a breach creates a real risk of significant harm, and records of every breach for 24 months. In the US, every state, DC, Puerto Rico and the US Virgin Islands has a breach notification law, according to the FTC, and listed companies disclose material incidents under the SEC's Form 8-K rules.

Three habits help everywhere: write down the time you became aware and why; list every party (insurer, clients with notice clauses, regulators, people affected, agencies) with its own clock; and let counsel confirm each duty. Many regulators accept an initial report followed by updates. These rules were correct at November 2026; check the official source.

Should you pay a ransom?

This is a decision for your organisation's leadership, with advice, and it should be recorded. Official positions are clear about the risks. The FBI says it does not support paying a ransom. The US Treasury's Office of Foreign Assets Control says the US government strongly discourages paying ransom or extortion demands, that sanctions penalties can apply on a strict liability basis, and that prompt reporting to law enforcement and full cooperation are significant mitigating factors. The UK's NCSC says law enforcement does not encourage, endorse or condone payment, and that paying does not guarantee you get your data back.

Some countries add reporting duties: in Australia, businesses above a turnover threshold must report a ransomware payment to the national cyber agency within a short window. A practical decision record asks, in order: can we recover from clean backups; what do counsel (including sanctions checks), our insurer and law enforcement advise; is any deletion promise verifiable (it is not); and, if a payment were ever made, which reports must follow.

What are the most common mistakes?

These are the mistakes that turn a bad night into a bad month.

• Powering everything off, which destroys evidence of what the attacker ran.
• Discussing the response on company email or chat the attacker may be reading.
• Restoring over infected systems, or reconnecting before credentials are reset.
• Backups on the same network and credentials as everything else.
• Never timing a restore, so nobody knows how long recovery will take.
• Hiring outside firms before calling the insurer, when the policy requires the call first.
• Waiting to be certain before starting the notification clock.
• Blaming the person who clicked, so the next person hides a mistake.
• Holding a review with no owned, dated actions at the end.

How do you keep the plan alive?

Run a 90-minute tabletop exercise at least twice a year with the real decision-makers and a different scenario each time: ransomware at 3 a.m., a supplier's email taken over to send fake invoices, client data on a leak site. Check the contact list every quarter, run restore tests every quarter, and review the plan every six months and after any serious incident. After every exercise or incident, hold a blameless after-action review within 14 days with four questions: what did we expect, what happened, why the difference, and what will we change.

Keep your own team's judgement sharp as well: AssessAll's Incident Response and On-Call Judgment assessment is one way to see where the incident team starts. And if personal goals keep slipping, Jobulary's guide to the fresh-start effect explains how to reset one on a meaningful date. The Ransomware and Cyber Incident Response Playbook from Bodhih Training holds the workbook, forms, plan, message library and three tabletop scenarios used in this guide. Agency and framework names are used descriptively; Bodhih is not affiliated with or endorsed by NIST, CISA, the NCSC or any regulator named here.