If you don't learn from problems, you'll keep making the same mistakes, losing time and money each time. For example, an e-commerce business in Delhi suffered a ransomware attack that locked their inventory system for 3 days, costing ₹5 lakhs in lost sales and refunds. If they had documented what went wrong (unpatched servers, no backups) and fixed it, the second attack could have been prevented entirely—instead they were hit again 8 months later. Without this learning process, you also fail audits when bigger customers or banks ask 'show us your incident response plan'—which can cost you contracts worth crores. Regulators under DPDP Act also expect you to show continuous improvement after any data breach.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no record of incidents or disruptions. When problems happen, people fix them in a panic but nobody documents what went wrong or how to stop it recurring.
Initial
You occasionally write down what happened during major incidents (like a server down or a cyber-attack), but there is no formal process and the information stays with whoever handled it.
Developing
You have a basic incident log where major disruptions are recorded (date, what broke, how long it took to fix), and the owner sometimes talks about what to do differently next time.
Defined
You conduct a formal review meeting after every significant incident, document findings in a simple report, assign action items to staff, and check if those actions were completed within 30 days.
Managed
You maintain a structured incident register with root cause analysis for all events, prioritize improvements based on risk and impact, track remediation progress monthly, and share lessons learned with the team quarterly.
Optimised
You run a continuous learning system where incidents are analyzed deeply, near-misses are reported proactively, improvements are tested and validated, outcomes are shared across the organization, and your incident response keeps getting faster and more effective.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | After the next significant incident (data loss, downtime, security issue, or near-miss), have someone spend 2 hours documenting: what happened, when it happened, how long it took to fix, and what the owner thinks caused it. Save this as a Word or Google Doc. | IT person or Operations manager | 2 hours per incident |
| 1 → 2 | Create a simple incident log spreadsheet (columns: Date, What Failed, Duration Down, Root Cause, Cost Impact, Fix Applied) and enter all past incidents from the last 12 months. Share it in a Google Drive or shared folder so it stays accessible. | IT person | 1 day |
| 2 → 3 | After each incident, schedule a 1-hour review meeting with relevant staff (IT, operations, affected department head). Use a simple template: What happened? Why? What do we do now? Who is responsible? By when? Document decisions and follow up in 2 weeks. | Operations manager or owner | 2-4 weeks (build the habit) |
| 3 → 4 | Upgrade your incident log to include a 'Root Cause Analysis' column where you dig deeper (use the 5 Whys method: Why did the server fail? → No monitoring. Why no monitoring? → We never set it up. Why? → Budget cut.). Track each action item in a separate 'Action Register' with status updates every 2 weeks. | IT person or QA lead | 1-2 months |
| 4 → 5 | Establish a monthly 'Resilience Review' meeting where incidents, near-misses, and completed improvements are discussed. Create feedback loops: ask staff if they spotted any problems that almost happened. Test your fixes in a non-live environment before rolling out. Share lessons in a company newsletter or team huddle. Measure: are incidents trending down? Is recovery time improving? | IT manager, Operations manager, Owner | Ongoing (2 hours monthly + continuous monitoring) |
Documents and records that prove your maturity level.
- Incident log or register (spreadsheet or document) with at least 6-12 months of recorded disruptions, including date, description, resolution time, and impact
- Minutes from at least 2 post-incident review meetings in the last 6 months, showing what was discussed and action items assigned
- Root cause analysis documents for the 3 most serious incidents in the past year (e.g. why the backup failed, why the ransomware got in, why the data was lost)
- Action register or checklist showing follow-up tasks from incidents, with owner names, due dates, and completion status (at least 80% should be marked complete)
- Evidence of change implementation: updated procedures, new tools deployed, or training conducted to address discovered gaps (e.g. 'Server monitoring tool installed on 15-Jan-2024 after Dec incident')
Prepare for these questions from customers or third-party reviewers.
- "Show me your incident log for the past 12 months. What were the top 3 disruptions and how long did they take to resolve?"
- "Walk me through one major incident. What did you find was the root cause, and what specific changes did you make to stop it happening again?"
- "Can you prove those changes were actually implemented? Do you have a way to verify they're working?"
- "When was the last time you reviewed an incident as a team and discussed lessons learned? What came out of that?"
- "Tell me about a near-miss your team caught before it became a real problem. How did that happen and what did you learn?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Simple incident tracking and log management | Google Sheets or Microsoft Excel with a shared drive; also Jira Free (15 user limit) or Trello with custom fields | Freshdesk Incident Management (₹5,000-15,000/year) or Atlassian Jira Standard (₹25,000-50,000/year for small teams) |
| Capture and analyze root causes using structured methods | Google Docs templates (create a '5 Whys' or 'Fishbone' template); Miro or Mural free tier for visual root cause diagrams | Lucidchart (₹5,000/year) for professional cause-effect diagrams; Confluence (₹3,000-8,000/year) for documentation |
| Track action items and remediation progress | Asana free tier (15 team members), Monday.com free tier, or a shared Google Tasks list | Monday.com (₹5,000-10,000/month), Asana Premium (₹2,500-5,000/month for small team), or Microsoft Project (₹4,000-6,000/month) |
| Schedule and document review meetings with templates | Google Meet (video) + Google Docs (meeting notes template); Notion free tier for knowledge base | Microsoft Teams (bundled in Microsoft 365 ₹4,000-8,000/user/year) for meetings and recordings |
| Communicate lessons learned and build organizational memory | Google Drive shared folder with a 'Lessons Learned' document; Slack free tier (message archive limit) for team updates | Confluence (₹3,000-8,000/year) or Notion Team (₹12,000/year) as internal wiki; Slack Pro (₹8,000-10,000/month) |
- Writing incident reports but never reading them again: Many Indian MSMEs document incidents to 'check the box' for audits, then file the report away. Six months later the same issue happens because nobody reviewed the document. Create a mandatory review cycle: every incident report must be discussed in a team meeting within 1 week.
- Blaming the person instead of fixing the process: When a data breach happens because an employee clicked a phishing email, companies often punish the employee and move on. The real lesson is: we have no email security training, no email filter, and no phishing simulation. Fix the process, not just the person.
- Treating near-misses as non-events: A near-miss (for example, a backup drive was found unplugged but data wasn't lost yet) is just as valuable as a real incident. Many Indian businesses ignore near-misses because 'nobody was hurt.' But near-misses are free warnings—use them. Create a simple hotline or anonymous reporting system so staff feel safe reporting 'almost problems'.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(2) requires fitness assessment and continuous improvements; Section 13 mandates data breach notification and post-incident corrective action |
| CERT-In Directions 2022 | Direction 4 requires incident reporting; Direction 5 implies post-incident review and documentation of remediation measures |
| ISO 27001:2022 | Clause 8.3 (response to information security incidents) and Clause 8.3.5 (post-incident evaluation/review); Annex A.5.23 (information security incident management) requires documented improvements |
| NIST CSF 2.0 | Recover Function (RC): RC.RP-1 (post-incident procedures) and RC.IM-1 (improvements implemented); also Respond Function (RS) component |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →