Is there a clear person or role responsible for handling incidents?

When something goes wrong with your computers or data, does everyone know exactly who takes charge and what they need to do? This question asks whether you have named one clear person (or a small backup team) who owns the job of responding to security incidents from the moment they happen until they're fixed.

⚡

Why This Matters to Your Business

Without a named incident owner, when a breach or attack happens, your team wastes precious hours figuring out who should act—meanwhile the attacker is still inside your systems. An e-commerce business in Mumbai lost ₹12 lakh to ransomware because no one was clearly responsible, so the IT person waited for the owner to decide, the owner was traveling, and backups got locked before anyone could respond. You also fail compliance audits (RBI, DPDP, client assessments) because you cannot prove you had a coordinated response, and customers lose trust when they see your incident response was chaotic.

📊

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 designated incident person at all. When a security event happens, people just call each other and hope someone fixes it.

Level 1
Initial

Someone (usually your IT person or owner) handles incidents, but it's not formally documented anywhere and the person may be unavailable without a backup.

Level 2
Developing

You have a named incident owner documented in writing and a backup person identified. Both know the basics of what to do, but no formal training or playbook exists.

Level 3
Defined

You have a written incident response plan that clearly names the incident owner, their role, and their authority to act. All staff know who to contact and there is a tested backup person.

Level 4
Managed

Your incident response plan names specific roles (owner, IT lead, manager, communications lead) with clear authority, escalation paths, and documented responsibilities. The team practices drills quarterly.

Level 5
Optimised

You have a mature incident response team with named roles, regular training, documented playbooks for different incident types, quarterly drills with documented outcomes, and continuous improvement based on industry threats and your own near-misses.

🚀

How to Move Up — Practical Steps

Step	What to Do	Who	Effort
0 → 1	Write down the name and contact details of the person who will be responsible for handling security incidents (usually your IT person or managing director if you are very small).	Managing Director or Owner	1 day
1 → 2	Create a one-page document naming the incident owner, a backup person (who can take over if the owner is unavailable), and what phone numbers/emails to use. Share it with all staff so they know who to call if something goes wrong.	Owner or HR Manager	3 days
2 → 3	Write a simple incident response plan (3-5 pages) that explains what the incident owner must do when an incident is reported: who to notify, what to preserve, how to contain the damage, and how to inform customers or authorities if needed.	IT Manager or external consultant	2-4 weeks
3 → 4	Expand your plan to define multiple roles (incident commander, IT lead, business continuity lead, communication lead) with clear decision-making authority, approval chains, and communication templates. Train all named people.	IT Manager and Management team	1-2 months
4 → 5	Run at least two tabletop incident drills per year, document what went well and what failed, and update your playbook based on real-world threats, new regulations, and lessons learned. Review and refresh training annually.	Incident Response Team Lead	Ongoing (2-3 days per drill)

📁

Evidence You Should Have

Documents and records that prove your maturity level.

Written document or email listing the name, job title, contact number, and email of the incident owner and backup person
A simple incident response plan or playbook (even 2-3 pages) that explains what to do when an incident is reported
Staff communication or memo confirming that all employees know who the incident owner is and how to reach them
Records of training or briefing sessions where the incident owner and their team were taught their roles and responsibilities
Copies of any incident drills, tabletop exercises, or actual incident records showing that the named person took charge

🔍

What an Auditor Will Ask

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

"Who is responsible for handling security incidents in your organization, and how do we know this person has the authority to act immediately?"
"What happens if your named incident owner is unavailable? Who takes over and how do people know?"
"Show me your incident response plan and explain how the incident owner's role is documented in it."
"Have you tested your incident response plan with a drill? If so, was the named person able to coordinate the response effectively?"

🛠

Tools That Work in India

Purpose	Free Option	Paid Option
Create and store a simple incident response playbook that all staff can access	Google Docs or Microsoft Word template (no cost)	—
Send alerts and notifications quickly to the incident team when a breach or suspicious activity is detected	Email lists or WhatsApp group (low-tech but works for small teams)	PagerDuty (approx ₹3,000–8,000/month for small teams)
Document and track incidents from report to resolution, including who did what and when	Google Sheets or Zoho CRM (free tier available)	Zoho Incident Management or Atlassian Jira (approx ₹2,000–10,000/month)

🛡

How This Makes You More Resilient

When you have a clear incident owner, your team responds 50–70% faster because everyone knows exactly who is in charge and what they should do, instead of wasting time in confusion. This dramatically reduces the window of time a hacker or malware has to spread, steal data, or encrypt files. You also recover customer trust faster and avoid hefty fines from regulators because you can prove a coordinated response.

⚠️

Common Pitfalls in India

Naming the IT person as incident owner but never giving them authority to stop systems, isolate networks, or communicate with customers—so they get stuck waiting for approval while the incident spreads.
Failing to name a backup person, so when your one IT person is sick or on holiday, the business is paralyzed during an attack.
Creating a fancy incident response plan that no one reads or practices, so when a real incident happens, people don't follow it or don't even know it exists.
Assuming the owner knows what to do without training or a playbook, leading to poor decisions like shutting down the wrong server, losing forensic evidence, or accidentally leaking sensitive data while trying to respond.
Changing the incident owner every 6 months without formal handover, so new people don't know their role and incidents take longer to manage.

⚖️

Compliance References

Standard	Relevant Section
DPDP Act 2023	Section 4(2) and Section 6(2): obligation to take reasonable security measures and to inform the Data Protection Authority in case of a data breach. Clear incident ownership accelerates notification.
CERT-In 2022	Direction 6: organizations must report cybersecurity incidents to CERT-In. A named incident owner ensures timely reporting.
ISO 27001:2022	Clause A.16.1 (Incident management): organizations must plan and prepare a coordinated and effective response to information security incidents, which requires clear roles and responsibilities.
NIST CSF 2.0	Detect (DE) and Respond (RS) functions: identifies the need for defined roles and responsibilities to detect and respond to cybersecurity events in a coordinated manner.

Ready to assess your organisation?

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

Start Free Self-Assessment →