NCSRC NIRMATA
Home Guides Framework Start Assessment →
Home › Guides › Business Continuity & Resilience › BCR-05
BCR-05 Business Continuity & Resilience 4% of OML score

Is there an understanding of how long the business can operate without key systems?

Do you know how many hours or days your business can keep running if your main computer systems (billing, inventory, email, accounting) go down? This question asks whether you've actually figured out which systems are most critical and how long you can survive without them before customers, operations or money are seriously affected.

⚡
Why This Matters to Your Business

Without knowing your limits, you cannot make smart decisions about what to fix first when disaster strikes. If a manufacturing unit in Bangalore loses their ERP system for 3 days, they cannot bill customers, track raw materials, or plan production—and lose ₹5-10 lakhs in revenue while competitors fulfil orders. A textile exporter in Tiruppur without this knowledge may not realise their customs clearance system failure blocks shipments for a week, causing demurrage charges and angry international buyers who cancel repeat orders. When GST or TDS audits happen, if you cannot quickly restore your accounting software, you miss filing deadlines and face penalties. Without this baseline, you waste money fixing non-critical systems first, while true business killers remain vulnerable.

📊
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 which systems matter most. When someone asks 'how long can we run without the billing system?', the answer is a guess or silence.

Level 1
Initial

You can name 3-4 critical systems (like billing, inventory, email) but you have not actually tested or timed how long the business survives without them. Your estimate is based on opinion, not reality.

Level 2
Developing

You have written down which 5-7 systems are critical and estimated survival time for each (e.g., 'billing: 2 days, email: 4 hours, payroll: 1 week'). These estimates are reasonable but not tested or validated.

Level 3
Defined

You have documented critical systems with time estimates, and you have done at least one real test or simulation where you deliberately turned off a system and timed how long before actual business impact occurred. You have a simple Recovery Time Objective (RTO) list.

Level 4
Managed

You maintain an updated inventory of all critical systems with tested RTO values (not guesses), and each department head (finance, operations, sales) has confirmed their own system dependencies and survival limits. You revisit this at least twice per year when systems change.

Level 5
Optimised

Your critical system list is dynamic, tested quarterly through controlled outage simulations, integrated into your disaster recovery plan with assigned recovery teams, and regularly reviewed with staff. Every new system addition triggers an automatic RTO assessment before deployment.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 Call a 1-hour meeting with your finance manager, operations manager, and IT person (if you have one). Write down: which 4-5 systems would cause immediate business problems if they stopped working today? Assign rough survival times (hours or days) using common sense. Business owner or operations manager 2 hours
1 → 2 Interview each department (finance, sales, operations, HR) separately for 30 minutes each. Ask them: 'If system X stopped right now, how long before customers complain or staff cannot work?' Document the answers in a simple table with system name, department, and hours/days survived. IT person or operations manager 1 week
2 → 3 Pick one low-risk system (e.g., not your production database). Shut it down during off-hours and measure actual time before someone notices business impact or workarounds fail. Update your estimates based on real data. Document what happened and lessons learned. IT person with business owner approval 2-4 weeks (includes planning, testing, and documentation)
3 → 4 Create a formal 'Critical Systems Inventory' document listing system name, owner, RTO in hours, and what manual workaround exists (if any). Have each department head sign off that their RTO is realistic. Update it when systems are added or changed. IT person and department heads 1-2 months
4 → 5 Schedule quarterly 'disaster scenario' reviews where you pick a different critical system each quarter, simulate its failure, measure actual recovery time, and update the documented RTO. Train new staff on the procedure. Link RTOs to your backup and recovery procedures so they stay aligned. IT person with department heads, business owner oversight Ongoing (2-3 hours per quarter)
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • Written list of critical systems (at least 5-7) with assigned Recovery Time Objectives (RTO) in hours or days—can be a simple spreadsheet or table
  • Department sign-off document where finance, operations, sales, and HR managers confirm their system dependencies and agreed RTO values
  • Test or simulation report showing that at least one critical system was deliberately taken offline and actual survival time was measured and recorded
  • Disaster recovery plan or business continuity document that references the critical systems list and defines roles for recovery (who does what when a system fails)
  • Quarterly or bi-annual review record showing the RTO list was revisited, any changes were noted, and staff were notified of updates
🔍
What an Auditor Will Ask

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

  • "Walk me through your list of critical systems. How did you decide which ones are critical, and how were the RTO values determined—estimation or testing?"
  • "Tell me about the longest outage you have experienced in the last 2 years. How did you know how long the business could survive, and did actual impact match your expectations?"
  • "If your billing system failed right now, how many hours or days could you operate before losing customers or revenue? Show me the documentation that supports this number."
  • "When you add a new system (new accounting software, new e-commerce platform), how do you assess its RTO before going live? Can you walk me through a recent example?"
  • "How often do you validate your RTO estimates? When did you last test or review them, and what changed since the last review?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Create and maintain your critical systems list and RTO inventory in a simple, searchable format Google Sheets or LibreOffice Calc (spreadsheet template created by your IT person) Airtable (₹1,500-3,000/month) for more advanced tracking and team collaboration
Document disaster recovery procedures and assign recovery tasks to team members Google Docs or Notion (free tier sufficient for small team documentation) Confluence (₹5,000-8,000/month per team) if you have many procedures to manage
Schedule and track quarterly RTO validation tests to ensure estimates stay current Google Calendar or Trello (free tier) to organize test dates and record results Monday.com (₹1,500-5,000/month) or Asana (₹2,000-7,500/month) for larger teams managing multiple projects
🛡
How This Makes You More Resilient
When you know your RTOs, you stop guessing and start planning. You can invest in backups and recovery tools for your true business killers first (not nice-to-haves), and you know in advance whether you need redundant systems, manual workarounds, or faster recovery infrastructure. In a real outage, your team knows what to do and in what order, so recovery is faster and business loss is smaller—a 3-day outage might become a 6-hour outage.
⚠️
Common Pitfalls in India
  • Assuming your RTO estimates without testing—a manager might say 'email is critical, we need it within 2 hours' but never verified if staff actually need it that fast or have workarounds. Test at least one system to ground-truth your guesses.
  • Forgetting to include supporting systems (like your ISP/internet router, power backup, or cooling for your server room) in the critical list. A manufacturing unit may have a fast backup for their ERP, but if the power supply fails and no one has a generator plan, the ERP backup does not matter.
  • Not updating RTOs when the business changes—a small trading firm may set RTOs in 2022, but by 2024 if they expanded to e-commerce, their RTO for the website should be 4 hours, not 2 days. Annually review RTOs against current business priorities.
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 8 (Data Processor Obligations) and Schedule 2 (data security measures)—demonstrating RTO understanding shows preparedness for personal data recovery
CERT-In 2022 Directions Direction 5 (Incident Response and Contingency Plan) and Direction 6 (Business Continuity)—RTO documentation is core to acceptable contingency planning
ISO 27001:2022 Annex A.5.3 (Segregation of Duties), A.8.2 (Protection of confidentiality, integrity and availability), and A.17.1 (Planning of information security continuity)
NIST CSF 2.0 Govern (GV.RR-01, GV.RR-02), Protect (PR.BC-02, PR.BC-03), and Recover (RC.RP-01) functions for resilience planning and recovery

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