If your business continuity plan is outdated, it won't actually save you when disaster strikes. A manufacturing business in Gujarat suffered a ransomware attack last year—they tried to use their 2-year-old backup plan and discovered half their servers had changed and the recovery steps were useless; they lost 3 weeks of production and ₹15 lakh in lost orders. Without a current review, you won't know if your backups actually work, if key staff know what to do, or if your recovery time targets still match your real business needs. This puts you at risk of compliance failures with DPDP Act (which requires you to protect customer data) and customer contracts that demand certain uptime guarantees.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no written business continuity plan at all, or you have one from 5+ years ago that nobody has looked at. If something breaks, people just call the IT vendor and hope for the best.
Initial
You have a basic plan written down somewhere (maybe a Word file or email), but it hasn't been formally reviewed in over 12 months and nobody is sure if it still applies.
Developing
You completed a basic review sometime in the last 12 months—maybe an email saying 'we checked our backups' or a quick conversation with your IT support. It's documented but not thorough.
Defined
You did a formal, documented review in the last 12 months where you actually tested backups, checked that recovery steps match current systems, and updated the plan with any changes. Key staff were involved.
Managed
You review your plan every 6 months or after major system changes, you test recovery procedures with actual drills, and staff sign off that they understand their roles. Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are measured and tracked.
Optimised
Your plan is reviewed and tested quarterly with full team participation, recovery procedures are automated where possible, and lessons from drills are documented and drive continuous improvements. Plan is integrated into all hiring and system change processes.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Create a simple 1-2 page written Business Continuity Plan listing critical systems, key staff contacts, and basic backup/recovery steps. Get owner sign-off. | IT Manager or Owner | 3-5 days |
| 1 → 2 | Schedule a 2-hour meeting with IT and operations staff to review the existing plan against current systems, update contact numbers and system names, and document what changed. Create a simple checklist of what was reviewed. | IT Manager + Operations Lead | 1 week (including follow-up updates) |
| 2 → 3 | Conduct a full formal review: test at least one backup restoration to actual hardware, verify recovery time estimates are realistic, walk through the plan with 2-3 key staff, document findings and sign-off. Update plan with gaps found. | IT Manager with Operations and Finance input | 2-4 weeks |
| 3 → 4 | Establish a semi-annual (6-month) review schedule; run a tabletop drill with staff where you walk through a real outage scenario; measure actual RTO/RPO for critical systems and document it in the plan; create a log of all reviews and test results. | IT Manager + Department Heads | 1-2 months to set up, then 2-3 days per review |
| 4 → 5 | Automate recovery testing, integrate BC plan review into change management process, run full recovery drills 2x per year with post-drill reports, track metrics in a dashboard, make BC part of onboarding for all new hires. | IT Manager with cross-functional team | Ongoing (average 5-10 hours/month) |
Documents and records that prove your maturity level.
- Dated sign-off document or meeting minutes showing BC plan was reviewed within last 12 months (include date, who reviewed it, and what was checked)
- Updated Business Continuity Plan document with current system names, staff roles, contact details, and recovery procedures (version number and date on document)
- Records of any backup tests or recovery drills performed in last 12 months (test date, systems tested, time taken, pass/fail, signed off by IT)
- List of Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for critical business systems with dates measured or last confirmed
- Log or spreadsheet tracking all BC plan reviews, dates, what was changed, and who approved changes
Prepare for these questions from customers or third-party reviewers.
- "When was your business continuity plan last formally reviewed, and can you show me evidence of that review?"
- "What critical business systems are covered in your plan, and how do you know your backups for those systems actually work?"
- "If your main server failed today, how long would it take to recover it, and have you tested that time recently?"
- "Who on your staff knows the recovery procedures, and how do you ensure they are trained and ready?"
- "What changes have happened in your business in the last 12 months (new systems, staff, locations, customers), and how did those changes get reflected in your BC plan?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and document your Business Continuity Plan in a simple template format | Google Docs or Microsoft Word template (search 'BC plan template'); NIST has free templates at csrc.nist.gov | Plan Cloud (₹5,000-15,000/year) or Everbridge (enterprise pricing, ₹50,000+/year) |
| Track backup test results and maintenance schedules to show plan is being followed | Google Sheets or Excel with simple checklist; Trello free version | Veeam Backup & Replication (₹2-5 lakh/year for SME) or Backblaze (₹50,000-1,50,000/year) |
| Schedule and log regular BC plan reviews and drills with team calendar integration | Google Calendar with shared notes; Microsoft Teams free version | OneDrive + SharePoint (₹8,000-20,000/user/year) or Asana (₹10,000-50,000/month) |
- Writing a BC plan once and then never looking at it again because 'we're covered'—without regular review, the plan becomes useless when your systems or staff change
- Testing backups only on request from an auditor instead of regularly—by then you may discover the backups have been failing silently for months
- Creating a BC plan but not training anyone on it—when crisis hits, nobody knows what to do with the fancy document
- Focusing only on IT recovery and forgetting about business processes—a backup that restores servers in 2 hours is worthless if your accounting staff don't know how to re-enter yesterday's transactions
- Assuming your backup vendor 'handles' business continuity—you are responsible for testing and proving the plan works, not the vendor
- Not documenting RTO/RPO targets—without knowing how long you can afford to be down, you can't build an effective recovery plan or measure success
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Lawful basis) and Schedule 2 (Consent requirements); Section 25 (Accountability); requires documented systems and procedures to protect personal data |
| CERT-In 2022 | Direction 4.1 (Backup and Recovery) and Direction 4.4 (Business Continuity); mandates organizations maintain and test BC plans; applicable if handling critical infrastructure or customer data |
| ISO 27001:2022 | Clause A.8.13 (Backup) and A.8.14 (Redundancy); requires periodic review and testing of backup procedures and BC plans |
| NIST CSF 2.0 | Govern (GV) function GV.RR.01 (Governance and resilience review) and Recover (RC) function RC.RP.01 (Recovery planning); requires documented, tested, and reviewed BC and disaster recovery |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →