Without clear responsibility assignments, during a crisis everyone panics, nobody takes charge, and response is chaotic—wasting precious time when minutes matter. A textile exporter in Tamil Nadu lost ₹8 lakhs in a single day when their server crashed because nobody was officially responsible for checking backups or contacting the IT vendor, so the system stayed down for 16 hours. Similarly, a Bangalore BPO lost two major clients after a data breach because no one was designated to communicate with customers during the incident, creating a trust vacuum. Regulators and customers now expect to see a 'who owns what' plan before they sign contracts with you.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You walk in and find no written plan at all—when something breaks, people just figure it out on the spot or the owner handles everything by phone. There's no documented chain of command, no backup people, and no written procedures for anyone to follow.
Initial
You find a one-page document that lists the owner and maybe one IT person as responsible for 'everything,' but it's vague and nobody else knows what they should be doing if that one person is unavailable. The document sits in the owner's drawer and was never actually discussed with the team.
Developing
You find a basic Business Continuity Plan that names specific people for specific functions (IT lead, customer communication lead, finance lead) with one backup for each, and it was shared with the team once. However, the plan doesn't detail what each person actually does step-by-step, and it hasn't been tested or updated in over a year.
Defined
You find a detailed Business Continuity Plan with clear role descriptions for at least 5-6 key positions, backup designations for each role, specific step-by-step procedures, contact phone numbers, and evidence that it was reviewed and updated within the last 6 months. Team members have been trained on their roles at least once.
Managed
You find a comprehensive, regularly maintained Business Continuity Plan that includes role descriptions, escalation procedures, backup assignments, detailed runbooks for common failures (server down, key person absent, data loss), multiple communication channels, and evidence of annual tabletop exercises where the team has practiced their roles. The plan is version-controlled and available to relevant staff in multiple formats.
Optimised
You find a mature Business Continuity & Disaster Recovery framework that is tested quarterly through live exercises (not just tabletop), with documented results and continuous improvement cycles. New hires receive induction training on their BC responsibilities, third-party dependencies are managed with SLAs, and the plan is dynamically updated based on actual incidents, near-misses, and evolving business risks.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Hold a 1-hour meeting with the owner and 2–3 key people (IT, operations, customer service). Write down: (a) What are the 3–5 things that would hurt us most if they stopped working? (b) Who should handle each? Create a simple one-page 'BC Roles & Responsibilities' document naming the owner and at least one other person. Print it and keep it visible. | Business owner with HR or operations manager | 1 day |
| 1 → 2 | Expand the one-page list into a 5–10 page BC Plan document. For each critical function (IT, customer comms, finance, operations), write: (a) Person responsible and their backup; (b) What they do in a crisis (3–5 key actions); (c) Emergency contact numbers; (d) Who they report to. Have a quick meeting with each person to confirm their role and explain it to them. Save it as a shared document and send it to the team. | Operations manager or IT person, with input from function heads | 1 week |
| 2 → 3 | Convert the BC Plan into a detailed runbook for the top 3 crisis scenarios (e.g., 'Server down for 4+ hours,' 'Key person unavailable,' 'Data loss'). For each scenario, write step-by-step procedures (who does what, in what order, with timelines). Add detailed contact lists, vendor SLAs, IT system diagrams, and recovery procedures. Review and sign off by the owner. Schedule a 30-minute team walk-through for each scenario. Update the plan and date it. | IT person with operations manager, reviewed by owner | 2–4 weeks |
| 3 → 4 | Conduct a formal tabletop exercise: gather the team, present a crisis scenario, and ask each person to walk through their assigned steps verbally without using the runbook. Time them, note gaps, and document results. Based on findings, update the runbook. Train any new hires on their BC roles. Create a simple 'BC checklist' (one-page version) for quick reference. Set a calendar reminder to review and test the plan every 6 months. | Operations manager to facilitate; owner and all key staff to participate | 1–2 months (including follow-up documentation) |
| 4 → 5 | Run at least two realistic tabletop or live exercises per year (e.g., simulate a server down scenario and actually test backup systems). Document exercise results, measure recovery times, and identify improvement areas. Update the plan with lessons learned. Integrate BC responsibilities into annual performance reviews. Build strong relationships with third-party vendors (ISPs, cloud providers) and ensure their SLAs are clearly written and tested. Make BC a standing agenda item in quarterly management meetings. | Operations or quality manager to coordinate; owner and all staff to participate periodically | Ongoing (approximately 20–30 hours/year) |
Documents and records that prove your maturity level.
- Written Business Continuity Plan document (2+ pages minimum) that names specific individuals, their backup designations, and their crisis responsibilities
- Role & Responsibility Matrix table showing critical functions (IT, customer comms, finance, operations, procurement, etc.), assigned person, backup person, and their key duties during a disruption
- Detailed runbooks or step-by-step procedures for at least the top 3 critical failure scenarios (e.g., server outage, key person unavailable, ransomware, data loss), with timelines and decision trees
- Evidence of BC training or communication to staff: sign-in sheet from a BC plan review meeting, training record, or email confirmations showing that team members have received the plan and understand their roles
- Tabletop exercise report or incident debriefs from the past 12 months showing that the plan was actually tested, with documented findings and follow-up actions taken
Prepare for these questions from customers or third-party reviewers.
- "Show me your Business Continuity Plan. Who is responsible for IT recovery, and who is their backup if they're not available?"
- "Walk me through what happens on Day 1 if your main server fails or your internet is down for 8 hours. Show me the step-by-step procedure and tell me who does what."
- "When was the plan last tested or reviewed? Do you have evidence that your team has actually practiced their roles (a tabletop exercise or a real incident response)?"
- "If your IT person or operations manager is absent (vacation, illness, termination), does someone else know how to execute the critical recovery procedures? How do you ensure continuity of knowledge?"
- "Who has access to this plan, how is it distributed, and how do you ensure it stays current? Show me a version date or change history."
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and maintain BC Plan documents, role matrices, and runbooks collaboratively and keep them version-controlled | Google Docs (free; use folder sharing and commenting) or Microsoft 365 Basic (₹99/month for cloud storage and version history) | Confluence (₹5–10 per user/month) or Notion (₹800–2000/year for team plan) |
| Organize BC exercise scheduling, tabletop facilitation, and store exercise reports or incident logs | Google Forms + Google Sheets (for recording exercise results and lessons learned) or Trello (free tier allows basic project boards) | Monday.com (₹999/month) or Asana (₹1,200–3,000/month for small teams) |
| Maintain emergency contact lists, escalation trees, and distribute critical BC information quickly during a real incident | Google Contacts with labels, or a shared Excel/Google Sheet with restricted access | StatusPage.io (₹299/month for incident communication) or Everbridge (custom pricing, ₹2,00,000+/year, typically for larger organizations) |
- Assigning everything to one person (usually the owner or IT person), creating a single point of failure—when that person is sick or leaves, the business has no idea what to do. Always name a backup person for every critical role, even if they have limited IT knowledge.
- Writing a BC Plan but never testing it or sharing it with the team, so it stays theoretical and unknown. The plan sits in someone's email archive and when a real crisis hits, nobody remembers it exists or knows what their role is supposed to be.
- Creating a plan for scenarios that don't match your actual business risks. For example, writing detailed procedures for 'office flooded' when your real risk is ransomware or losing internet connectivity. Focus on the top 3–5 things that would actually hurt your business, not generic scenarios.
- Failing to document procedures clearly enough for someone other than the author to follow them. Step-by-step runbooks must be written for someone unfamiliar with the system, with exact commands, URLs, contact numbers, and timelines—not just vague instructions.
- Not updating the plan when people leave, new systems are added, or vendor contact details change. A 2-year-old plan with outdated phone numbers and staff names is useless in a real crisis. Review and update at least once a year.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(1) and Schedule 2 (Reasonable Security Practices): businesses must establish documented incident response and continuity procedures for personal data systems |
| CERT-In 2022 | Annexure I (Critical Information Infrastructure Protection Rules): organizations handling critical systems must have documented BCP with defined roles and responsibilities for incident response |
| ISO 27001:2022 | Clause 8.3.4 (Information security incident management): requires roles and responsibilities to be assigned; Annex A 5.4 (Responsibilities for information security) |
| NIST CSF 2.0 | Governance (GV) function, especially GV.OC-01 (roles and responsibilities) and Resilience (RS) function for recovery planning and incident response coordination |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →