If your incident response plan sits in a drawer and is never reviewed, when a real attack happens—like ransomware hitting your accounting files or customer payment data being stolen—your team won't know what to do. This leads to wasted hours figuring out responses, delayed reporting to customers and regulators (which can result in penalties under DPDP Act), potential loss of customer trust and contracts, and sometimes regulatory fines from bodies like CERT-In or your industry regulator. A real example: a Delhi-based e-commerce company suffered a data breach but had no tested plan; they took 45 days to notify customers instead of the required timeframe, faced customer lawsuits, and lost two major contracts worth ₹80 lakhs combined.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You don't have a documented incident response plan at all, or if you do, no one remembers where it is or when it was last looked at. When a security problem occurs, your team responds reactively without any structured approach.
Initial
You have a basic incident response plan written down, but it was created more than 12 months ago and hasn't been reviewed, updated, or tested since then. The contact list might be outdated and roles are unclear.
Developing
You have an incident response plan that was reviewed and updated within the last 12 months, with current contact numbers and defined roles. However, it hasn't been tested through a drill or simulation, so you're not sure if it actually works in practice.
Defined
You have a current incident response plan (reviewed in last 12 months) with clear roles, responsibilities, and escalation paths, and you've conducted at least one tabletop exercise or partial test to validate it. Team members know their responsibilities but a full-scale test hasn't been done.
Managed
Your incident response plan is reviewed every 6 months, includes detailed procedures for different incident types (ransomware, data breach, service outage), and you've conducted a full simulation or drill involving key team members and documented lessons learned. The plan is accessible and communicated to relevant staff.
Optimised
Incident readiness is reviewed quarterly with documented evidence of changes made; you conduct annual full-scale drills involving IT, management, legal, and external parties (customers, regulators where applicable); lessons are tracked and incorporated; and the plan evolves based on new threat intelligence and lessons from industry incidents. Regular metrics show response time improvements.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Document a basic incident response plan covering: what to do when you discover a security issue, who to call first (IT lead, MD, legal), where to log the incident, and initial steps to contain the problem. Include current contact numbers and a one-page summary of roles. | IT Lead or designated Owner (possibly external consultant) | 3-5 days |
| 1 → 2 | Review the existing plan; update all contact numbers, add current staff names and roles, verify technical details (systems covered, backup locations, customer notification templates), and document the review date. Have MD or audit head sign off. | IT Lead with sign-off from Management | 1 week |
| 2 → 3 | Conduct a tabletop exercise: gather key people (IT, finance, management, customer service) and walk through a realistic incident scenario (e.g., ransomware demand email received) to test the plan. Document what worked, what didn't, and update the plan with findings. | IT Lead (facilitator) with cross-functional team | 2-3 weeks including planning, execution, and documentation |
| 3 → 4 | Expand the plan to cover different incident types (ransomware, data theft, service outage, insider threat); create detailed runbooks for each; include communication templates for customers and regulators; establish a structured incident log and metrics (detection time, containment time, notification time). Train team on responsibilities. | IT Lead with external consultant if budget allows | 4-6 weeks |
| 4 → 5 | Establish a quarterly review cadence with documented meeting notes; conduct at least one full-scale simulation annually involving customers or regulators if applicable; track and trend incident response metrics; align updates with emerging threats (industry advisories, CERT-In alerts); maintain a lessons-learned register. | IT Lead, Management, and designated Incident Commander role | Ongoing: 4-6 hours per quarter for reviews, 1-2 weeks for annual drill |
Documents and records that prove your maturity level.
- Dated incident response plan document with version number and approval signature from management or board
- Evidence of review (email chain, meeting minutes, or sign-off form) within the last 12 months showing what was reviewed and any changes made
- Tabletop exercise or drill report including date, participants, scenario used, findings, and action items taken
- Current incident response contact list with names, roles, phone numbers, and email addresses; separate list for escalation (MD, legal, external vendors)
- Incident log or tracker showing at least one incident (real or simulated) with timestamps for detection, notification, containment, and resolution
Prepare for these questions from customers or third-party reviewers.
- "When was your incident response plan last reviewed, and can you show me the documented evidence of that review?"
- "Walk me through what your team would do in the first hour after discovering ransomware on your main server—who do you call, what's your first action, and where are those instructions written?"
- "Has your incident response plan been tested with a drill or simulation? If yes, what was the date and what did you learn that caused you to change the plan?"
- "Show me your current incident response contacts—are these names and numbers accurate, and does everyone on this list know they're on it and what they're supposed to do?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and store your incident response plan with version control and approval workflow | Google Docs (with access controls) or LibreOffice Writer | Microsoft 365 (₹2,500–6,000/user/year) with SharePoint for centralized storage and change tracking |
| Document and track incidents: detection time, who was notified, actions taken, timeline | Google Sheets or LibreOffice Calc with manual updates | Atlassian Jira (₹7,000–25,000/year for small team) or ServiceNow (₹60,000+/year, usually overkill for MSMEs) |
| Conduct tabletop exercises and document findings, assign and track remediation actions | Google Forms for feedback + Google Sheets for tracking; Trello free tier for task assignment | Monday.com (₹3,000–8,000/month) or Asana (₹2,000–6,000/user/month) for structured exercise management |
- Plan-in-a-drawer syndrome: Writing the plan once and then never looking at it because the IT person left, roles changed, or no one made it a reminder. In India, high staff turnover in IT means outdated contact lists and forgotten procedures within 6–12 months.
- No clear owner or accountability: The plan exists but no one is assigned responsibility for keeping it current or running drills. Without a named 'Incident Commander' or owner, reviews keep getting pushed back and never happen.
- Plan is too complex or written by external consultant without team input: A 50-page plan written by a consultant that the team doesn't understand or buy into sits unused. MSMEs often lack the resources to execute enterprise-level playbooks.
- No involvement of non-IT stakeholders: The plan only covers IT actions and ignores what finance, HR, customer service, or management should do. Real incidents require coordination across departments, and a plan that only addresses technical steps is incomplete.
- Confusing 'having a plan' with 'testing the plan': Many businesses assume that once the plan is documented, they're compliant. Without at least one drill or tabletop exercise, no one knows if the plan actually works or if contact numbers are even correct.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Reasonable security practices and procedures) and Section 6 (Data Protection Officer responsibilities for incident management) |
| CERT-In 2022 Directions | Rule 3 (incident reporting timelines and process) - entities must have procedures to detect, respond, and report incidents |
| ISO 27001:2022 | Clause 5.23 (Information security incident management) and Annex A Control 5.23 |
| NIST CSF 2.0 | Respond function (RS) - particularly RS.RP-1 (Response plan is executed) and RS.CO-1 (Incident response is coordinated) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →