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

Are basic steps defined for responding to common incidents (malware, data loss, account compromise)?

When something bad happens like a virus infects your computer, someone steals customer data, or an employee's login gets hacked, do you have a written plan for what to do first? This question asks whether your business has simple, step-by-step instructions ready for the most common security problems so people know exactly what to do instead of panicking.

⚡
Why This Matters to Your Business

Without a response plan, your team wastes precious hours figuring out what to do while damage spreads—a ransomware attack could encrypt all your files, a data breach could expose customer phone numbers and addresses leading to regulatory fines under DPDP Act, and confused staff might accidentally delete evidence or alert the attacker. A manufacturing business in Pune lost ₹18 lakhs when malware spread for 3 days because no one knew who to call or how to isolate infected machines. Customers lose trust, auditors flag you as unprepared, and you may face penalties from data protection authorities.

📊
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 response steps anywhere; when something breaks, people call each other asking 'what do we do?' and decisions are made on the spot. Your IT person (if you have one) handles emergencies by trial and error, and afterwards no one documents what happened.

Level 1
Initial

You have a basic one-page document listing three emergency phone numbers (IT person, owner, maybe a local computer repair shop) and vague instructions like 'turn off the computer if it's infected.' There's no clear decision tree for different types of incidents and no assigned roles.

Level 2
Developing

You have a simple 2–3 page incident response guide covering malware, data loss, and account compromise with basic steps like 'isolate the device, notify the IT person, check backups.' Roles are loosely assigned (IT person handles technical, owner handles communication) but the plan hasn't been tested.

Level 3
Defined

You have a documented incident response plan with clear steps for malware, data loss, and account compromise, including isolation procedures, notification triggers, backup checks, and escalation contacts with phone numbers. The plan has been reviewed once by your team and shared with key staff; roles are assigned but drills haven't been conducted.

Level 4
Managed

Your incident response plan is detailed and regularly updated (at least annually), includes decision trees for different incident types, covers containment, preservation of evidence, customer notification, and regulatory reporting. You've conducted at least one tabletop drill or simulation; staff know their roles and the plan is tested when systems change.

Level 5
Optimised

Your incident response plan is comprehensive, tested through realistic drills twice a year with documented results and learnings, integrated with your backup and recovery systems, and reviewed quarterly for relevance. External advisors have reviewed it; staff can execute critical steps from memory; and you track response times and effectiveness metrics.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 Write a one-page emergency contact list and basic checklist (power off device, notify IT, check last backup date) for malware and account compromise incidents. Business owner or designated IT person 1 day
1 → 2 Expand the document to 2–3 pages with separate procedures for malware infection, data loss, and account compromise, including isolation steps, backup recovery checks, and who to notify internally (owner, finance, customer service). IT person with input from owner 1 week
2 → 3 Add decision flowcharts for each incident type (e.g., 'Is data publicly exposed?' → 'Notify CERT-In within 72 hours'), assign clear roles with mobile numbers, include customer/vendor notification templates, and document escalation criteria. IT person with owner and legal/compliance review 2–3 weeks
3 → 4 Conduct a tabletop drill simulating a malware outbreak or data breach, document gaps, refine procedures, integrate the plan with your backup/recovery process, and schedule annual review dates. IT person facilitating, owner and key staff participating 1–2 months (including drill execution and remediation)
4 → 5 Run semi-annual realistic drills (e.g., simulate a ransomware attack with controlled environment), measure response times, track metrics (time to detect, time to isolate, downtime), gather staff feedback, and refine based on learnings. IT person and external advisor (if budget allows) Ongoing (2–3 days per drill + monthly review)
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • Printed or digital copy of incident response plan document with date of last review and sign-off from owner/IT lead
  • Documented contact list with names, phone numbers, and roles (IT person, owner, backup contact, external support vendor if contracted)
  • Written procedures for at least three incident types: malware infection, data loss/corruption, and account compromise with step-by-step actions
  • Signed acknowledgment forms or email confirmations showing key staff have read and understood the plan
  • Record of at least one tabletop drill, simulation, or incident response exercise with documented results, issues found, and actions taken
🔍
What an Auditor Will Ask

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

  • "Show me your incident response plan. When was it last updated and who approved it?"
  • "Walk me through what happens if malware is detected on an employee's laptop right now. Who do they call and what's the first step?"
  • "How do your team members know what to do during a data breach? Have you conducted any training or drills?"
  • "If customer data was accidentally exposed, what's your process for deciding whether to notify regulators and customers? Is it documented?"
  • "What would your business do if your main server fails and backups are unavailable? Do you have recovery steps written down?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Create and store your incident response plan document securely Google Docs (with restricted access) or Nextcloud (self-hosted); simple and accessible Microsoft 365 (₹3,000–6,000/year) or Confluence by Atlassian (₹1,200–3,000/year)
Document and track incidents (what happened, when, who handled it, resolution time) Google Sheets or LibreOffice Calc; basic but functional Jira Service Management (₹2,000–5,000/year) or Freshdesk (₹1,500–4,000/month)
Send encrypted notifications to staff or customers during an incident without emails being intercepted Secure email via Protonmail or encrypted messaging like Signal Dedicated incident notification platform like OnSolve or Everbridge (₹5,000–15,000/month)
Simulate incidents (tabletop drills) and document lessons learned Simple spreadsheet or shared document to log drill scenarios and outcomes Incident simulation platform like Disrupt or Gremlin (₹10,000–30,000/month, usually for larger firms)
🛡
How This Makes You More Resilient
When a malware or data breach incident hits, your team responds in minutes instead of hours of confusion, containing the damage quickly and preserving evidence for investigation. Your customers and regulators are informed promptly and professionally, protecting your reputation, reducing downtime-related revenue loss, and avoiding penalties from authorities like CERT-In.
⚠️
Common Pitfalls in India
  • Writing a lengthy, formal 50-page incident response plan that no one reads or understands; instead, keep your initial plan to 2–3 pages with clear, simple language and diagrams for small teams.
  • Focusing only on IT-level technical steps (isolate device, run antivirus) and forgetting the business side: who informs the owner, how quickly do you notify customers, and when do you call a lawyer—resulting in missed regulatory deadlines.
  • Assuming your one IT person will remember the plan during a real crisis; ensure the plan is printed, shared with backup staff, and accessible even if that person is unavailable.
  • Never testing the plan, so when an actual incident happens, you discover steps are outdated, contact numbers are wrong, or the backup system doesn't work as described.
  • Failing to define 'who decides' on critical actions like 'do we pay a ransomware demand?' or 'do we take systems offline?'—leaving staff paralyzed during an incident.
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 6 (transparency and accountability obligations) and Section 8 (response to personal data breaches within 72 hours notification requirement)
CERT-In 2022 Directions Direction 4: Organisations must notify CERT-In of cybersecurity incidents without unreasonable delay, and within 72 hours where data breaches occur
ISO 27001:2022 Clause A.16.1 (Planning and preparation for information security incident handling and improvement) and A.16.1.5 (Response to information security incidents)
NIST CSF 2.0 Respond Function (RS): Respond to detected or reported cybersecurity incidents by executing incident response plan and coordinating response efforts

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