How to Build a Cybersecurity Incident Response Plan for Your Business

A cybersecurity incident response plan is the document you write on a calm Tuesday that you will follow on the worst day of your working life. It is a short, pre-agreed playbook for the first hours and days after an attack: who leads, who calls the lawyers and the insurers, how you preserve evidence, when the Information Regulator must be told, and what you say to clients. The plan exists because humans under adrenaline make bad decisions, and the businesses that survive ransomware and data breaches are usually the ones whose decisions were made in advance.

Most South African SMBs do not have one. That is not an insult, it is a gap, and the gap is closable in a working week. This guide walks through what a practical incident response plan contains for a business of 10 to 200 people, aligned with POPIA’s legal requirements, and honest about what you can do yourself versus when you need professional support.

What the Plan Actually Contains

Keep it short enough to use. A workable SMB plan is 8 to 12 pages, not a 60-page policy binder. It contains six things:

• Roles with names. An incident leader, a deputy, a communications owner, and a legal contact. Everyone else needs one line: report anything suspicious to this number, day or night.
• Detection triggers. The specific signs that start the clock: ransom notes, locked accounts, mass file changes, bank confirmation calls, clients reporting strange emails from your domain.
• The first-hour checklist. Isolate affected systems, preserve logs, activate the plan. Explicitly do not delete evidence, do not power-cycle encrypted machines, do not pay anything before the insurer is consulted.
• The legal timeline. POPIA requires notification to the Information Regulator within 72 hours of becoming aware of a breach that risks harm, and affected data subjects must be told too. The plan fixes who assesses that and when.
• Communication templates. Pre-drafted skeleton messages to staff, clients, and the public, because drafting honest sentences under pressure is far harder than filling in blanks.
• Recovery steps. Which backups restore first, the rebuild order, and the criteria for declaring “clean” before reconnecting.

Our article on POPIA breach notification in the first 72 hours covers the legal sequence in detail, and it belongs in the plan’s appendix.

The Six Stages, Sized for an SMB

Formal incident response, the NIST framework, describes six phases: preparation, Detection and Analysis, Containment, Eradication, Recovery, and Lessons Learned. Enterprises staff each phase. An SMB should size them honestly:

Preparation is the plan itself plus tested backups and contact lists. Detection will likely start with a phone call from a staff member or client, so staff must know the number to call. Containment for an SMB means isolation fast: pulling the network cable, disabling the affected accounts, blocking the attacker’s access path. Eradication, confirming the attacker is out and the vulnerability is closed, is the first phase where professional help earns its fee, because attackers leave back doors. Recovery is restoring from known-good backups in the agreed order, finance first, then operations. Lessons Learned is a one-page written review within two weeks, while memories are honest.

POPIA and the 72-Hour Clock

The legal deadline is what turns a technical mess into a compliance test. From the moment you become aware of a breach involving personal information that is likely to cause harm, section 22 of POPIA obliges you to notify the Information Regulator, and the expectation aligned with practice is within 72 hours, plus notify affected data subjects. The notification needs specifics: what data, whose, the likely consequences, and what you are doing about it.

Two practical notes. First, “becoming aware” starts the clock, not “confirming every detail”, which is why the plan assigns someone to make that assessment immediately. Second, insurers increasingly require reasonable security measures as a condition of cover, and an incident response plan is the first thing a cyber insurer asks to see. Our overview of what cyber insurers check lists the documents to have ready.

Building the Plan in a Working Week

Day one: assign roles and collect every emergency contact, insurer, lawyers, IT provider, bank fraud line, into one page. Day two: write the detection triggers and first-hour checklist with your IT person or provider in the room. Day three: draft the POPIA notification decision tree and communication templates, ideally reviewed by a legal adviser once. Day four: document the recovery order from your backup strategy, and verify the backups actually restore. Day five: run a one-hour tabletop exercise, a scripted scenario where the team talks through the first hours, then fix what the exercise exposed.

The tabletop is the part most businesses skip, and it is where the plan stops being paper. One hour, one scenario, for example: “It is 07:40 Monday and the finance manager cannot open any files, there is a note on her screen”, and you walk the plan step by step. The first run always finds a missing phone number or an unclear decision owner. That is the exercise working.

Frequently Asked Questions

What is an incident response plan?

It is a pre-agreed playbook for handling a cyber attack: who leads, the first-hour actions, the legal notification steps, communication templates, and the recovery order. It is written calmly in advance so decisions under pressure follow a script. For most SMBs, a practical plan is 8 to 12 pages.

How long do we have to report a breach under POPIA?

Notification to the Information Regulator is expected within 72 hours of becoming aware of a breach involving personal information that is likely to cause harm. Affected data subjects must also be notified. The clock starts at awareness, not at full investigation, so assign the assessment to a named person in the plan.

Who should be on the incident response team?

An SMB team is four roles, not a committee: an incident leader who decides, a technical lead who contains and investigates, a communications owner who writes to staff and clients, and a legal contact. Everyone else in the business needs exactly one instruction: call this number if something looks wrong.

Should we pay a ransom?

The plan should state the default: no payment decisions before consulting insurers and legal advisers. Payment does not guarantee working decryption, marks you as a payer for future attacks, and may raise legal exposure. Tested, isolated backups are the alternative that payment cannot buy back.

How often should we test the plan?

Once a year at minimum, plus after any real incident or major system change. A one-hour tabletop exercise with the core team is enough, it walks a scripted scenario through the first hours. Every run surfaces a stale contact or unclear decision, which is exactly what it is for.

Write It Before You Need It

An incident response plan costs a week of part-time attention and pays for itself the first hour of any real incident, in decisions not improvised and deadlines not missed. The version that helps is the short one with names, numbers, and a tested backup restore, not the long one nobody reads. If you want an experienced outside eye, Greg Hay builds and pressure-tests these plans with South African businesses, and the same POPIA expertise behind the POPIA compliance checklist applies here: the plan’s value is being ready before the day it matters.