When employees don't know who to contact, they waste time asking colleagues, call the wrong person, or don't report the problem at all. This delay can turn a small breach into a major one. For example, if an employee at a Delhi manufacturing export company notices unauthorized access to the customer shipment database but doesn't know who to report it to, the hacker could copy thousands of customer records before anyone stops them—resulting in customer lawsuits, lost contracts, and penalties under DPDP Act 2023. A confused incident response also means regulators and auditors see negligence, damaging your reputation and compliance score.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no formal process. When someone suspects a problem, they guess who to tell—maybe the owner, maybe IT, maybe nobody. There is no documented contact list and employees have no training on what counts as a security issue.
Initial
You have one or two people designated (usually the IT person or owner), but it's word-of-mouth knowledge. Some employees know, others don't. There is no written list posted anywhere and no consistent way to report issues.
Developing
You have an incident contact list (names, phone, email) posted on the office noticeboard and shared in the employee handbook. Most employees know who to contact, but you haven't formally trained anyone on what to report or tested whether the process actually works.
Defined
You have a documented incident response contact list, email, or hotline number that is communicated during onboarding and displayed prominently. All employees have been trained on what counts as a security incident and how to report it. You tested the process once and fixed obvious gaps.
Managed
You have multiple reporting channels (email alias, phone, chat, anonymous online form). Every new employee gets formal training on incident reporting. You regularly test the process (quarterly drills) and track how many reports come in. Response times are documented and met consistently.
Optimised
You have a mature incident reporting program with multiple channels, regular training, anonymous and non-anonymous options, documented response SLAs, automated acknowledgment, and quarterly reviews. External partners and customers know how to report issues. You track near-misses and close-calls to improve the process, and incident reporting metrics are part of your security dashboard.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Identify and document one primary contact person (usually IT lead or manager) for security incidents. Write down their name, phone number, and email. Communicate this informally to the team at the next meeting. | Owner or Manager | 2 hours |
| 1 → 2 | Create a simple one-page incident contact card with clear language: 'If you see something suspicious—unauthorized login, missing files, phishing email, strange behavior—contact [Name] immediately at [Phone] or [Email]. Examples: [3 bullet points].' Print and post in common areas and add to employee handbook. | Manager or HR | 3 days |
| 2 → 3 | Conduct a 30-minute classroom or online training session for all staff. Cover: what is a security incident (real examples), how to report it (step-by-step), what happens next. Use Indian business examples (GST breach, employee data leak, ransomware). Require attendance and keep a sign-in sheet. | IT lead or external trainer | 2 weeks prep + 1 day delivery |
| 3 → 4 | Set up a dedicated email alias (security@company.com) or anonymous form on your company intranet/Google Form. Document response time SLA (e.g., acknowledge within 2 hours, investigate within 1 day). Create an incident log to track all reports. Run a quarterly tabletop drill where you simulate a security incident and test the reporting process. | IT lead with Manager approval | 4-6 weeks |
| 4 → 5 | Integrate incident reporting into business continuity and audit cycles. Publish annual incident metrics (number of reports, response times, outcomes). Add incident reporting training to onboarding checklist. Partner with customers/vendors to include your incident contact in their procurement questionnaires. Review and refresh the process based on actual incidents and near-misses. | CISO or IT Manager with Board review | Ongoing quarterly |
Documents and records that prove your maturity level.
- Incident Response Contact List: a document or poster with the name, phone, and email of the person(s) to contact, displayed in office and included in employee handbook
- Training Records: sign-in sheet, attendance list, or learning management system record showing all employees have received incident reporting training with dates
- Incident Report Log or Register: a spreadsheet or tool tracking all security reports received (date, reporter name, issue, action taken, resolution date)
- Response Time SLA Document: a written policy stating how quickly incidents will be acknowledged and investigated (e.g., 'All reports acknowledged within 2 hours')
- Annual or Quarterly Drill Report: evidence that you simulated an incident, tested the reporting process, and documented the results and improvements made
Prepare for these questions from customers or third-party reviewers.
- "Pick a random employee and ask them: 'If you thought your laptop was hacked, who would you contact right now and how?' They should give a clear, fast answer with a name and phone/email."
- "Show me the document or poster that lists who employees should contact for a security incident. Is it current, accessible, and understandable?"
- "Tell me about the last three security reports your team received. When were they reported, to whom, and how quickly were they acted on?"
- "When was the last time you trained employees on what is a security incident and how to report it? Can you show me proof (attendance record, email announcement, etc.)?"
- "Do you have an SLA (Service Level Agreement) that says how fast you will respond to a reported security incident? What is it?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and host incident reporting forms anonymously so employees can report without fear of retaliation | Google Forms (part of Google Workspace free tier); Microsoft Forms (part of Office 365) | Safecall or similar whistleblowing platform: ₹3,00,000–8,00,000/year |
| Centralize and track all incident reports in a single searchable log with automatic notifications to the incident contact | Google Sheets or Airtable free tier with email notifications; Jira Community edition (for small teams) | ServiceNow Incident Management: ₹5,00,000–15,00,000/year; Atlassian Jira: ₹1,50,000–3,00,000/year |
| Send automated email alerts or SMS notifications to the incident contact when a report is submitted, so urgent issues don't get missed | IFTTT (If This Then That) with Zapier free tier; Google Sheets with email notification scripts | Zapier: ₹2,500–15,000/month depending on task volume; Twilio for SMS alerts: ₹100–500/month depending on volume |
- Creating a contact list but never updating it: the IT person listed left the company six months ago, and employees call a wrong number during a real incident. Assign someone to review and update the contact list every quarter.
- Training once and assuming everyone remembers: new employees join and don't know the process; existing staff forget over time. Make incident reporting part of every new-hire onboarding and send a reminder email twice per year.
- Having only one contact channel (e.g., one person's phone): if that person is sick, in a meeting, or unreachable, the incident goes unreported. Set up a shared email (security@company.com) or a secondary contact to ensure someone always responds.
- Not documenting what happens after a report: employees report an issue but hear nothing back, so they stop reporting next time. Always send a brief acknowledgment ('We received your report, we're investigating') and a follow-up summary when resolved.
- Confusing 'incident reporting' with 'blame': staff fear reporting a security problem because they worry they'll be punished for clicking a phishing link or leaving a laptop unlocked. Create a blameless culture where reporting is praised, not punished.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 6 (duties of data fiduciaries) and Section 7 (framework for contract management); Section 2(h) requires notification of a Data Protection Officer (DPO) or equivalent responsible person for incident handling |
| CERT-In 2022 Rules | Rule 4(1) and 4(2): entities shall implement incident response procedures and notify CERT-In of 'security incidents' within a specified timeframe; incident reporting readiness is a precondition |
| ISO 27001:2022 | Clause A.5.16 (incident management planning and preparation) and Clause A.5.17 (response to information security incidents); Annex A.5.18 addresses assessment and decision on security events |
| NIST CSF 2.0 | Detect (DE) function, especially DE.AE-1 (Awareness and understanding of potential security events) and DE.DP-1 (Detect potential security incidents and anomalies) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →