A plan that has never been tested almost always fails when you actually need it. For example, a Delhi-based manufacturing exporter discovered during a ransomware attack that their 'backup' procedure documented on paper didn't work because the backup system had been changed six months ago and nobody updated the plan. They lost a week of production and missed a major shipment deadline, losing ₹8 lakhs in revenue and a customer contract. Without periodic testing, you won't know which steps are broken, who actually knows their role, or whether your backups even work until disaster strikes—by which time it's too late.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no documented continuity plan at all, or if one exists, nobody has ever discussed it or tested it. When something critical breaks, people just figure it out as they go.
Initial
You have a basic continuity plan written down, but it has never been tested or reviewed. Your team may not even know where it is or what their role is supposed to be.
Developing
You have a documented plan and you've discussed it once or twice informally with key staff, but no actual testing has happened. You're relying on hope that it will work.
Defined
You conduct a tabletop discussion or walkthrough of your continuity plan once a year, where key team members talk through what they'd do. You've identified some gaps but haven't fixed them all.
Managed
You run a partial test or drill at least once a year where you actually simulate a failure (for example, unplugging the server or blocking access to a key application) and observe whether the documented steps work. You document the results and fix identified issues.
Optimised
You test your continuity plan at least twice yearly through realistic simulations or drills, update it based on findings, review it quarterly with all stakeholders, and maintain a record of each test with lessons learned. Testing is part of your normal annual cycle.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Write a one-page continuity plan that lists: (1) your critical business functions (e.g., order processing, website, customer support), (2) who owns each function, (3) what systems they depend on, (4) basic recovery steps. Include names and phone numbers. | Business owner or IT manager | 2-3 days |
| 1 → 2 | Schedule a 90-minute team meeting where you walk through the plan step-by-step with the relevant people (finance, operations, IT). Ask each person: 'Do you know what to do? Is this realistic?' Write down their feedback. | Business owner (facilitator) | 1 day (meeting + notes) |
| 2 → 3 | Conduct a tabletop exercise: gather key staff, describe a realistic failure scenario (e.g., 'Our server caught fire overnight'), and walk through the plan together step-by-step. Write down what's missing or unclear. Update the plan. | IT manager or external consultant | 2-3 weeks (planning + 2-hour exercise + updates) |
| 3 → 4 | Run one actual drill: simulate a real scenario (e.g., shut down a key server or block access to a critical application for 30 minutes) and execute the recovery steps. Time it. Document what worked and what didn't. Fix the broken parts. | IT manager with business owner oversight | 4-6 weeks (planning + execution + remediation) |
| 4 → 5 | Schedule two full drills per year (e.g., one in March, one in September). After each, hold a review meeting, document lessons learned, and update the plan. Add this to your annual compliance calendar. | Business owner (owner of calendar), IT manager (executor) | Ongoing (4 hours per drill + 2 hours per review) |
Documents and records that prove your maturity level.
- A written Business Continuity Plan or Disaster Recovery Plan document with date of last update, list of critical functions, recovery procedures, contact details, and estimated Recovery Time Objectives (RTOs)
- A record or log of at least one discussion, tabletop exercise, or drill conducted in the past 12 months, including date, participants, and topics covered
- Documentation or notes from a test or drill (e.g., date, scenario simulated, results, issues found, corrective actions taken)
- Updated or revised plan version that shows changes made based on test findings and feedback
- A schedule or calendar showing planned testing activities for the current or next year
Prepare for these questions from customers or third-party reviewers.
- "When was your continuity plan last tested, and what was the scenario? Can you show me the test report?"
- "Who is responsible for executing each step in your plan, and when was the last time you confirmed they understood their role?"
- "What gaps or issues were identified in the last test, and what have you done to fix them?"
- "If your primary data center or internet connection went down today, how long would you realistically be without service, and how would your customers know?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and manage your continuity plan document in a shared, version-controlled location | Google Docs or Microsoft Word (free online versions); Notion (free tier) | Microsoft 365 Business or Google Workspace: ₹300–600/user/month |
| Schedule and log test activities, document results, and track corrective actions | Google Sheets or Excel (templates available online); Trello (free tier up to 10 cards) | Asana, Monday.com, or Jira: ₹1,500–5,000/month for small team |
| Simulate critical failures (outages, ransomware, data loss) to test recovery procedures without using real systems | Gremlin Community Edition (controlled chaos testing); manual testing scripts written in-house | Gremlin Pro: ₹30,000–100,000/year; Incident.io or OnPage: ₹50,000–200,000/year |
- Writing a plan but never updating it when systems, staff, or processes change—so the plan becomes useless. Six months after you write it, your backup vendor changes or someone leaves, and the plan is stale.
- Testing only the IT side (backups and recovery) but not the business side—nobody talks to the finance team about how they'll process refunds or verify data integrity, or to sales about how they'll communicate with customers during an outage.
- Announcing the test in advance and having everyone 'prepare' so the test passes artificially—but in a real emergency, there's no preparation. Run drills by surprise or with minimal notice to catch realistic problems.
- Assuming that because you have backups, recovery is automatic—but never actually restoring from backup to verify it works. Many Indian businesses have discovered their backup is corrupt only when they needed it.
- Keeping the plan and test results secret to 'avoid liability' or audit embarrassment—but this means no one learns, and you repeat the same mistakes in the next crisis.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(1) and Schedule 2 (Data Protection Obligations): Requires data fiduciaries to implement appropriate safeguards, including recovery and resilience measures |
| CERT-In 2022 | Direction 4: Indian Computer Emergency Response Team mandates testing of incident response and disaster recovery plans for critical infrastructure operators |
| ISO 27001:2022 | Annex A, Control A.8.1 (Backup) and A.17.1 (Incident planning and preparation); requires periodic testing and review of controls |
| NIST CSF 2.0 | Respond (RS) and Recover (RC) functions; RS.RP-1 and RC.RP-1 require planning and testing of response and recovery procedures |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →