Without clear recovery documentation, when a crisis hits, your team wastes critical hours figuring out what to do instead of fixing the problem. For example, a manufacturing company in Bangalore lost ₹8 lakhs in revenue when their billing system crashed because no one knew the recovery steps—the IT person was on leave and no written guide existed. Unclear or missing recovery instructions can also cause you to fail compliance audits (DPDP Act requires you to show you can recover personal data), lose customer trust if they find out you couldn't restore their data, and miss regulatory deadlines for incident reporting because you didn't know how fast you could recover.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no written recovery steps at all; people call the IT person or vendor and hope they remember what to do. Your business grinds to a halt while waiting for someone to figure it out.
Initial
You have some recovery steps written down, but they're scattered in emails, on someone's personal notes, or buried in technical documentation that only the IT person understands. During a real incident, no one else can follow them.
Developing
You have recovery steps documented in one place in simpler language, but they haven't been tested and some details are missing or outdated. An employee could roughly follow them but might get stuck.
Defined
You have clear, step-by-step recovery documentation in simple language, tested at least once, and stored where the team can find it. Most people could follow it with minimal help, though not all edge cases are covered.
Managed
You have complete, tested recovery procedures for all critical systems, written in plain language with screenshots and decision trees, stored in an accessible location, and reviewed every year. Most people can follow them with confidence without needing the IT person.
Optimised
You have detailed, tested recovery playbooks for all systems, regularly practiced through drills, automatically updated when systems change, stored in multiple accessible locations, and verified to work. Your team can execute recovery confidently even during high stress.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Meet with your IT person or system vendor and ask them to write down the top 3 recovery steps (e.g., restart server, restore from backup, contact support). Write it in plain language, not technical jargon. Store it in a shared document or printed folder. | Business owner or IT person | 1 day |
| 1 → 2 | Consolidate all scattered recovery notes into one clear document. Add a table of contents, simple step-by-step instructions for each critical system (billing, email, website, inventory, etc.), and contact numbers for vendors. Use bullet points and short sentences. | IT person with business owner review | 1 week |
| 2 → 3 | Test the recovery steps on a test system or after-hours. Fix any missing or outdated steps. Add screenshots, warning signs (e.g., 'if you see this error, do this'), and a decision tree ('If system X won't start, check Y first'). Store copies in your office and email to key staff. | IT person with one other staff member | 2-4 weeks |
| 3 → 4 | Document recovery steps for all critical systems, not just one or two. Add estimated recovery time for each, checklist-style verification steps, and a quick reference card for the most common scenarios. Train all relevant staff to use the document. | IT person with business owner oversight | 1-2 months |
| 4 → 5 | Run quarterly recovery drills (half-day practice exercises where you actually follow the steps). Update documentation based on what you learned. Store recovery guides in multiple places (printed in a binder, on a USB drive, in cloud storage, and posted near the server). Integrate recovery steps into your IT change management process so they stay current. | IT person with full team participation | Ongoing (4 hours per quarter plus updates) |
Documents and records that prove your maturity level.
- Disaster Recovery Plan or Business Continuity Plan document that lists all critical systems and their recovery steps in plain language
- Step-by-step recovery procedures for each critical system (e.g., 'How to restore the billing system from backup', 'How to restart the email server'), dated and version-numbered
- Decision tree or flowchart showing what to do if System A fails vs. System B fails, written for non-technical staff
- Evidence of testing: a log showing when recovery steps were tested, what worked, and what needed fixing (e.g., 'Tested on 15-Jan-2024, backup restore took 45 mins, updated step 4')
- Training record or sign-off sheet showing that relevant staff have read and understood the recovery documentation
Prepare for these questions from customers or third-party reviewers.
- "Show me your recovery documentation. Is it written in language that a non-IT person can understand, or is it full of technical jargon?"
- "When was this last tested? Can you show me evidence that someone actually followed these steps and confirmed they work?"
- "If your IT person is not available, could someone else in the team execute a recovery using only this documentation? Have you verified this?"
- "How do you keep this documentation up to date when systems change? What's your process for updating it?"
- "Where is this documentation stored? If your office burns down or is ransomed, can you still access it?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and store recovery documentation in an organized, searchable way | Google Docs / Google Drive (free tier, 15 GB storage) or Notion (free tier with limited features) | Confluence by Atlassian (₹5,000–15,000/year for small teams) or Microsoft SharePoint (included in Microsoft 365 at ₹500/month per user) |
| Create flowcharts and decision trees for recovery steps | Draw.io (free, desktop and web version) or Lucidchart free tier | Lucidchart (₹10,000–25,000/year) or Visio (₹15,000/year) |
| Set reminders and schedule recovery testing drills | Google Calendar (free) or Todoist free tier | Asana (₹8,000–20,000/year for small teams) or Monday.com (₹15,000–40,000/year) |
- Writing recovery steps in IT jargon (e.g., 'SSH into the DB server and run fsck') instead of plain language. Test it: can your office manager follow the steps? If not, rewrite it.
- Documenting recovery steps once and never updating them. When you upgrade your system, buy new software, or change vendors, the old steps become wrong and dangerous. Set a yearly review date and check it when anything changes.
- Keeping recovery documentation only on the IT person's computer or only in a cloud account they control. If they leave, fall ill, or the account is hacked, you lose access. Store copies on printed paper, USB drives, and cloud storage you control.
- Never actually testing the recovery steps before a real incident. A plan that hasn't been tested is just fiction. Run a test at least once a year, even if it's just a 30-minute walkthrough.
- Assuming one person (the IT person) is enough to execute recovery. Document it so at least two people could do it independently. This prevents a single point of failure.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(2) and Schedule 2: You must demonstrate ability to restore personal data in case of loss or damage; recovery documentation is proof of this capability |
| CERT-In 2022 | Directions 2.3.3: Entities must have documented incident response and recovery procedures; BCR-13 satisfies this requirement for recovery documentation |
| ISO 27001:2022 | Annex A, Control 8.36 (Information backup) and 8.38 (Information security incident management): Recovery procedures demonstrate control of backup and readiness to handle incidents |
| NIST CSF 2.0 | Recover function (RC): Specifically RC.RP-1 (Incidents are contained) and RC.RP-2 (Restoration activities are coordinated) require documented 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 →