Most incident response advice is written for organisations that already have incident response. It assumes a security operations centre, a defined severity matrix, a forensics retainer, and a communications team on standby.
If you are starting from nothing, that advice is not merely unhelpful. It is actively harmful, because it makes the first useful step look enormous. It is not. Month one has four jobs, and none of them requires a budget.
Week one: decide who decides
The most common failure in a first real incident is not technical. It is that nobody knows who is permitted to take a production system offline, notify a customer, or engage a lawyer. Hours get spent locating that person, and those hours are spent while the incident continues.
So write down three things:
- Who declares an incident, and how anyone in the company reaches them, including at two in the morning on a Sunday
- Who is authorised to disrupt production in order to contain something, and what they may do without seeking further approval
- Who owns external communication, meaning customers, the Information Regulator, and the press, and who is explicitly not permitted to speak
One page. Names rather than job titles, with a named deputy for each. Circulate it, and keep a copy somewhere that does not depend on the systems which might be down.
Week two: find out what you can actually see
Before writing a single playbook, establish what evidence exists and how long it survives. Pick a plausible scenario, say a compromised user account, and try to answer these questions using only what you have today:
- Can you tell when a given account last authenticated, from where, and to what?
- Can you tell what that account accessed afterwards?
- How far back do those logs go, and are they retained somewhere the compromised account could not delete?
- If a laptop is involved, can you reach it, and can you isolate it remotely?
- Do you know which systems hold personal information, so you can determine within hours whether a breach is notifiable?
You will not enjoy the answers, and that is the point. The exercise produces a short, ranked, obviously justified list of logging and access gaps. It is the highest-value week of the four, and it costs nothing but attention.
Week three: write three playbooks, not thirty
Playbook libraries are where first-year incident response programmes go to die. Write three, covering what actually happens to organisations of your size:
- Business email compromise or credential phishing
- Ransomware or destructive malware on an endpoint or server
- Exposed data, meaning a public storage bucket, a leaked key, or an accidental disclosure
Each should fit on two pages, and each should answer the same set of questions: how do we know, who do we call, what do we do first, what do we deliberately not do, what do we preserve, and at what point does this become a notification decision.
That last question matters in South Africa specifically. Section 22 of POPIA requires notification to the Information Regulator and to affected data subjects as soon as reasonably possible after a compromise is discovered. Your playbook should name the moment that assessment begins and who makes it, so that it is not being invented under pressure by whoever happens to be awake.
Include a do-not list. Do not delete the malware. Do not reboot the host before capturing memory if you might need it. Do not tip off the attacker with a mass password reset before you understand scope. Do not discuss the incident on the platform that may itself be compromised.
Week four: run one tabletop
Ninety minutes, the people named in week one, one of the three scenarios, and somebody whose only job is to write down every question the room could not answer.
Do not aim for realism. Aim for exposing gaps. The output you want is not a maturity score. It is a list that reads like: nobody knew whether we have cyber insurance, we could not reach the person with the domain registrar login, our backup restore has never been tested end to end, and we have no way to email all customers if the mail platform is the thing that is down.
That list is your roadmap for month two, and it was produced by your own organisation rather than by a vendor’s maturity model.
What month one should not include
Not a tool purchase. Every capability gap you found in week two will appear to have a product answer, and buying before you understand the gap is how organisations end up with a SIEM that nobody tunes and everybody resents.
Not a thirty-page policy. Not a five-level severity matrix with an accompanying responsibility chart. Not a threat intelligence subscription.
And not a claim that you are now prepared. You are not. You are marginally less likely to waste the first four hours of a real incident, which is a genuine improvement and worth being honest about.
How to tell whether it worked
One test. Pick somebody who does not work in security, and ask what they would do if they clicked a link and then realised it was fake.
If they can name a person or a channel without hesitating, and they believe they will not be punished for reporting it, month one worked. If they say they would probably just change their password and hope, it did not, and no amount of playbook writing will fix that until the reporting path is real and visibly safe to use.