Does the business know what systems or data are most critical during an incident?

Do you know which of your systems, databases, or customer information are the most important to keep running if something goes wrong? Can your team quickly identify and fix the critical stuff first instead of wasting time on less important things?

⚡

Why This Matters to Your Business

Without knowing what's critical, when an attack or outage happens, your team wastes hours figuring out what to fix first—meanwhile your customer data might be exposed, orders aren't processed, and you lose revenue. A garment exporter in Tiruppur loses their order management system for 8 hours because they don't know it's critical; customers cancel ₹50 lakh in orders because shipments aren't tracked. If you can't prove you protected critical data first, regulators under the DPDP Act may fine you, and customers won't trust you with their information again.

📊

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 documented list of critical systems or data. If someone asks your IT person which system must never go down, they give a different answer than your accountant would.

Level 1
Initial

Your owner or manager has a rough idea in their head about which systems matter most, but it's not written down. When a junior IT person joins, they have to guess what's important.

Level 2
Developing

You have a basic written list of critical systems (e.g., invoicing software, customer database, email) but it's not formally approved or tested. The list lives in someone's notebook or a Word file that doesn't get updated.

Level 3
Defined

You have a documented and approved list of critical systems and data, with clear reasons why each is important (e.g., customer data = DPDP compliance, invoice system = revenue). Your team reviews it once a year and updates it when systems change.

Level 4
Managed

You have a detailed priority matrix that ranks systems by impact and recovery time. You've tested recovery procedures for your top 3-5 systems and documented how long each should take. Your incident plan explicitly references this priority list.

Level 5
Optimised

Your criticality assessment is continuously reviewed quarterly, tested in real incidents, and automatically feeds into your incident response playbooks. Every team member can explain in 30 seconds why their system's ranking matters.

🚀

How to Move Up — Practical Steps

Step	What to Do	Who	Effort
0 → 1	Business owner meets with IT person and finance manager for 1 hour; brainstorm and verbally agree on top 5 systems that would hurt the business most if down (e.g., GST billing, customer data, email, inventory tracking). Write it in simple bullet points.	Business owner or operations manager	1 day
1 → 2	Formalise the list: create a one-page table with system name, what data it holds, who depends on it, and rough cost of 1-hour downtime. Get finance and operations to sign off. Save it as a locked PDF in shared drive.	IT person or operations manager with approval from owner	3-5 days
2 → 3	Expand the list into a proper Business Impact Analysis (BIA) document: for each critical system, define Recovery Time Objective (RTO = how fast must it be back online) and Recovery Point Objective (RPO = how much data loss is acceptable). Example: Customer DB = RTO 2 hours, RPO 30 minutes. Get documented approval from management.	IT person with input from department heads and formal sign-off from owner	2-4 weeks
3 → 4	Create incident response playbooks for your top 3-5 systems that reference criticality. Conduct a desktop simulation (no actual shutdown needed): walk through a 1-hour outage scenario for your most critical system and time how long recovery actually takes. Update the RTO/RPO based on real findings. Document lessons learned.	IT person led, with participation from all department heads. External consultant optional (₹2-5 lakh for 3-5 days if budget allows)	1-2 months
4 → 5	Schedule quarterly reviews of the criticality list (link to change management). Run one real tabletop incident exercise per year that explicitly tests recovery of critical systems. Feed results back into playbooks. Train new hires using this framework in their first week. Measure and report on recovery performance in monthly management reviews.	IT person, with oversight from owner or quality manager	Ongoing (4-6 hours per quarter)

📁

Evidence You Should Have

Documents and records that prove your maturity level.

Documented list of critical systems and data (at least system name, function, and business justification)
Business Impact Analysis (BIA) document with Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each critical system
Sign-off or approval from business owner/management confirming the criticality rankings
Incident response playbook or checklist that explicitly references the priority list and specifies which systems to recover first
Evidence of at least one test or simulation (notes from meeting, email, or incident log) where recovery procedures were executed and actual recovery times recorded

🔍

What an Auditor Will Ask

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

"Walk me through your documented list of critical systems. How did you decide what makes a system critical?"
"If your customer database went down for 2 hours, what would the business impact be? What about your invoicing system?"
"Show me your incident response plan. How does it tell the team which system to fix first if multiple systems are affected?"
"When was the last time you actually tested recovery of one of these critical systems? What did you learn, and how did it change your plan?"

🛠

Tools That Work in India

Purpose	Free Option	Paid Option
Document and maintain the list of critical systems with approved RTOs and RPOs	Google Sheets (shared, with comments and version history) or LibreOffice Calc. Add columns for system name, criticality reason, RTO, RPO, owner name, and last review date.	ServiceNow IT Service Management module (₹5-15 lakh/year depending on users) or Atlassian Confluence (₹1-3 lakh/year for 10-50 users)
Conduct Business Impact Analysis (BIA) and create recovery time estimates	NIST SP 800-34 BIA template (download free from NIST website); use in Excel. Or SANS incident handling templates.	MetricStream GRC platform (₹10-20 lakh/year) or Archer platform (₹8-15 lakh/year). Overkill for most MSMEs.
Track and document incident response tests and actual recovery performance	Simple spreadsheet (Excel/Sheets) with columns: test date, system tested, planned RTO, actual recovery time, issues found, owner, sign-off. Or Jira for free tier (up to 10 users).	Splunk Enterprise (₹15-40 lakh/year) or Elastic Stack subscription (₹5-10 lakh/year) if you want automated logging and monitoring of recovery tests

🛡

How This Makes You More Resilient

When you know your critical systems, an incident doesn't become a panic—your team immediately focuses on restoring what actually costs you money and reputation, getting you back online 4-6 hours faster. You avoid situations where a junior tech spends 2 hours restoring a non-critical email archive while your customer payment system is down. Customers and auditors see you as organised and prepared, which protects your contracts and regulatory standing.

⚠️

Common Pitfalls in India

Assuming everything is equally critical: MSMEs often mark all systems as 'critical' because they don't want to admit something might not matter. This makes incident response useless because the team doesn't know where to focus. Reality check: if your email is down for 1 hour but customer orders still process, email is not as critical as order management.
Creating a list once and never updating it: you buy new software, retire old systems, or add new products, but your criticality list stays frozen. When an incident hits, your team follows an outdated plan. Set a mandatory review trigger whenever IT infrastructure changes.
Not including upstream or downstream dependencies: you mark your invoicing system as critical but forget it depends on your internet connection and power supply. During an incident, the team tries to restore the invoicing software while the server is still offline. Document the full chain: what does your critical system need to work?

⚖️

Compliance References

Standard	Relevant Section
DPDP Act 2023	Section 8 (accountability and governance): organisations must demonstrate reasonable security practices and ability to respond to data incidents. Identifying critical data systems is foundational to this.
CERT-In 2022 Guidelines	Direction 2.3.3 and 4.1 (incident management and business continuity): organisations must have documented incident response procedures that prioritise critical assets and systems.
ISO 27001:2022	Clause 4.3 (determination of scope) and Annex A.5.19 (incident response planning): information security must protect critical assets identified during a scope and impact assessment.
NIST CSF 2.0	RESPOND function (RC.RP: Response Planning) and RECOVER function (RC.CO: Coordination): organisations must identify and prioritise critical systems before an incident occurs.

Ready to assess your organisation?

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

Start Free Self-Assessment →