The First Hour of a Ransomware Attack: A Practical Response Plan

Ransomware response is decided long before the incident, but the first hour still matters enormously. This is a practical sequence for the first sixty minutes, written for the person who finds it rather than the person who planned for it.

Two things not to do, both of which are instinctive. Do not power the machine off, because volatile memory can contain encryption keys and forensic evidence. Do not start deleting the ransom note or affected files, because you are destroying evidence you may need for insurance and reporting.

Minutes 0 to 5: Contain

Disconnect affected machines from the network. Physically unplug the ethernet cable and disable wireless. Leave the machine powered on. The objective is stopping lateral movement while preserving state.

If multiple machines are affected, or a server is involved, isolate at the network level rather than machine by machine. Encryption spreads faster than you can walk between desks.

Minutes 5 to 15: Escalate and assess

Contact whoever owns your incident response, whether that is an internal team or your IT provider. Then establish scope:

• How many machines show encrypted files or a ransom note?
• Are file servers or shared drives affected?
• Is Microsoft 365 or other cloud data affected, or just local machines?
• Are backups reachable, and critically, are they on a system the attacker can also reach?

Minutes 15 to 30: Protect the backups

This decides whether the incident is a bad week or an existential event. Ransomware operators routinely target backups first, precisely because a business with clean, isolated backups does not pay.

If your backups are on a network share the compromised account could reach, assume they may be affected. Immutable or offline copies are the ones that matter here. This is why backup testing is not a bureaucratic exercise: the first time you discover a restore does not work should never be during an incident.

Minutes 30 to 45: Preserve and notify

Photograph ransom notes and screens. Record which machines were affected and when they were noticed. Preserve logs before anything is rebuilt.

Then work out your obligations. Under the Notifiable Data Breaches scheme, if personal information has been accessed or disclosed without authorisation and serious harm is likely, you must notify the OAIC and affected individuals. Ransomware that exfiltrates data before encrypting is a notifiable breach, not merely an availability problem. Contact your cyber insurer early, because many policies require prompt notification and some require using their nominated responders.

Minutes 45 to 60: Decide the recovery path

With scope understood and backups verified, the decision is rebuild-and-restore versus alternatives. A clean rebuild from known-good backups is almost always the right answer where backups are intact.

On paying the ransom

Australian Government guidance is not to pay. Payment does not guarantee a working decryptor, identifies the business as willing to pay, and may carry legal exposure depending on the recipient. There may also be reporting obligations attached to a payment. That decision needs legal advice and insurer involvement, not an operational judgement call at hour one.

What actually determines the outcome

Almost everything that decides how badly this goes was settled beforehand:

• Whether backups were isolated from the network the attacker reached
• Whether a restore had ever actually been tested
• Whether MFA was enforced on email and remote access
• Whether administrative privileges were restricted, or everyone was a local admin
• Whether anyone was monitoring alerts out of hours

Those are five of the Essential Eight, which is not a coincidence. If reading this made you uncertain about any of them, that uncertainty is the finding. Our free assessment reviews backup, recovery and incident readiness and tells you plainly where the gaps are.