Without a reporting process, employees stay silent. A small breach in your customer database might go unnoticed for weeks or months, turning into a major incident. A textile exporter in Tamil Nadu lost ₹45 lakhs when a staff member noticed suspicious database access but didn't know whom to report it to—by the time the owner found out, the attacker had already copied customer payment details. Silence also means you cannot meet your legal obligations under the DPDP Act to notify regulators and affected individuals within the required timeline. Customers and regulators will lose trust in your ability to protect their data.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no formal reporting channel. If someone suspects a problem, they either email their boss if they remember, or ignore it and hope it goes away.
Initial
There is one email address or phone number where security concerns can be reported, but it is not well-known and employees are not trained on how to use it.
Developing
You have a documented process (written down, shared with staff) for reporting security issues—usually to your IT person or manager—and most employees know it exists.
Defined
Your reporting process is well-documented, regularly communicated, includes a no-blame policy, and you track every report to ensure it gets investigated and closed.
Managed
Reports are tracked in a system, response times are measured, staff receive feedback on outcomes, and the process is tested quarterly to confirm it works.
Optimised
Your incident reporting system is automated, integrated with your incident response plan, metrics are reviewed monthly by leadership, and you continuously improve the process based on lessons learned.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Designate one person (IT lead or manager) as the security contact. Write down their name, email, and phone number. Share it with all staff via email and post it near printers. | Business owner or IT lead | 1 day |
| 1 → 2 | Create a one-page security incident reporting procedure. Include what to report (unusual emails, failed logins, missing files, suspicious access), whom to contact, and what information to provide. Add this to your employee handbook and conduct a 15-minute team meeting to explain it. | IT lead with business owner approval | 1 week |
| 2 → 3 | Build a simple log or spreadsheet to record all reports: date, reporter name (optional), description, investigation outcome, and closure date. Establish a no-blame culture by publicly thanking staff who report issues. Review logs monthly in management meetings. | IT lead | 2-4 weeks |
| 3 → 4 | Move reporting logs into a ticketing system (even a free tool like Google Forms with automatic email alerts). Define target response times (e.g., acknowledge within 4 hours, investigate within 24 hours). Test the process quarterly with a fake scenario to ensure staff respond correctly. | IT lead with external consultant if needed | 1-2 months |
| 4 → 5 | Integrate incident reports into your incident response playbook. Analyze trends (are certain teams reporting more? are certain threat types missing?). Conduct annual drills, measure metrics like average resolution time, and share anonymized successes with staff to reinforce the reporting culture. | IT lead, information security officer, business owner | Ongoing (1-2 hours per month) |
Documents and records that prove your maturity level.
- A written incident reporting procedure document (1-2 pages) that lists how, where, and to whom to report
- Evidence of communication: email to staff, handbook page, or poster announcing the reporting process and the contact person
- A log or register of all reported incidents (spreadsheet, Google Form responses, or ticketing system entries) with dates, descriptions, and outcomes
- At least 2-3 closed incident reports showing investigation notes and resolution
- Documentation of a test or drill where staff were asked to report a fake incident and confirmed they knew how to do it
Prepare for these questions from customers or third-party reviewers.
- "Show me your documented process for reporting security and data incidents. How do employees know whom to contact and how?"
- "Can you show me examples of incidents that were reported in the last 6-12 months? How did you respond to each one?"
- "How do you ensure that people who report incidents are not punished or blamed for doing so? What have you done to build trust?"
- "How fast does the company typically acknowledge and respond to a reported incident? Can you demonstrate this with logs or records?"
- "Have you tested this reporting process? Have you run a drill to confirm that staff actually know how to report an incident?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Collect and track incident reports from staff | Google Forms (linked to Gmail) with automated notifications; or email alias (security@company.com) monitored by designated person | Freshdesk (₹2,500–5,000/month), Jira (₹250–500/month for small teams), or Zoho Desk (₹3,000–6,000/month) |
| Create and distribute the written reporting policy | Google Docs, Microsoft Word (free version), or Canva for simple posters | Professional template services; typically included in paid ticketing tools |
| Log and track incidents over time | Google Sheets or Excel with shared access; open-source ticketing like Osticket | Incident response platforms like Incident.io (₹8,000–15,000/month) or integrated SIEM solutions |
- Creating a reporting channel that only goes to the IT person, who is already overworked and may delay or ignore reports. Ensure there is a backup contact (manager or another trusted person) and clear escalation rules.
- Making the process too technical or formal (e.g., requiring incident forms in jargon) so that frontline staff like drivers, receptionists, or shop staff don't understand it and don't report. Keep the language simple.
- Not protecting the reporter from blame or retaliation. In Indian businesses, staff fear punishment if they 'make trouble.' Explicitly state that reporting is safe and appreciated; celebrate employees who report issues.
- Forgetting to communicate the process regularly. A poster put up once is forgotten within weeks. Repeat the message in monthly team huddles, email reminders, and induction training for new hires.
- Not actually investigating or closing reported incidents, so staff lose faith in the process. Always acknowledge receipt, provide a rough timeline, and give feedback (even if the answer is 'we checked and found nothing'). Failing to close incidents leaves staff confused and less likely to report next time.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 5 (processing principles), Section 7 (consent and lawfulness), Section 18 (response to data principal requests), and Schedule 2 (technical and organizational measures) |
| CERT-In Guidelines 2022 | Rule 3(b) (reporting cybersecurity incidents); Rule 4 (containment and remediation) |
| ISO 27001:2022 | Clause A.5.16 (incident management), Clause A.5.17 (monitoring and response), Clause 7.4 (communication of information security) |
| NIST CSF 2.0 | Detect (DE.AE-1: Anomalies detected), Respond (RS.CO-1: Personnel know roles; RS.CO-2: Stakeholders are notified) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →