Incident response for teams that don't have a security team

It is 2 a.m., a customer emails to say their data looks exposed, and nobody on your team has ever run a security incident. What happens in the next hour decides how bad this gets, both technically and legally, and improvising is how small incidents become disasters. You do not need a security team to handle this well; you need a simple plan agreed in advance. This article is that plan, sized for a startup with no dedicated security staff.

The problem

Without a plan, an incident turns into chaos: engineers start deleting things and destroying the evidence you will later need, nobody knows who decides whether to take the service offline, the wrong person tells customers the wrong thing, and in India you quietly miss CERT-In's six-hour reporting window without realising it existed. The damage from a breach is often less about the initial compromise and more about the panicked, uncoordinated response that follows.

Why it happens

Incident response feels like something only big companies with security operations centres do, so small teams skip it until they need it, which is the worst possible time to design it. The mechanism is simple: under stress, people default to action, and uncoordinated action during an incident makes things worse. A plan works not because it is clever but because it replaces panic with a short list of pre-agreed decisions, made calmly, before the adrenaline.

A plan that fits on one page

You can write your entire incident response plan in an afternoon. It needs five parts.

1. Roles

Decide, now, who does what during an incident:

• Incident lead — one person who runs the response and makes the calls. Not a committee.
• Technical lead — investigates and contains, on the systems.
• Communications — handles customers, and internal updates.
• Legal/compliance — owns regulatory duties like CERT-In reporting. In a small team, one person may wear two hats, but each hat must have a name.

2. A short runbook

The first-hour steps, written down so nobody has to think them up at 2 a.m.:

• Detect and confirm. Is this real? What is the evidence?
• Contain, do not destroy. Isolate affected systems (revoke keys, block access, take a snapshot) but preserve evidence — do not wipe or rebuild before you have captured logs and images. You will need them for the investigation and possibly for regulators.
• Assess scope. What data and systems are affected? Whose data?
• Notify. Trigger the communications and legal steps below.
• Recover. Restore from known-good backups only after you understand how they got in, so you do not restore the hole too.

3. Communications

Draft the templates now, calmly: what you tell customers, what you tell your team, and who approves the wording. Vague or premature statements cause as much damage as silence. The rule is one source of truth and no speculation.

4. Regulatory duties (India)

Under CERT-In's 2022 directions, organisations must report certain cyber incidents to CERT-In within six hours of noticing them, and retain relevant logs for 180 days. Six hours is not much time to discover a process, so the reporting path — who files, how, and with what information — must be decided in advance. If you handle personal data, India's Digital Personal Data Protection Act adds its own breach-notification duties. Know which apply to you before you need them.

5. Evidence and review

Keep a timeline of everything done during the incident. Afterwards, run a blameless review: what happened, what worked, what to change. The goal is a slightly better plan each time, not someone to blame.

Practise before it is real

A plan you have never rehearsed will not hold under stress. Run a tabletop exercise once a quarter: sit the team down, describe a scenario ("a developer's laptop with production access is stolen"), and talk through who does what, step by step. These take an hour, cost nothing, and reliably expose the gaps — a missing phone number, an unclear decision owner, a backup nobody has tested — while it is still cheap to fix them.

What to do this week

• Write the one-page plan: name the incident lead and the other three roles.
• Draft the first-hour runbook, emphasising "contain, preserve evidence, then recover."
• Confirm your CERT-In reporting path and who files within the six-hour window.
• Draft the customer and internal communication templates in advance.
• Book a one-hour tabletop exercise and run one scenario end to end.

When to bring in a partner

Some incidents need hands you do not have at 2 a.m. VA2PT provides 24x7 SRE and NOC coverage and managed security so there is always someone watching and someone to call, and our team can help you write, rehearse and, when it matters, run the response. Preparing the plan with a partner who has handled real incidents is far cheaper than learning during your first one.