If your incident response plan lists names and phone numbers of people who have already left, or describes systems that no longer exist, then when a real security emergency happens—like a ransomware attack or data breach—nobody knows who to call or what to do. For example, an e-commerce business in Bangalore suffered a customer data breach but their response plan only had the old IT manager's contact, who had left six months earlier; the company wasted three critical hours finding the right person to lead the response, during which attackers exfiltrated more data. Without updated plans, you also fail compliance audits, lose customer trust, and face regulatory penalties under the DPDP Act for not having a working incident response capability.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no incident response plan at all, or it exists but has never been reviewed. Nobody in the organization has formal roles assigned for handling security incidents.
Initial
You have a basic incident response plan with assigned roles written down, but nobody checks it even when staff leave or major systems change. The document sits in a folder and is forgotten.
Developing
You update the incident response plan when major staff changes occur (CEO, IT head leaving), but you do not systematically review roles when junior staff change or when systems are upgraded. Updates happen by accident, not by design.
Defined
You have a defined process: when any staff member leaves or joins, HR notifies the IT manager, who updates the incident response plan within two weeks. You also review the plan annually and update it when major new systems go live.
Managed
You maintain a live contact list linked to your incident response plan that is updated in real time when staff changes happen through your HR system. You test whether the updated roles work by conducting quarterly incident drills.
Optimised
Your incident response plan is automatically updated through integration with your HR and IT asset management systems whenever roles change. You conduct monthly incident response drills that validate the current plan, and you track metrics on response effectiveness over time.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Write down a simple one-page incident response plan naming who is responsible for detection, communication, containment, and recovery. Include mobile numbers and email addresses. Get the owner to sign it. | IT Manager or Owner | 1 day |
| 1 → 2 | Add a sentence to your HR offboarding checklist: 'Notify IT Manager of departing staff so incident response plan can be updated.' Create a simple log where IT Manager records each update with date and who changed. | HR Manager and IT Manager | 2–3 days |
| 2 → 3 | Create a formal annual review process: schedule one day every January to review the entire incident response plan against current staff list and system inventory. Document what was checked and what was changed. Add a clause that any staff change (not just leadership) triggers a plan review within 2 weeks. | IT Manager with Owner approval | 1–2 weeks (first time), then 2 days/year |
| 3 → 4 | Create a master contact list (spreadsheet or simple database) with all incident response roles, names, mobile numbers, and email. Link it to your incident response plan. Every time HR adds or removes staff, they update this list. Run a tabletop incident simulation every quarter to verify the plan works. | IT Manager (owns list), HR Manager (triggers updates) | 2–4 weeks (first time), then 2 hours per staff change + 1 day per quarter for drills |
| 4 → 5 | Integrate your HR system and IT asset management system so that when a staff member is marked as 'left' in HR, their contact is automatically removed from the incident response plan. Log all drills and measure response time, escalation speed, and action accuracy. Use drill results to improve the plan. | IT Manager with vendor or consultant support | Ongoing: 1–2 months to set up, then 2 hours/month to monitor and improve |
Documents and records that prove your maturity level.
- Current incident response plan document dated and signed, with role names and contact details for all staff assigned to incident response duties
- A log or register showing dates when the incident response plan was reviewed (e.g., HR change log linked to plan updates, or a review sign-off sheet)
- Evidence of a formal review process (e.g., written procedure stating when and how the plan is reviewed, e.g. annually or whenever staff changes)
- Records of staff changes communicated to the incident response team (e.g., email from HR to IT Manager saying 'X has left, remove them from incident response'; or offboarding checklist signed)
- Evidence of incident response drills or tabletop exercises that tested the current plan and validated that named roles are accurate and reachable
Prepare for these questions from customers or third-party reviewers.
- "Show me your current incident response plan. When was it last reviewed and updated?"
- "Walk me through how you notify the incident response team when staff leave or join. Show me evidence of a recent staff change and how the plan was updated."
- "If I called the mobile number listed for your incident response lead right now, would that person still be at your organization? How do you ensure contact details are current?"
- "Do you test your incident response plan after staff or system changes? If yes, when was the last test, and what did you find?"
- "Show me your process for reviewing incident response roles when major systems are upgraded or replaced. When did you last do this?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Store and version-control incident response plan; track review dates and who approved each version | Google Docs or Microsoft Word with version history enabled; plus a shared spreadsheet for contact tracking | Confluence or Notion (₹1,500–3,000/user/year) for collaborative documentation |
| Maintain a live, searchable contact list and role matrix for incident response team; link to HR data if possible | Excel or Google Sheets with conditional formatting and email validation | Freshworks HR (₹5,000–15,000/month) or Zoho People (₹2,000–8,000/month) with API integration to incident response system |
| Schedule and run incident response tabletop drills; document findings and plan improvements | Google Calendar + Google Forms to record drill feedback; Jotform for drill checklists | SANS Cyber Aces or Incident Response Simulation Platform (₹50,000–200,000/year for SME bundles) |
- The incident response plan is created as a one-time exercise during a compliance audit, then filed away and never touched again. When staff leave, nobody remembers to update it, and the plan becomes useless within months.
- HR and IT do not communicate. When someone is fired or resigns, the IT Manager is not informed, so the plan still lists them as a key responder. During an actual breach, critical time is wasted trying to reach someone who no longer works there.
- The plan lists job titles (e.g., 'Network Admin') but not names, or lists names without current phone numbers. When an incident happens, the team cannot find the right person quickly.
- Management believes that updating the plan is a one-person job for the IT Manager and does not allocate time or budget for it. The IT Manager is too busy with daily work to do annual reviews, so the plan drifts out of date.
- After hiring a consultant or new vendor, nobody updates the incident response plan to include them or hand over their responsibilities, leading to gaps or unclear handoffs during an emergency.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 4(11) and Schedule 1: Data Fiduciaries must have defined roles and responsibilities for data protection; incident response capability is part of accountability |
| CERT-In Guidelines 2022 | Rule 4 (Critical Infrastructure): Organizations must define incident response roles, escalation contacts, and update them when systems or staff change |
| ISO 27001:2022 | Clause A.16.1 (Planning of Information Security Incident Management): requires planning and assigning incident response roles; A.16.5 requires periodic assessment of the incident response capability |
| NIST CSF 2.0 | Respond (RS) function, RS.CO-1 and RS.CO-2: Execute incident response plan and update it based on organizational changes |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →