How to Build a Ransomware Response Plan for Your Business

A ransomware response plan is a documented set of procedures that tells your organisation exactly what to do when a ransomware attack is confirmed. It specifies who does what, in what order, with what authority, and how decisions are made under pressure.

Without a plan, every ransomware response is improvised. Improvised responses under stress — with systems down, staff alarmed, and attackers on a countdown timer — consistently produce worse outcomes: delayed containment, missed notification windows, destroyed forensic evidence, unnecessary ransom payments, and insurance claims denied because the insurer wasn't notified in time.

A plan does not prevent ransomware. It determines how bad the outcome is when ransomware happens. Here is how to build one that actually works.

What a Ransomware Response Plan Must Cover

An effective plan for a South African SME covers six areas: detection and declaration, containment, assessment, notification and communication, recovery, and post-incident review.

1. Detection and Declaration

Who can declare an incident? Define who in your organisation has the authority to declare a ransomware incident and activate the response plan. This should not require unanimous agreement or escalation through three management layers — speed in the first hour matters. A single named role (IT Manager, Information Officer, or senior technical lead) should be able to make the call.

What triggers a declaration? Define observable indicators: ransom note on a screen, files with unexpected extensions, widespread inability to open files, unusual CPU activity on file servers, backup console showing unexpected deletions. Staff should know what to look for and who to call when they see it.

Out-of-hours contacts. Ransomware often deploys outside business hours — attackers deliberately time encryption for nights and weekends when detection is slower. Your plan must include mobile numbers and escalation paths that work at 2am on a Sunday.

2. Immediate Containment Actions

Document the specific steps to be taken within the first 30 minutes of a confirmed incident. These should be a checklist that any technically literate staff member can execute without judgment calls:

• Identify affected machines (ransom note visible, files encrypted)
• Disconnect affected machines from the network (pull cable / disable Wi-Fi / disable switch port)
• Do NOT reboot affected machines
• Do NOT delete encrypted files
• Do NOT attempt to run removal tools before forensic imaging
• Notify the incident commander (named role + mobile number)
• Document the time of discovery and affected systems in the incident log

Assign a named owner to each step. "IT will do it" is not a plan — "Sean K. (IT Manager, 082-xxx-xxxx) will do it" is a plan.

3. Incident Command Structure

Define who leads the response, who is responsible for each workstream, and how decisions are made.

Incident Commander: Overall coordination, decision authority, external communications. Typically the CEO or COO for significant incidents.

Technical Lead: Containment, forensic preservation, recovery. Typically IT Manager or external incident response firm.

Legal and Compliance Lead: POPIA notification, insurance notification, ransom payment legal assessment. Typically your attorney or compliance officer.

Communications Lead: Internal staff communications, client communications, media (if required). Typically a senior manager or marketing lead.

For SMEs without dedicated staff in each role, one person may cover multiple workstreams — but the responsibilities should still be explicitly assigned. Ambiguity about who is responsible for POPIA notification, for example, consistently results in missed notification windows.

4. Vendor and Partner Contacts

Your plan must include current contact details for every external party you will need to reach during an incident:

• Cyber insurance broker: Policy number, 24-hour incident line
• Incident response firm: Name, mobile number, engagement terms (retainer or on-demand)
• Managed backup provider: Contact for initiating recovery, 24-hour support line
• Legal counsel: Contact familiar with POPIA notification obligations
• IT/MSP provider: If external IT support is used
• Information Regulator: Contact details for breach notification submission

These contacts should be stored in printed form and digitally in a location accessible from a device unaffected by the incident — not only on the systems that may be encrypted.

5. Notification Decision Tree

POPIA Section 22 requires notification of the Information Regulator and affected data subjects after a security compromise involving personal information. Your plan must address this with a clear decision framework:

Step 1 — Does the incident involve personal information? If ransomware encrypted systems containing customer records, employee data, or any other personal information — yes. This applies to almost every business.

Step 2 — Has personal information been accessed or exfiltrated (not just encrypted)? Modern ransomware commonly exfiltrates data before encrypting. Forensic investigation will determine this — but notification should not wait for the full investigation to complete. Notify on the basis of a reasonable suspicion that personal information was compromised, and update the notification as the investigation proceeds.

Step 3 — Notify the Information Regulator. Submit notification to the Information Regulator as soon as reasonably possible — treat 72 hours from discovery as the target. The notification can be preliminary; it does not need to include full forensic details.

Step 4 — Notify affected data subjects. Once the scope of affected personal information is known, notify the individuals whose data was compromised. Your plan should include a template notification letter that can be adapted for the specific incident.

Include in your plan:

• The Information Regulator's notification portal URL and process
• A template preliminary breach notification to the Regulator
• A template data subject notification letter
• The criteria your organisation will use to determine whether notification is required

6. Recovery Decision Framework

Your plan must address the payment question before an incident occurs — not during one.

Primary path: Recovery from clean, tested backup. Document the specific steps: who initiates the restore, what the recovery sequence is (which systems first), what the expected recovery time is, and who confirms that restored systems are clean before reconnecting them to the network.

If backup recovery is not viable: Define the conditions under which alternative recovery options are pursued, who engages the forensic recovery firm, and who has authority to authorise ransom payment if all alternatives are exhausted. Define the insurer notification requirement before any payment is made.

Include the insurer's pre-authorisation requirement explicitly: "No ransom payment will be made without prior written authorisation from [insurer name]."

7. Post-Incident Review

Within two weeks of restoring normal operations, conduct a structured post-incident review:

• Root cause: how did the attacker get in?
• Dwell time: how long were they in the environment before the attack triggered?
• Detection: how was the attack detected, and how could it have been detected earlier?
• Response: what worked in the response, and what should be improved?
• Recovery: what was the actual recovery time vs the planned RTO?
• Remediation: what specific controls need to be implemented to close the entry point and reduce recurrence probability?

Document the outcomes and assign remediation actions with owners and deadlines. File the review with your POPIA incident register.

Testing Your Plan

A plan that has never been tested is a plan with unknown gaps. Test yours before you need it.

Annual tabletop exercise: Gather your incident command team and walk through a ransomware scenario. Assign roles, work through the decision points, and identify where the plan is unclear, where contacts are missing, and where decision authority is ambiguous. 90 minutes once a year is a meaningful investment.

Backup restore test: Test an actual recovery from backup annually, using a realistic scenario. Restore a server or a mailbox from backup to a test environment and verify that the data is complete and usable. Document the time taken. Compare it to your RTO commitment.

Contact list verification: Quarterly, verify that every contact in your plan is still current — insurer incident line, incident response firm, legal counsel, IT support. Contacts change. A plan with stale phone numbers fails at the worst moment.

Making the Plan Accessible

Your response plan must be accessible when your systems are down. Store printed copies in:

• The Information Officer's office
• The CEO's office
• With your IT lead (at home as well as the office)

Store a digital copy in a location independent of your primary systems: a personal cloud storage account, a USB drive kept off-site, or a printed copy with your insurer's documents.

A plan stored only on your company file server is inaccessible when the file server is encrypted. This sounds obvious. It is a mistake that organisations make with surprising regularity.

---

Building a ransomware response plan is a half-day exercise for most SMEs. The template structure in this article covers the essential components. The harder work — ensuring backup is in place, engaging an incident response firm, reviewing your cyber insurance coverage — is what the plan depends on.

Our team works with South African businesses to build and test both the plan and the technical infrastructure it relies on. If you would like to work through your response plan with us, we are available for a no-obligation planning session.