Without knowing which systems are critical, when disaster strikes—a ransomware attack, power outage, or hardware failure—your team wastes time recovering the wrong things while your actual revenue-generating operations stay down. For example, a Mumbai export company lost ₹8 lakhs in one day because they spent 6 hours restoring a backup system while their order management system (which they hadn't marked as critical) remained offline. Your audit or customer security assessment will fail if you cannot show which systems matter most. You'll also struggle to justify security spending and may invest in protecting non-critical systems while leaving revenue-critical ones vulnerable.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You do not have any documented list of critical systems. Your team knows informally which things are important, but it exists only in people's heads, not on paper.
Initial
You have created a simple spreadsheet listing your main systems and services, but there is no formal process for deciding what counts as 'critical' and no regular update cycle.
Developing
You have a documented list of critical systems with a clear definition of what 'critical' means (e.g., systems that stop revenue or cause regulatory breach if down). The list is reviewed once a year but has no detailed recovery details yet.
Defined
Your critical systems list is maintained and updated quarterly, includes business owner sign-off, and each critical system has an associated Recovery Time Objective (RTO) and Recovery Point Objective (RPO)—targets for how fast you need to recover and how much data loss is acceptable.
Managed
Your critical systems are categorized by criticality tier, linked to documented recovery procedures, and the business owner formally approves any changes to the list. Dependencies between systems are mapped.
Optimised
Your critical systems framework is embedded in annual risk reviews, tested in recovery drills, automatically updated when infrastructure changes, and linked to incident response and backup strategies. Dependencies and single points of failure are regularly re-evaluated.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Hold a 2-hour meeting with the business owner, finance head, and IT person. List every application, system, and service your business uses. Write it in a simple Excel file with columns: System Name, What It Does, Rough Number of Users. Save it on the shared drive. | IT person (with business owner input) | 1 day |
| 1 → 2 | Define criticality: Ask the business owner 'If this system goes down for 4 hours, do we lose money or violate law?' If yes, mark it CRITICAL. If maybe, mark IMPORTANT. If no, mark ROUTINE. Add these labels to your spreadsheet. Have the business owner sign the spreadsheet. | IT person with business owner sign-off | 3 days |
| 2 → 3 | For each CRITICAL system, write down: (1) What is the maximum time we can be down? (RTO, e.g., 2 hours). (2) How much data loss can we accept? (RPO, e.g., 15 minutes). Document these targets based on actual business needs, not guessing. Get business owner approval. | IT person with business owner and department heads | 2-4 weeks |
| 3 → 4 | Create a 'Critical Systems Register' document. For each critical system list: owner (who runs it), dependencies (what other systems it relies on), backup location, restore procedure steps, and responsible person. Group systems into tiers (Tier 1 = restore first, Tier 2 = restore second). Share with all stakeholders. | IT person with input from system owners | 1-2 months |
| 4 → 5 | Run a quarterly review cycle: Update the critical systems list when infrastructure changes, test recovery procedures in dry-run drills twice yearly, update RTOs/RPOs based on business changes, and document lessons learned. Link list to backup schedules, disaster recovery plan, and insurance coverage. | IT person (monthly), business owner (quarterly sign-off) | Ongoing |
Documents and records that prove your maturity level.
- A signed, dated document titled 'Critical Systems List' or 'Business Continuity Priority Register' listing each critical system, its business function, owner, RTO (recovery time target), and RPO (recovery point objective)
- A definition document or policy page that explains what 'critical' means to your organization and the criteria used to classify systems
- Meeting minutes or email showing business owner approval of the critical systems list (dated within last 12 months)
- A 'System Dependencies Map' showing which critical systems depend on other systems (e.g., 'Order Management depends on Database Server and Internet connection')
- Backup and recovery procedure documents for each critical system, referencing the RTO/RPO targets
Prepare for these questions from customers or third-party reviewers.
- "Show me your list of critical systems. How was it created and who approved it? When was it last updated?"
- "Pick one critical system. What is its RTO and RPO? How do you know these are the right numbers for your business?"
- "If your database server fails today, what is the first system you would restore and why? What would be the last? Show me the priority order."
- "Tell me about one system that is NOT on your critical list. Why did you decide it is not critical? What would happen if it went down?"
- "Show me how dependencies are documented. If System A is down, which other systems stop working? How do you know?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and maintain the critical systems list with version control and approval workflow | Google Sheets or Microsoft Excel shared on OneDrive (free Microsoft 365 for nonprofits; paid ₹3,999/year for Business Basic for 1 user) | ServiceNow ITSM (₹30,000+/year) or Atlassian Jira (₹5,000–50,000/year depending on users) |
| Map system dependencies and visualize which systems depend on each other | Lucidchart free tier (3 documents) or draw.io (free, browser-based, no limits) | Microsoft Visio (₹8,000/year single license) or Lucidchart Pro (₹15,000/year) |
| Track backup schedules and Recovery Time/Point Objectives for each critical system | Google Forms + Sheets to log backup completion dates and test results | Veeam Backup & Replication (₹3,00,000–8,00,000/year for SMEs) or Acronis Cyber Protect (₹1,20,000–5,00,000/year) |
- Marking everything as 'critical' to be safe: This defeats the purpose. A payroll system going down for 2 hours is serious but different from an order management system going down for 2 hours. Be honest about business impact, not technical importance.
- Letting IT alone decide criticality: Without the business owner and department heads, IT will focus on technical systems (servers, databases) and miss business services (customer portal, reporting, compliance tools). Always involve the people who use the systems.
- Creating a list once and never updating it: When you add new software, retire old systems, or change business processes, the list becomes stale and useless. Schedule a quarterly review with the business owner.
- Confusing 'critical' with 'frequently used': An employee timesheet system is used daily but is not critical to immediate revenue. A backup inventory system used once a month might be critical for tax compliance. Think about impact, not frequency.
- No written RTO/RPO targets: If you say 'we need to recover fast', your team will guess during a crisis. Write down a specific number (e.g., 'Order Management System: RTO 2 hours, RPO 15 minutes') and sign it with the business owner so everyone agrees.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Reasonable Security Safeguards) and Schedule 2 (Storage Limitation) require organizations to identify and protect personal data systems; knowing which systems are critical is part of this |
| CERT-In 2022 | Guideline 7 (Business Continuity and Disaster Recovery) requires organizations to identify critical information systems and maintain recovery plans |
| ISO 27001:2022 | Clause 8.1 (Operational Planning and Control) and Annex A, Control A.12.3.1 (Information Backup) require identification of critical assets and systems for backup |
| NIST CSF 2.0 | Recovery Function (RC) Category RC.1.1 requires identification of assets and critical resources to enable recovery planning |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →