Ransomware Attack: What to Do in the First 24 Hours

The moment ransomware is confirmed on your network, a clock starts. The decisions made in the next 24 hours determine whether the incident is contained and recovered from quickly, or whether it becomes a weeks-long catastrophe that threatens the business.

Most organisations have never rehearsed this scenario. Under the pressure of an active incident — systems down, staff panicking, attackers on a countdown timer — untested decision-making leads to mistakes: paying when payment is avoidable, delaying notification until it becomes a regulatory violation, failing to preserve evidence needed for insurance claims, or rebooting systems that preserve forensic artefacts.

This guide gives you a clear, step-by-step framework for the first 24 hours. Print it. File it. Make sure the people who need it know where it is before you need it.

Hour 0: Detection and Initial Containment

Do not reboot affected systems. This is the most common first-instinct mistake. Rebooting may destroy volatile memory artefacts — running processes, network connections, encryption keys held in RAM — that forensic investigators need to identify the attacker, determine the scope, and potentially aid decryption. Leave affected systems powered on but disconnected from the network.

Disconnect from the network immediately. Pull the network cable or disable the Wi-Fi on affected machines. Do not wait to confirm the scope first — contain first, assess second. If you can do it quickly and safely, disable network switches serving affected segments. The priority is stopping lateral movement before the ransomware reaches systems it has not yet touched.

Do not delete files or attempt manual recovery. Do not attempt to restore from backup yet. Do not delete encrypted files. Do not run antivirus removal tools on affected systems before forensic imaging. Preserve the state of affected systems exactly as they are.

Alert key personnel. Notify your CEO or MD, IT lead, and any managed service provider or incident response partner. If you have cyber insurance, notify your broker immediately — many policies require prompt notification and may void coverage if you act without their involvement.

Document the time and symptoms. Note the exact time you first observed ransomware symptoms, which systems are affected, and the content of any ransom note. This documentation is required for insurance claims, POPIA notification, and forensic investigation.

Hour 1: Scope Assessment

Identify affected systems. With network access disabled on affected machines, assess which systems have been encrypted and which appear unaffected. Work from a clean device — a laptop that was off during the attack, or a device that was not connected to the affected network segment.

Check your backup status. From a clean, unaffected device, log into your cloud backup management console and verify:

• What is the most recent successful backup for each protected system?
• Is the backup console accessible and showing normal status?
• Are backup copies showing as intact in the management console?

If your backup is cloud-based with immutable storage and the console shows intact backups, your recovery path is clear. If your backup appears to have been affected or is inaccessible, note this immediately — it changes the decision framework significantly.

Identify the potential entry point. Look for phishing emails that arrived in the 24–72 hours before the attack. Check Remote Desktop Protocol access logs if RDP is enabled. Review recent software installations and email attachments. This is preliminary — forensic investigators will do a thorough analysis — but early identification of the entry point helps determine whether the attacker may still have active access.

Hour 2–4: Notification and Professional Engagement

Engage a professional incident response firm. Unless you have an internal security team with ransomware response experience, this is not optional. A qualified incident response firm will: forensically image affected systems before recovery begins; identify the ransomware strain and assess whether free decryption tools exist; assess the extent of any data exfiltration during the dwell period; advise on the payment decision if backup recovery is not viable; and preserve evidence for insurance, regulatory, and potential law enforcement purposes.

Begin this engagement in parallel with your own response activities. Delays in engaging professional support are consistently cited as a factor that increases total incident cost.

Notify your cyber insurer. Contact your cyber insurance broker or insurer's incident response line. Most policies require notification within a specific timeframe (often 24–72 hours of discovery). Provide the initial information you have documented: time of discovery, systems affected, whether backup is intact. Do not authorise ransom payment before consulting with your insurer — many policies require prior approval.

Assess the POPIA notification obligation. A ransomware attack that encrypted personal information — or where the attacker had access to systems containing personal information during the dwell period — triggers POPIA Section 22 notification obligations. You must notify the Information Regulator and affected data subjects as soon as reasonably possible. In practice, "as soon as reasonably possible" for Regulator notification is understood to mean within 72 hours of becoming aware of the breach.

You do not need to have determined the full scope of affected personal information before notifying — the notification can be updated as the forensic investigation proceeds. What you cannot do is delay notification until the investigation is complete, which may take weeks.

Brief staff. Tell your staff what has happened — briefly and factually. They will already know something is wrong. A clear communication prevents rumour, prevents staff from taking unhelpful actions (rebooting their machines, connecting to the network from home, contacting clients directly about the incident), and establishes a single point of communication.

Hour 4–12: Recovery Initiation or Ransom Assessment

If backup is intact: initiate recovery.

Work with your IT team or managed backup provider to identify the appropriate recovery point — the most recent clean backup that predates the compromise, which may require looking beyond the most recent snapshot if dwell time was significant. Prioritise systems in order of business criticality: core operational systems first, then secondary systems, then endpoints.

Restore to clean hardware or freshly provisioned virtual machines where possible — do not restore to systems that were running during the attack until they have been forensically cleaned and the entry point closed.

If backup is compromised or absent: assess alternatives.

Your incident response firm will advise on alternative recovery options: shadow copy recovery, file carving, decryption tools for the specific ransomware variant. Be realistic about the success probability and timeline for each.

If alternative recovery is not viable and payment is being considered: do not act without your insurer's involvement, legal advice on sanctions exposure and FICA obligations, and confirmation from your incident response firm on the negotiation process. Ransom negotiations conducted by professionals consistently achieve better outcomes — lower amounts, working keys — than panicked direct payment.

Hour 12–24: Stabilisation and Evidence Preservation

Re-establish communications. If email is affected, establish alternative communication channels for staff and for client-facing operations. A temporary Gmail workspace, mobile messaging, or a previously identified out-of-band communication plan.

Preserve forensic evidence. Before cleaning and rebuilding any affected systems, ensure forensic images have been taken by your incident response firm. This evidence is required for insurance claims, potential law enforcement referral, and the Information Regulator investigation that may follow your POPIA notification.

Communicate with affected clients and suppliers where necessary. If the incident has caused visible service disruption — systems inaccessible, emails bouncing, orders not being processed — affected parties will need to know. Keep communications factual: "We have experienced a cyber security incident and are working to restore normal operations. We will provide an update by [time]." Do not speculate about the cause, scope, or whether personal data has been affected until you have forensic confirmation.

Document everything. Maintain a running incident log: every action taken, every system affected, every decision made, every person notified, and the time of each. This log is essential for insurance, regulatory, and legal purposes.

After 24 Hours

The first 24 hours are about containment, assessment, and initiating recovery. The days and weeks that follow involve completing recovery, conducting a root cause analysis, implementing the remediation identified by forensic investigators, and building the procedures and controls that reduce the probability and impact of a future incident.

The organisations that recover fastest and most completely from ransomware are those that had a documented response plan, a tested backup strategy, and professional incident response relationships in place before the attack occurred. The time to establish these is not during an incident.

If you have not yet documented your ransomware response plan or assessed your backup readiness, our team can help you build both.