Incident Response Plan: A Step-by-Step Template for SMBs

An incident response plan is a documented, pre-agreed procedure that tells an organisation exactly who does what, in what order, within minutes of discovering a breach, ransomware infection, or data leak — instead of improvising under pressure. For Indian SMBs, a workable plan follows the NIST SP 800-61 lifecycle (Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity), assigns roles through a RACI matrix, sets escalation thresholds, and builds in India's CERT-In requirement to report specific incident categories within 6 hours of noticing them. This guide walks through each phase with a ready-to-adapt template outline.

Why Most Indian SMBs Don't Have One

Ask most Indian SMB founders if they have an incident response plan and the honest answer is usually "we'll figure it out when it happens." That works for a printer outage. It does not work when a ransomware note appears on forty laptops at 2 AM, or a support engineer spots customer records being exfiltrated and nobody knows whether to unplug the server, call the bank, or call a lawyer first. The absence of a plan doesn't prevent incidents — it guarantees the response is slower, costlier, and more likely to miss a legal deadline.

A written plan converts a panic scenario into a checklist. It doesn't need to be a hundred-page document modelled on a bank's; it needs to answer four questions before an incident happens, not during one: who gets called first, who has authority to isolate a system, what gets reported and to whom, and how is evidence preserved.

The NIST SP 800-61 Lifecycle, Adapted for SMBs

The NIST SP 800-61 Computer Security Incident Handling Guide is the most widely referenced incident response framework globally, and its four-phase lifecycle scales down to a five-person IT team as well as it scales up to an enterprise SOC.

Phase 1: Preparation

This is the phase most SMBs skip entirely: an up-to-date asset inventory, a contact list that works at 3 AM, pre-arranged access to a digital forensics resource, backup systems tested for actual restore capability, and this document itself, signed off by leadership.

1. Maintain a current inventory of critical systems, data stores, and their business owners.
2. Pre-identify an external incident response or forensics contact — arranging this after a breach starts costs hours you don't have.
3. Test backups by restoring them, not just by checking the backup job succeeded.
4. Define what counts as an "incident" versus routine noise, so the team isn't paralysed deciding whether to escalate.

Phase 2: Detection and Analysis

Detection is spotting that something is wrong — an unusual login, a spike in outbound traffic, a ransomware note, or an alert from a monitoring tool. Analysis is the fast triage that follows: is this real, how bad is it, and what category (malware, unauthorised access, data exfiltration, denial of service, insider misuse)?

The category matters immediately because it determines the CERT-In reporting clock and which playbook to follow. Under-classifying an incident in the first hour is the most common reason SMBs miss their reporting window.

Phase 3: Containment, Eradication, and Recovery

Containment stops the bleeding — isolating systems, disabling compromised accounts, blocking malicious IPs — without destroying evidence needed later. Eradication removes the root cause: the malware, the unauthorised account, the exploited vulnerability. Recovery restores systems from clean, verified backups, with monitoring to confirm the attacker hasn't regained access.

Never skip short-term containment (isolate, image the disk) in the rush to eradicate — deleting malware before imaging destroys evidence a forensics investigation or insurance claim later needs.

Phase 4: Post-Incident Activity

The phase every deadline-driven team is tempted to skip once systems are back up. A short "lessons learned" review — what worked, what didn't, what would make detection faster next time — should happen within one to two weeks of closure, while details are fresh, and is also when the plan gets updated with what the incident revealed.

Roles and RACI: Who Does What

The most common reason an SMB response stalls in its first hour isn't technical — it's that nobody knows who's allowed to shut down a production server, or who talks to a customer whose data was exposed. A RACI matrix (Responsible, Accountable, Consulted, Informed) fixes this before it becomes a live problem.

Escalation Thresholds

Not every alert is an incident. Define severity tiers in the plan itself:

1. Low — contained to a single non-critical system, no data exposure suspected. Handled by IT lead, logged, reviewed at next team sync.
2. Medium — customer-facing system affected or data exposure suspected but unconfirmed. IT lead escalates to founder/CEO within the hour.
3. High — confirmed data breach, ransomware, or system compromise affecting critical infrastructure. Immediate escalation to founder, legal, and external IR partner; CERT-In reporting clock starts.

The CERT-In 6-Hour Reporting Obligation

Under India's CERT-In Cyber Security Directions of April 2022, issued under Section 70B of the IT Act, 2000, service providers, intermediaries, data centres, and body corporates operating in India must report specified categories of cyber incidents to CERT-In within 6 hours of noticing the incident — one of the shortest mandatory reporting windows globally. The clock starts from when the organisation notices or is notified, not from when it's fully confirmed or contained, which is why detection and analysis needs to move fast and err toward escalation.

The directions cover a defined list of incident types — targeted scanning of critical systems, unauthorised access, data breaches, ransomware, denial-of-service attacks — not every minor security event. Organisations must also maintain and provide logs (ICT system logs, within India, for 180 days) when CERT-In requests them, which is why evidence-handling discipline needs to be routine, not improvised.

Communication and Evidence Handling

Two disciplines separate an organised response from a chaotic one, and both need to be decided in advance.

Communication should follow a single approved channel with one designated spokesperson — usually the founder or a communications lead, briefed by IT and legal — so customers, partners, and regulators get consistent information instead of conflicting statements. Internal communication about an active incident should move to an out-of-band channel, not the potentially compromised email or chat system, to avoid tipping off an attacker who may still have access.

Evidence handling determines whether a later forensic investigation, insurance claim, or law enforcement referral is even possible. Before any system is wiped, capture: a timestamped log of every action taken, a disk or memory image where feasible, relevant logs pulled before rotation deletes them, and a documented chain of custody.

Estimated Effort Across the Response Lifecycle

Based on typical SMB incident handling, most of the actual working hours land in containment/eradication and detection/analysis, not in the initial preparation or final review:

Ready-to-Adapt Incident Response Plan Template Outline

Use this as the skeleton for your own document — fill in names, thresholds, and contacts specific to your organisation:

1. Document control — version, owner, last and next review date.
2. Purpose and scope — systems, data, and locations covered.
3. Roles and RACI matrix — named individuals, not just titles, with 24x7 contacts.
4. Severity classification — low/medium/high thresholds and who declares each.
5. Detection sources — monitoring tools, alert channels, how employees report incidents.
6. Phase-by-phase playbooks — one page each for ransomware, phishing-led compromise, data exfiltration, and DDoS.
7. CERT-In and regulatory reporting — who files, the 6-hour checklist, log retention.
8. Communication plan — escalation path, external spokesperson, notification template.
9. Evidence handling checklist — imaging, log preservation, chain of custody.
10. External contacts — legal counsel, cyber insurer, external IR/forensics resource, and where relevant, a CERT-In empanelled partner for formal reporting support.
11. Post-incident review template — timeline, root cause, what worked, plan updates required.

Making the Plan Real

A document sitting in a shared drive that nobody has read is not an incident response plan — it's a liability with a table of contents. It becomes real only when it's reviewed with the people named in the RACI matrix and updated every time something changes: new systems, new team members, a near-miss that revealed a gap.

Bachao.AI helps Indian SMBs identify the vulnerabilities that most often trigger the incidents this plan is built to handle, so preparation starts with knowing your actual exposure. Dhisattva AI Pvt Ltd built the platform for teams that need continuous security visibility without a dedicated in-house SOC.

Want to know what an attacker could actually reach in your environment before you need this plan for real? Get a free VAPT scan, read more on the blog, or check our DPDP compliance guide if your plan needs to cover personal data breach notification too.