This week the internet got a fresh scare. On 21 October 2026, details of two serious flaws in PHP leaked online before most organizations had a fix in place. PHP is the software that runs about seven in ten websites, including most WordPress sites. Researchers call the flaws PHP2Shell. They let an attacker take control of a web server without needing a password, and security firms are already seeing attacks.
Closer to home, the Communications Authority of Kenya recorded 2.35 billion cyber threat events in just the three months to June 2026. So the question is not if something will go wrong. It is what will you do in the first hours when it does?
And your next breach may have nothing to do with PHP2Shell. It could be one stolen password. One convincing phone call to your IT help desk. One mistake by a supplier. Most organizations spend money keeping attackers out and spotting them. Far fewer plan what to do once an attacker is in. This blog is that plan, in plain language, with real stories of what went right and what went wrong.
"Back online" is not the same as "recovered"
When systems go down, everyone wants them back fast. Every hour offline costs money and customer trust, so that pressure is real. But switching a system back on is not the same as recovering it. If you restore from a backup the attacker had already touched, or you leave the original weakness open, they can simply walk back in, often doing more damage the second time.
Real case: Change Healthcare, USA (2024). Attackers logged in using one stolen password on a remote-access portal that had no second login step (no multi-factor authentication, or MFA). They stayed hidden for nine days, copying data, before they locked systems with ransomware.
The company paid a ransom of about US$22 million. The stolen data was leaked anyway. Response and disruption costs passed US$870 million.
Lesson: paying does not buy recovery. Closing the door the attackers used, and checking how far they got, matters far more.
The US standards body NIST updated its official incident response guide in April 2025 (SP 800-61 Revision 3). Its message is simple: attacks now happen more often and hurt more, and recovery often takes weeks or months, not the day or two it used to. That is why NIST treats responding and recovering as part of everyday risk management, alongside the other functions of its Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover.
Why panic makes things worse
When people first spot a breach, panic often takes over. Computers get switched off. Passwords are changed in a rush. Someone posts screenshots in a big office WhatsApp group. Nobody writes anything down.
Each of these can destroy evidence, warn the attacker that you have seen them, and leave you unable to answer simple questions later, such as: What was affected? When did it start? What did we do?
The cure is a written plan that your people have read and practised before anything happens. In the first hours, follow the plan, not your instincts.
Your first 24 hours, step by step
Hour 0 to 1: Confirm it, take charge, stay calm
· Check it is real. Is this an attack or an ordinary fault? Roughly how serious does it look?
· Put one person in charge. Call them the Incident Commander. They make the decisions and keep the timeline.
· Talk somewhere safe. If you think email or chat may be hacked, move to a channel the attacker cannot see, such as a small, invite-only group on personal phones for the response team only.
· Write everything down. Who did what, when and why. NIST asks organizations to keep these records and protect them from being changed.
· Do not wipe anything yet. No deleting, reformatting or reinstalling. That destroys the evidence you will need.
Real case: British Library, UK (October 2023). On the morning of 28 October, staff could not reach the Library's network. The technology team followed its major-incident plan, confirmed a cyber-attack, and the Crisis Management Plan was switched on at 09:15. The UK's National Cyber Security Centre was called straight away.
Lesson: because a plan already existed, confusion turned into organised action within hours.
Hour 1 to 4: Stop the spread and find the edges
· Contain it. Cut affected machines off the network, disable hacked accounts and block known bad addresses. Where possible, disconnect rather than power off, so evidence held in memory survives.
· Look beyond the first machine. Attackers rarely stay in one place. Check other systems for signs they have been there, or left a hidden back door. NIST warns that a quick, shallow check can make an incident look smaller than it is and let it carry on unseen.
· Choose your approach and write down why. Do you restore quickly, or watch and investigate further first? Each choice has trade-offs. Record the reasons.
Live example: PHP2Shell (this week). Security experts stress that installing the PHP2Shell fix closes the hole but does not remove anything an attacker already planted. Early attacks have been dropping web shells (hidden back doors) and crypto-mining software, and ransomware groups are reportedly using the flaw to get in.
Lesson: if you run PHP websites and patched late, treat it as a possible breach. Patch first, then hunt for back doors.
Hour 4 to 24: Tell the right people, remove the cause, plan the comeback
· Bring in legal and your Data Protection Officer. In Kenya, a data controller must notify the Office of the Data Protection Commissioner (ODPC) within 72 hours of becoming aware of a personal data breach (section 43, Data Protection Act, 2019). A data processor must tell the controller within 48 hours. A late notice must explain the delay. Other laws and contracts may add duties, so check with your lawyer.
· Remove the cause. Clean out malware and back doors, lock breached accounts, and fix or shield every weakness the attacker used.
· Brief leadership and agree one clear message for staff, customers and regulators.
· Agree the “ready” test before you restore anything. What must be true before a system goes back into use?
Kenya reality check: the regulator is watching. Since the Data Protection Act took effect, the ODPC has issued 357 determinations, 134 enforcement notices and 20 penalty notices (as of January 2026). In late 2025 it ordered Diamond Trust Bank Kenya and DTB Uganda to pay a customer KES 500,000 in compensation after her financial data was disclosed to the wrong person. Penalty notices can reach KES 5 million or 1% of annual turnover, whichever is lower.
Real case: communicating under pressure, Kenya. In July 2023, a flood of fake traffic (a DDoS attack), claimed by a group calling itself Anonymous Sudan, knocked eCitizen, the portal for more than 5,000 government services, offline from 23 July. The ICT Cabinet Secretary publicly confirmed the attack and said no data was accessed, services were back by 27 July, and the government offered visas on arrival while e-visas were down.
In July 2026, hackers defaced the President's official website and demanded five Bitcoin. The government confirmed it the same day, restricted access for forensic checks and said no sensitive data was taken.
Lesson: say what you know, quickly and honestly, and have a manual backup for your most important services.
What recovering well actually looks like
1. Decide when to start recovering. Weigh the disruption of rebuilding against the risk that is still there.
2. Check your backups before you use them. Look for signs of tampering or damage first. A backup taken after the attacker arrived can bring them straight back.
Real case: Maersk and NotPetya (2017). Malware wiped the shipping giant's network, including every domain controller (the servers that hold all staff logins). Without them, nothing could restart. The rescue came by luck: one office in West Africa had lost power during the attack, so its server was offline and untouched. That hard drive was flown to the UK, and Maersk rebuilt in about 10 days, at a cost of roughly US$300 million.
Lesson: keep at least one backup that is offline and cannot be reached from your network, and test that you can actually restore from it. Do not rely on a power cut.
3. Restore in order of importance. Bring back the services the business depends on most first, and confirm with the people who own those systems. An up-to-date list of your systems, ranked by importance, makes this possible.
Real case: Marks & Spencer, UK (2025). Attackers tricked an IT help desk into handing over access with nothing more than a phone call. M&S stopped online orders for 46 days. Home deliveries came back in June, but click-and-collect only returned in August. The retailer estimated a hit of about £300 million to its profits.
Lesson: recovery happens in stages, so decide in advance which services come back first. And train help-desk staff to verify every password-reset request.
4. Check restored systems and fix the root cause before they go back into use.
5. Watch restored systems closely to confirm they are behaving normally.
6. Declare recovery finished against agreed criteria, then write an after-action report: what happened, what you did and what you learned.
Real case: British Library, continued. In March 2024 the Library published an open, 18-page review of the attack, praised by the UK's cyber and data regulators. It also showed how long recovery can take: old “legacy” systems slowed the rebuild, and recovery ran past its planned July 2025 finish date.
Lesson: practise a “everything is down” scenario, and replace old systems before an attacker forces you to.
7. Keep communicating. Staff, customers and, where relevant, the public should hear what you are doing to recover and to stop it happening again.
Your 24-hour card (print it and pin it up)
· Hour 0–1: Confirm. Appoint one leader. Move to a safe channel. Start the log. Wipe nothing.
· Hour 1–4: Disconnect affected systems. Disable hacked accounts. Check beyond the first machine.
· Hour 4–24: Call legal and your DPO (the 72-hour ODPC clock is running). Remove the cause. Agree one message. Set the “ready” test.
· Recovery: Test backups first. Restore in priority order. Fix the root cause. Monitor. Write the lessons down.
The bottom line
No organization can stop every attack. But every organization can recover well: quickly and safely, with evidence preserved, the regulator informed and the root cause fixed. Change Healthcare, Maersk, M&S and the British Library all show the same thing. What happens in the first 24 hours, and how carefully you rebuild afterwards, decides whether a breach becomes a bad week or a bad year. Treat recovery as something you plan and practise, not something you make up on the day, and each incident will leave you stronger.
Need help building or testing your incident response plan? Talk to Us.
📞 Telephone: +254 728 223 333
Email: cybersecurity@southendtech.co.ke | info@southendtech.co.ke | dataprotection@southendtech.co.ke
South-End Tech Limited — Helping East African businesses build secure AI-ready foundations.