If you don't learn from incidents, you'll keep getting hit by the same attacks—wasting money on repeated damage control instead of prevention. For example, a Delhi manufacturing firm got ransomware through weak passwords twice in 18 months because they never documented or acted on the first incident; the second attack cost them ₹15 lakhs in recovery and lost orders. A compliance auditor or customer (especially if you work with banks or e-commerce) will fail you if you can't show you're improving. Repeated incidents also destroy customer trust and can trigger regulatory fines under DPDP Act if you can't prove you're taking data breaches seriously.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You've had a security incident but there's no written record of what happened or what you did about it. If someone asks what went wrong, the owner or IT person gives a vague explanation from memory.
Initial
You write down what happened when an incident occurs (e.g., 'email hacked on 5 Jan'), but there's no formal process to figure out the root cause or plan fixes. The notes sit in a folder and aren't reviewed.
Developing
You document incidents with some detail (when, what system, rough impact) and the IT person sometimes talks about what caused it, but there's no formal meeting or assigned follow-up actions. Learning happens by accident, not design.
Defined
You have a basic incident log with date, impact, and root cause analysis for each incident, and the IT person regularly checks it and suggests fixes (e.g., 'we should change that password policy'). However, not all fixes get approved or tracked to completion.
Managed
You maintain a formal incident log, conduct a structured root cause analysis for each significant incident, document what was fixed, and track remediation tasks to closure. You review incidents at quarterly management meetings and share key lessons with the team.
Optimised
Incident review is embedded in your security operations; every incident triggers a documented root cause analysis, corrective action is tracked and verified, lessons are shared across the organization, and you proactively hunt for similar weaknesses before they cause the next incident.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Create a simple incident log template (spreadsheet with columns: Date, Affected System, What Happened, Initial Impact, Notes) and commit to documenting every security issue from now on, no matter how small. | IT person or business owner | 2 hours |
| 1 → 2 | Add two more columns to the log: 'Root Cause' and 'Action Taken', and after each incident, spend 30 minutes investigating why it happened before moving on. Keep the log visible and review it every month. | IT person | 1 week to establish habit |
| 2 → 3 | Formalize a 1-hour post-incident review meeting (even for small incidents); invite the IT person, relevant team member, and owner. Document who attended, what was decided, and assign one person to implement each fix with a due date. | IT person and business owner | 2-4 weeks (one meeting per incident) |
| 3 → 4 | Add a 'Verification' column to track whether fixes were actually completed and tested; conduct a quarterly review meeting where you look back at all incidents in the past 3 months, confirm all actions are done, and discuss trends (e.g., 'we had 3 phishing incidents—do we need more training?'). | IT person and business owner | 1-2 months (2 hours per quarter plus ongoing tracking) |
| 4 → 5 | Automate incident detection alerts (e.g., failed login attempts, backup failures), correlate incidents to identify patterns before they cause damage, share lessons learned with staff through monthly security updates, and conduct an annual security review to identify and close systemic gaps. | IT person with possible external consultant support | Ongoing (2-3 hours per week) |
Documents and records that prove your maturity level.
- Incident log or register with at least 5 entries (past 12 months) showing date, description, root cause, and corrective action
- Meeting minutes or notes from at least one post-incident review showing attendees, discussion, and assigned actions with due dates
- Evidence of at least one completed fix (e.g., email from IT confirming a password policy was updated, or a screenshot showing a software patch was installed) linked to an incident
- Quarterly or annual trend analysis document showing that you've reviewed incidents over time and identified patterns (e.g., 'phishing is our top risk')
- Staff communication (email, memo, or training record) showing that lessons from a past incident were shared with employees to prevent repetition
Prepare for these questions from customers or third-party reviewers.
- "Walk me through the last three security incidents you've had. How did you figure out what went wrong, and what did you change afterward?"
- "Can you show me your incident log and tell me which past incidents led to actual security improvements in your systems or processes?"
- "Have you ever had the same type of incident twice? If yes, why did it happen again, and what did you do differently the second time?"
- "If I find a security weakness in your company today, how would you ensure it doesn't happen to someone else's company you might merge with or work closely with? Do you share lessons learned externally?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Document and track security incidents with root cause analysis and corrective actions | Google Sheets or Microsoft Excel template (create your own or search 'incident log template'); also Jira free tier (for small teams) | Atlassian Jira (₹1,200–3,000/year for small team) or ServiceNow (starts ₹5,000+/month but overkill for MSME) |
| Identify if the same incident is happening elsewhere in your systems (pattern detection) | Windows Event Viewer (built-in), grep/awk commands in Linux, or ELK Stack (open-source: Elasticsearch, Logstash, Kibana) | Splunk (starts ₹3,000+/month), DataDog (₹5,000+/month) |
| Automated alerts for suspicious activity so incidents are caught faster and lessons can be applied | OSSEC (open-source host-based intrusion detection), Fail2Ban (brute-force login protection) | Wazuh cloud (₹2,000–8,000/month depending on data volume), Microsoft Defender for Business (₹350–700/month per user) |
- Treating incident response as a one-time event: owner or IT person fixes the immediate problem but never sits down to ask 'why did this happen?' and 'how do we prevent it?' A quick fix feels like success but repeats the vulnerability.
- Blaming external factors only: saying 'we got hacked because the attacker was sophisticated' instead of asking 'what gap in our security did they exploit?' Shifting blame prevents learning and improvement.
- Not documenting incidents because they seem small or the owner is embarrassed: a 'minor' incident (like an employee opening a phishing email) is often the first signal of a bigger problem; hiding it means you miss the chance to train staff or improve email filters.
- No accountability for follow-up: fixes are discussed in a meeting but no one is assigned responsibility or a deadline; six months later nothing has changed and a similar incident happens again, frustrating everyone.
- Keeping incident knowledge only in the IT person's head: if that person leaves, all lessons go with them; a new hire makes the same mistakes because there's no documented history to learn from.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 7 (Data Fiduciary obligations); Section 8 (principles of data processing including accountability); Schedule 1 (guardrails for high-risk processing—incident review is part of demonstrating due diligence) |
| CERT-In Guidelines 2022 | Direction 4 (incident reporting); Direction 6 (security audit and assessment); implies organizations must learn from incidents to reduce future risk |
| ISO 27001:2022 | Clause 8.2.4 (incident management); Annex A Control A.16.1 (planning and preparation for incident response); A.8.3.4 (event logging and monitoring for improvement) |
| NIST CSF 2.0 | Detect function (DE.DP-1: detect anomalies, DE.DP-4: malware is detected); Respond function (RS: incident handling and communication); Recover function (RC: business continuity and lessons learned from incidents) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →