NCSRC NIRMATA
Home Guides Framework Start Assessment →
Home › Guides › Incident Readiness › IR-09
IR-09 Incident Readiness 4% of OML score

Does the business know when incidents must be reported to customers or authorities?

Do you have a clear written list of which types of security incidents must be reported to your customers or to government authorities, and do your staff know how quickly they must report them? This is about knowing the rules before something bad happens, not scrambling to figure it out when an incident occurs.

⚡
Why This Matters to Your Business

If a customer's data leaks from your system and you don't report it on time, you can face penalties under the Digital Personal Data Protection (DPDP) Act 2023 and lose customer trust permanently. For example, a manufacturing company in Delhi that suffered a ransomware attack discovered their customer list was exposed but waited 3 weeks to notify customers—they lost 40% of their business and faced a ₹50 lakh DPDP notice. Banks and government agencies you work with may blacklist you if you don't report incidents within their required timeframe. Without knowing the rules, your team will panic and delay, turning a small incident into a compliance disaster.

📊
What Each Maturity Level Looks Like

Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.

Level 0
Absent

You have no written incident reporting procedure. When something bad happens, your team emails each other or calls the owner asking what to do.

Level 1
Initial

You have vague knowledge that you 'should report' incidents, but no one can clearly say which incidents, to whom, or within how many hours—it's mostly guesswork.

Level 2
Developing

You have a basic written list saying 'report data breaches' but the timelines are unclear, contact names are outdated, and only the IT person knows about it.

Level 3
Defined

You have a documented incident reporting procedure with clear timelines (e.g., 72 hours for DPDP Act) and contact lists for customers and authorities, and management has approved it.

Level 4
Managed

Your incident reporting procedure is documented, tested quarterly through drills, includes escalation rules based on severity, and your team demonstrates they know the thresholds without prompting.

Level 5
Optimised

You have an incident reporting process that is automated where possible (e.g., alerts trigger notifications), regularly tested, updated after each incident or regulatory change, and all staff can recite their role without hesitation.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 Schedule a 2-hour meeting with your IT person and business owner to list what counts as an 'incident' (data loss, ransomware, customer complaint about data exposure, etc.). Write down initial guesses about who to tell (customers, RBI if financial data, CERT-In, police). Business Owner + IT Person 1 day
1 → 2 Research and document: (1) DPDP Act Section 5 requires breach notification within 72 hours to RBI/authority if personal data is involved; (2) any contractual notification clauses in your customer contracts; (3) CERT-In Incident Reporting requirements if you store critical data. Create a one-page table with Incident Type → Whom to Report → Deadline. IT Person or Consultant 1 week
2 → 3 Formalize your incident reporting procedure into a 2-3 page document: list incident categories, reporting timeline, contact names/emails/phone for key customers and authorities (RBI grievance cell, nearest police cybercrime unit, CERT-In), and approval workflow. Get it signed off by management and share with all staff. IT Manager + Compliance/HR Lead 2-4 weeks
3 → 4 Conduct a tabletop simulation: role-play a ransomware incident and have each team member execute their part of the reporting procedure (detect → escalate → notify → document). Document what went wrong and update the procedure. Repeat quarterly. IT Manager + Business Owner 1-2 months (initial setup and first drill)
4 → 5 Integrate incident reporting into your monitoring systems: set up alerts in your antivirus/firewall to auto-trigger notification lists; create a simple incident ticket template in email or a free tool that auto-logs the time reported; review and update the procedure annually after any regulatory change or real incident. IT Person Ongoing (monthly review, annual update)
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • Written Incident Classification & Reporting Procedure document (1-3 pages) approved by management, dated and versioned
  • Incident Reporting Contact List with customer and authority details (RBI, CERT-In, local Cyber Police), phone numbers, email addresses, and reporting deadlines for each type
  • Completed Incident Report Template or Form (even blank examples) showing fields for: date/time detected, incident type, data affected, initial actions taken, notification date/time, recipient, and sign-off
  • Record of staff training or briefing (email, meeting notes, or training attendance sheet) showing that at least management and IT staff have been told about reporting rules
  • Evidence of at least one incident drill or test (tabletop or real incident response log) showing that the procedure was actually followed with timestamps
🔍
What an Auditor Will Ask

Prepare for these questions from customers or third-party reviewers.

  • "Walk me through your incident reporting procedure step-by-step. Without looking at your document, tell me: if you discover customer personal data has been exposed, how many hours do you have to notify CERT-In or RBI, and who makes the call?"
  • "Show me your list of incidents that trigger mandatory reporting. For each type (ransomware, data breach, unauthorized access), state the notification deadline and which authorities or customers you must notify."
  • "Can you describe a recent incident (real or simulated) and show me the evidence that it was reported within the required timeline? Provide the incident log, the notification email, and proof it was sent on time."
  • "What happens if your team misses a reporting deadline? Who is responsible for catching that mistake? Show me a procedure that prevents this."
  • "Have you tested whether your team actually knows how to report an incident? When did you last do a drill, and what did your staff struggle with?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Create and maintain your incident reporting procedure document and contact list Google Docs (free Google account, shareable, version-controlled, comment-friendly) Microsoft Word 365 (₹6,000/year per user) or Notion (₹0-1,800/year depending on plan)
Log and track incidents from detection to closure with timestamps and notifications sent Google Forms + Google Sheets (creates incident form and auto-logs to spreadsheet) or Jira Free (up to 10 users) Atlassian Jira Service Management (₹15,000-40,000/year) or Freshservice (₹7,500-25,000/year)
Send incident notifications and alerts to customers and authorities reliably with delivery proof Gmail with read receipts, or free Slack for internal escalation (if you use Slack) Twilio SMS notifications (pay-per-use, approx ₹0.30-1 per SMS) or SendGrid email service (₹2,000-15,000/year for volume-based plans)
🛡
How This Makes You More Resilient
When you know exactly when and to whom to report incidents, you avoid costly compliance penalties under DPDP Act (up to ₹5 crore for willful breaches) and maintain customer trust by being transparent early. Your team responds faster and more confidently instead of panicking, reducing the damage window and often preventing escalation to authorities altogether. You also build a defensible record showing you acted in good faith, which regulators and courts consider when determining fines.
⚠️
Common Pitfalls in India
  • Assuming your customer contracts don't require breach notification because you didn't read them carefully—many financial services and government contracts have strict 24-48 hour notification clauses that override DPDP's 72-hour window.
  • Only creating an incident reporting procedure in your IT person's head or in scattered email threads, then losing it when they leave the company; always keep a dated, signed, physical or shared document copy.
  • Confusing 'incident detection time' with 'incident discovery time'—DPDP requires reporting within 72 hours of *discovery*, not when the breach actually happened, so delaying discovery by investigating quietly can backfire legally.
  • Not having direct contact numbers for your biggest customers or for CERT-In's incident reporting phone line, then wasting hours during a real incident trying to find the right email or department.
  • Setting unrealistic reporting timelines (e.g., 'we'll investigate for 2 weeks before telling anyone')—regulators expect you to notify *immediately* upon discovery and investigate in parallel, not before.
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 5 (breach notification within 72 hours of discovery to Data Principal and relevant authority); Section 18 (Data Fiduciary's obligation to inform without undue delay)
CERT-In 2022 Indian Computer Emergency Response Team (CERT-In) Incident Reporting Directions – entities must report incidents involving critical data or critical infrastructure within 6 hours of detection
ISO 27001:2022 Clause A.5.28 (Responsive information security), Annex A control 5.28 requires documented process for incident communication and reporting
NIST CSF 2.0 Detect (DE) & Respond (RS) functions; specifically RS.CO-1 (coordinate detection activities and RS.CO-2 (incident reporting and sharing)

Ready to assess your organisation?

Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.

Start Free Self-Assessment →

TRUST-IN Bharat · NIRMATA Framework · Licensed CC BY-SA 4.0 · Custodian: Elytra Security

← Back to all guides  ·  trustinbharat.org