Outdated continuity plans become useless when a real crisis hits—you'll waste hours or days realizing the plan doesn't match your current setup, losing customers and revenue while you scramble to recover. For example, a Bangalore IT consulting firm that moved from on-premises servers to cloud infrastructure but didn't update their recovery procedures discovered during a ransomware attack that their backup restore process no longer worked, costing them 48 hours of downtime and three lost client contracts. Banks and financial clients now require proof of updated plans before renewing vendor contracts, so outdated plans can directly block new business. Regulatory audits (GST, income tax, ISO certifications) increasingly check this—failure to show updated plans can result in audit flags or compliance failures that affect your business reputation.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no written continuity plan at all, or you have an old plan from 2019 that nobody has looked at since. When asked where the plan is, people shrug and point to a dusty folder or a forgotten email.
Initial
You have a basic continuity plan written down, but it was last reviewed more than 12 months ago and nobody documented whether it still matches your current systems and staff. The plan exists but feels disconnected from how the business actually operates today.
Developing
You have a continuity plan that was updated within the last 12 months, covering critical systems and key business functions. However, updates were ad-hoc (done only when someone remembered) rather than triggered by actual business changes.
Defined
You have a documented continuity plan that lists which business changes (new location, new software, staff changes) should trigger a plan review, and you updated it at least once when a planned trigger occurred. Someone owns the responsibility for keeping it current.
Managed
Your plan is reviewed and updated automatically whenever a significant business change happens—new system rollout, office relocation, new department, process changes—and updates are recorded with dates and what changed. Testing happens at least annually and plan revisions reflect test findings.
Optimised
Your continuity plan is living and actively maintained, with quarterly reviews whether or not changes occurred, full testing at least annually with documented results, and immediate updates after any business change or test failure. Team members know the current plan and can execute it without delays.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Write down a basic one-page continuity plan listing your 3–5 most critical business functions (e.g., customer orders, payroll, email), what systems they depend on, and rough recovery steps. Get it signed off by owner or operations lead. | Business owner or IT person | 1 day |
| 1 → 2 | Conduct a structured review of the existing plan by walking through your actual current systems, locations, and staff. Update the plan to reflect reality today (new servers, cloud tools, new office, remote staff, etc.). Record the review date and what was changed. | IT person with operations input | 3–5 days |
| 2 → 3 | Create a change-trigger checklist (new software purchase, office move, hiring a new critical role, etc.) and assign one person to own continuity plan maintenance. Schedule quarterly plan reviews. Document at least one update triggered by an actual business change. | Business owner and IT person | 1–2 weeks |
| 3 → 4 | Run a tabletop test or simulation of your recovery plan (simulate a server failure or office closure). Document what worked and what didn't. Update the plan based on test findings and set up an annual testing schedule. | IT person with key staff | 2–4 weeks (including test execution) |
| 4 → 5 | Integrate continuity plan reviews into your regular business operations cycle (quarterly or after every significant change). Brief entire team on current plan. Track and communicate all updates. Measure recovery time objectives (RTO) and recovery point objectives (RPO) from real tests. | Business owner, IT person, operations manager | Ongoing (2–3 hours per quarter plus test time annually) |
Documents and records that prove your maturity level.
- Continuity or disaster recovery plan document dated and signed, with documented review or update history (dates and changes noted)
- List of critical business functions and systems, with dependencies mapped out
- Change trigger checklist or policy document naming what business changes require plan review (new systems, relocations, staff changes, etc.)
- Evidence of at least one plan update tied to an actual business change (email, meeting notes, revision date on document showing what changed and why)
- Test execution records or tabletop test summary showing plan was tested, gaps found, and remediation actions taken
Prepare for these questions from customers or third-party reviewers.
- "When was your continuity plan last reviewed or updated, and what business changes prompted that update?"
- "Walk me through a scenario: if your main office becomes unavailable tomorrow, what does your team do first according to the plan? Is that still accurate with your current setup?"
- "How do you ensure the plan stays current when you hire new staff, add new systems, or move locations? Who is responsible?"
- "Have you ever tested this plan, even informally? What did you find, and did you update the plan based on test results?"
- "Show me evidence that your plan reflects your current systems (cloud vs. on-premises, remote staff, current vendors, etc.)—not a two-year-old version."
| Purpose | Free Option | Paid Option |
|---|---|---|
| Simple plan documentation and version control | Google Docs or LibreOffice Writer with document history tracking enabled | Microsoft Word with SharePoint version history (included in Office 365, approx ₹5,000–12,000/year for small team) |
| Create flowcharts and diagrams of systems and recovery steps | Lucidchart free tier (limited) or Draw.io (free, open-source) | Lucidchart professional (approx ₹8,000–15,000/year) or Visio (included in Microsoft 365) |
| Track and schedule plan reviews and tests | Google Calendar with shared ownership or Trello free board | Monday.com or Asana (approx ₹2,000–8,000/month for small team) or Jira (approx ₹7,000–15,000/month) |
- Plan written once, then never touched again—teams grow, systems change (especially migration to cloud), but the old plan stays on the shelf. Indian businesses often assume 'if it worked last year, it still works' without verifying.
- Plan exists but is disconnected from reality—it still lists an old office that closed, refers to a system that was replaced, or assumes staff that left the company are still available to execute recovery steps.
- Triggers for updates not defined—there's no clear rule for when to update the plan, so updates happen randomly or never. A new software platform is deployed but the plan isn't touched until a crisis forces someone to notice it's broken.
- Testing only done on paper or never—auditors and compliance teams can spot when a plan has never been tested because recovery steps are vague, time estimates are unrealistic, or the plan lacks specific contact numbers and escalation chains.
- Single point of failure in knowledge—only one person (often the IT person) knows the plan; if they leave or are unavailable during a crisis, the plan becomes useless. No team briefing or documentation ensures shared understanding.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (data protection by design and default) and Schedule 2 (reasonable security practices)—requires organizations to maintain and periodically update incident response and continuity plans |
| CERT-In 2022 Directions | Direction 5 (incident handling) and Direction 6 (business continuity planning)—mandates critical infrastructure operators maintain and test continuity plans; applies to all organizations post-notification by CERT-In |
| ISO 27001:2022 | Clause A.17.1 (information security continuity) and A.17.2 (redundancy)—requires organizations plan, document, and test business continuity to ensure availability and redundancy |
| NIST CSF 2.0 | RECOVER function (RC.RP: Recovery planning) and RECOVER function (RC.RP-1: Recovery plan is kept current with business and technical changes) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →