Without incident documentation, you repeat the same mistakes, lose track of patterns that show you're under attack, and cannot prove to regulators or customers that you handled a breach properly. If a customer's payment data is stolen and you have no record of when you discovered it or what you did, you face DPDP Act fines (up to ₹5 crore), loss of customer trust, and possible legal action. An audit by a large client or bank will immediately fail if you cannot show incident logs. A textile exporter in Tamil Nadu who suffered ransomware but had no incident record could not prove timely notification to customers, resulting in contract penalties and reputational damage.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no written record of incidents at all. When something breaks, people discuss it verbally, maybe send a WhatsApp message, and move on.
Initial
Someone occasionally writes a brief note in an email or notebook about what went wrong, but there is no standard format and most incidents are forgotten within days.
Developing
You have a simple incident log (spreadsheet or notebook) that records the date, what happened, and who fixed it, but it is not always filled in and nobody reviews it.
Defined
You maintain a consistent incident log in a spreadsheet with defined columns (date, description, impact, root cause, resolution), and your IT person or manager reviews it monthly to spot patterns.
Managed
Incidents are logged in a simple ticketing system or form with structured data, a clear process for reporting, regular review by leadership, and documented lessons learned stored in a shared location.
Optimised
Incident documentation is automated where possible, tied to your broader risk and audit processes, reviewed in real time for emerging threats, and used to drive regular security training and process improvement.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Create a one-page incident reporting template in Microsoft Word or Google Docs with fields: Incident Date, What Happened, Who Reported It, Initial Impact, and Actions Taken. Print copies or save a template in a shared folder. | Owner or IT Manager | 2 hours |
| 1 → 2 | Set up a simple Excel spreadsheet or Google Sheet with columns for Date, Description, Affected Systems/Data, Severity (Low/Medium/High), Root Cause, Resolution, and Date Closed. Establish a rule that any IT issue or security event must be logged here within 24 hours. | IT Manager or designated admin | 1 day |
| 2 → 3 | Standardize the incident log with clear definitions (e.g., what counts as an incident), add a column for lessons learned, and schedule a monthly 30-minute review meeting where the IT person presents incidents to the manager or owner. Document any trends or repeat issues. | IT Manager and Owner/Operations Lead | 1 week |
| 3 → 4 | Migrate to a free or low-cost ticketing system (such as Zoho Desk, Freshdesk free tier, or even Google Forms with automated logging). Create a formal incident response procedure document that defines roles, escalation rules, and documentation requirements. Train all staff on how and when to report. | IT Manager with Owner approval | 2–4 weeks |
| 4 → 5 | Implement automated alerting where possible (e.g., system logs feed into your ticketing tool), conduct quarterly incident trend analysis with the leadership team, tie lessons learned to annual security training, and document how incident data informs changes to policies or controls. | IT Manager, Owner, and Security Lead | Ongoing |
Documents and records that prove your maturity level.
- Incident log or register (spreadsheet, notebook, or ticketing system printout) showing at least the last 6 months of recorded incidents with dates and descriptions
- Incident reporting template or form that defines what information must be captured
- At least three completed incident records showing description, impact assessment, root cause, and resolution steps
- Evidence of review (e.g., email, meeting notes, or a signed-off summary from the manager or owner reviewing incidents at least quarterly)
- A document or email showing that lessons learned from at least one past incident led to a change in process, training, or controls
Prepare for these questions from customers or third-party reviewers.
- "Show me your incident log for the past 12 months. How many security or IT incidents have you recorded?"
- "Walk me through a specific incident: what was reported, how was it investigated, and what was the outcome?"
- "If I ask your team about an incident that happened six months ago, where would they find the documentation?"
- "How do you ensure that incidents are actually reported and logged? What happens if someone forgets to document one?"
- "Have you identified any patterns or repeat incidents in your logs? What did you do differently as a result?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and maintain a simple incident log with templates and automated reminders | Google Sheets (free Google account, shared across team, can add form responses automatically) | Microsoft Excel with OneDrive (part of Microsoft 365 at ~₹360–500/month) |
| Ticketing and incident management system with structured workflows, reporting, and history | Zoho Desk free tier (up to 1 agent, limited features), or Freshdesk free plan (up to 1 agent, 90 days data retention) | Zoho Desk paid (~₹1,200/agent/month), Freshdesk paid (~₹1,500–3,000/month), Jira (~₹400–700/month for small teams) |
| Event and log aggregation to automatically capture system incidents and errors | ELK Stack (Elasticsearch, Logstash, Kibana) – open source, self-hosted, requires technical setup | Splunk (~₹15,000–50,000+/year), New Relic (~₹8,000–25,000/year), Datadog (~₹10,000–40,000+/year) |
- Treating only 'security breaches' as incidents and ignoring system crashes, data corruption, or internal mistakes—this means you miss patterns and fail to improve overall resilience.
- Keeping incident records scattered across emails, WhatsApp, sticky notes, and one person's memory—when that person leaves or a regulator asks for records, you cannot find anything and cannot prove you acted.
- Logging incidents but never reviewing them, so the same printer jam or password reset problem happens 10 times a year and nobody realizes there is a training or process problem.
- Documenting incidents only after a customer complains or a regulator asks, instead of proactively recording them—this looks defensive and suggests you are hiding problems.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 6 (data fiduciary obligations to implement reasonable security measures) and Section 7 (duty to notify personal data breaches to the Data Protection Board and affected individuals without undue delay) |
| CERT-In Guidelines 2022 | Cyber Security Direction 4: Entities must report cybersecurity incidents to CERT-In within a prescribed timeline; documentation is required to prove timely notification and mitigation steps |
| ISO 27001:2022 | Clause 8.4 (Information security incident management) and Annex A.5.25 (Incident response and improvement) |
| NIST CSF 2.0 | Detect (DE) function – DE.DP (Processes and procedures are in place to promptly detect, report and respond to anomalies) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →