An incident response plan is the thing you least want to be writing at 2 a.m. while an attacker is already inside your systems. Yet that is roughly what happened to America's top cyber-defence body. According to TechCrunch, the Cybersecurity and Infrastructure Security Agency (CISA) admitted it "missed" a chance to get ahead of a security incident by not having a response plan ready before it happened.
Sit with that for a second. The agency whose entire job is telling everyone else to be prepared got caught improvising its own playbook mid-fire. If it can happen to CISA, it will happen to your three-person startup in Colombo. So let me turn this into something useful instead of a dunk.
🔍 Why the plan has to exist before the fire
The failure here is not technical. It is a planning failure, and planning failures are the cheapest ones to fix. When you write your response steps during an incident, three things go wrong at once:
- You make decisions under stress. Adrenaline is bad for judgement. Who do we call, do we take the box offline, do we tell users yet? These are hard questions that get worse when you are panicking.
- Nobody knows their role. Two people fix the same thing, a third thing gets ignored.
- You lose evidence. In the scramble, someone reboots the compromised server and wipes the logs you needed.
Key takeaway: A runbook written calmly on a normal Tuesday is worth ten decisions made in a panic. The whole value of the plan is that it exists before you need it.
The point of a plan is not that it predicts the exact attack. It never will. The point is that it removes the easy decisions from your plate so your brain is free for the hard ones.
🛠️ The one-page runbook a small team can actually write today
You do not need a 40-page corporate document. You need one page that answers "what do we do in the first hour." Here is a starter you can adapt.
| Phase | Question to answer in advance | Who owns it |
|---|---|---|
| Detect | How do we even know something is wrong? (alerts, a user report, a weird login) | On-call dev |
| Contain | Do we isolate the machine or pull it offline? What breaks if we do? | Tech lead |
| Preserve | Before we touch anything, do we snapshot logs and disk? | Tech lead |
| Communicate | Who tells users, and after how long? Who talks to press if it's public? | Founder |
| Recover | How do we restore from a known-good backup? Where is it? | Whoever set up backups |
| Review | When it's over, who writes the post-mortem? | Everyone, blameless |
Print it. Pin it in your team chat. The test of a good runbook is simple: could a tired teammate follow it at 2 a.m. without calling you?
💡 Free-tier and open-source tools that make this real
A learning budget is not an excuse to skip this. Almost every piece can be free.
- Backups you have actually tested. An untested backup is a rumour. Restore it once to prove it works.
- A secure way to share credentials during an incident. Do not paste the root password into a group chat that logs forever. Use a self-destructing link. Our own one-time secret tool exists for exactly this: the link opens once, then the data is gone.
- A password manager so a compromised account can be rotated in minutes, not hours.
- Log storage off the affected box. If logs only live on the server that got popped, the attacker controls your evidence.
- A written contact list with phone numbers, not just Slack handles. Slack might be the thing that is down.
Free templates exist too. CISA and other national bodies publish incident-response guidance for public use. Start from one, then cut it down to fit a team your size.
📊 What CISA got right by saying it out loud
Here is the part I respect. Admitting "we missed this" in public is itself a security practice. Most organisations bury the lesson. A blameless post-mortem that names the gap is how you stop repeating it.
| Reaction to a mistake | What it produces |
|---|---|
| Hide it, blame an individual | The same gap, again, next quarter |
| Name the gap, fix the process | A plan that exists before the next incident |
For a Sri Lankan team building software for local banks, telcos, or government, this matters more than usual. Trust is the whole product. The team that can honestly say "here is what we learned and here is what we changed" recovers faster than the one that pretends it never happened.
🚀 What this means for you
You are not CISA. You have fewer people, less money, and a smaller attack surface. That is an advantage, because your plan can be one page instead of a binder. Do this before you close this tab:
- Open a shared doc and paste the six-phase table above.
- Fill in real names next to each role. If you are a solo founder, your name goes in every row, and that is a risk worth knowing about.
- Write down where your backups live and when you last restored one.
- Save a secure-sharing link and a contact list somewhere that survives your main system going down.
Bottom line: The most powerful cyber agency in the world got caught without a plan. The fix is not more budget or fancier tools. It is thirty minutes on a calm day. Spend them now, before the incident writes your playbook for you.
Top comments (0)