Business Continuity and Disaster Recovery for Indian SMBs

Business Continuity Planning (BCP) and Disaster Recovery (DR) determine whether your business survives a ransomware attack, a cloud outage, or a server-room flood. BCP covers staying operational — people, processes, vendors, communications. DR covers restoring your IT systems and data. Most Indian SMBs conflate them or ignore both. This guide explains what each covers, how to build a workable plan without a dedicated security team, and what DPDP and CERT-In now expect from you.

BCP vs DR — The Distinction That Matters

People use these terms interchangeably, but they are different scopes with different owners.

Business Continuity Planning is a business-level document: if the office is unreachable, a key vendor disappears, or a critical system is down for a week, how does the organisation keep serving customers? It covers people, supplier alternatives, communication scripts, and manual workarounds.

Disaster Recovery is a technology-level document: how do we restore specific systems and data to a known-good state, and in what order? It defines the team, the tooling, and step-by-step restoration procedures.

One complements the other. A DR runbook with no BCP means your technical team restores systems that no one in the business knows how to use in a crisis.

Core Concepts Every SMB Must Understand

Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

RTO is the maximum tolerable downtime — how long can your business operate before systems must be restored? An e-commerce checkout system might have an RTO of 1 hour. Your internal HR portal might tolerate 72 hours.

RPO is the maximum tolerable data loss — how far back in time can you afford to roll back? An RPO of 4 hours means you accept losing up to 4 hours of transactions. An RPO of zero means synchronous replication and near-zero data loss.

Setting realistic RTO/RPO for each system is the single most important step in DR planning. It drives every other decision: how much you invest in replication, how frequently you back up, and how much you spend on standby infrastructure.

xychart-beta
  title "RTO and RPO Tiers by System Criticality"
  x-axis ["Payment", "Auth/Login", "Customer DB", "Reporting", "Internal Tools"]
  y-axis "Hours" 0 --> 72
  bar [1, 2, 4, 24, 72]
  line [0.5, 1, 2, 8, 24]

Bar = RTO target (restore time). Line = RPO target (data loss window). Values are illustrative starting points — set yours by actual business impact.

The 3-2-1 Backup Rule

The 3-2-1 rule is the minimum viable backup standard: 3 copies of data, on 2 different storage media or services, with 1 copy offsite and offline (air-gapped from your primary network).

The offsite-offline copy is what saves you from ransomware. Ransomware routinely scans connected drives and mapped cloud storage for backup directories and encrypts those too. If your backup is reachable via SMB or a mounted S3 bucket with always-on credentials, it is not truly offsite.

Failover, Runbooks, and RTOs

Failover is switching from a failed primary to a standby — automatic (warm/hot) or manual (cold). Most SMBs run cold-standby DR: restore from backup when needed. That is acceptable, but the RTO is hours to days. Size your plan accordingly.

Runbooks are step-by-step procedures, not architecture diagrams. A runbook says: log into AWS console → launch EC2 from AMI ami-0a1b2c3d → restore RDS snapshot prod-2026-MM-DD → update DNS A record → verify health endpoint. Executable by any qualified person, not only the author. If DR depends on one person's memory, you have no DR.

Building Your DR Plan in Five Steps

Step 1 — Asset and Dependency Inventory

List every system your business depends on. For each: service name, data it holds, criticality tier (Tier 1 = mission critical, Tier 2 = important, Tier 3 = non-critical), owner, and where data lives. Most Indian SMBs discover more critical dependencies than expected — payment gateways, WhatsApp Business API, accounting SaaS, cloud PBX.

Step 2 — Assign RTO and RPO

For each Tier 1 and Tier 2 system, assign realistic targets. Involve the business owner, not just IT — a CTO who sets RTO = 1 hour without consulting the CFO may find the cost unjustified; a CFO who does not understand RPO may not realise they are accepting a full day's lost transactions.

Step 3 — Design Your Backup Architecture

Implement 3-2-1 for every Tier 1 and Tier 2 system. For cloud-hosted workloads:

1. Automated daily snapshots in the same region
2. Cross-region replication or export to a second provider
3. Periodic export to immutable object storage (S3 Object Lock, or Wasabi with immutability enabled)

Step 4 — Write Runbooks for Tier 1 Systems

Write runbooks executable under stress by someone who did not build the system. Include: incident declaration, who to call, step-by-step restore commands, integrity verification, and customer communication steps.

Store runbooks offline — printed binder, personal device, or a separate identity account. A runbook stored only in a Google Drive requiring corporate SSO is inaccessible when SSO is the system that is down.

Step 5 — Define Roles and Communication

Who declares a disaster? Who authorises emergency cloud spend? Who calls the bank, registrar, and cloud provider? Who communicates to customers? Assign each role to a primary and a backup. Store contact lists in physical form or on a personal device — not only in the corporate collaboration tool.

graph TD
    A[Incident Detected] --> B{Is it a security breach?}
    B -- Yes --> C[Isolate affected systems immediately]
    B -- No --> D[Assess service impact]
    C --> E[Notify CERT-In if data breach]
    D --> F{Is Tier 1 system down?}
    F -- Yes --> G[Declare DR event - notify DR lead]
    F -- No --> H[Raise support ticket - standard SLA]
    G --> I[Execute Tier 1 runbook]
    I --> J{Restore successful within RTO?}
    J -- Yes --> K[Verify data integrity against RPO]
    J -- No --> L[Escalate to vendor - consider failover region]
    K --> M{Data loss within RPO?}
    M -- Yes --> N[Restore service - communicate to customers]
    M -- No --> O[Assess business impact of data gap]
    L --> P[Activate cold standby or manual workaround]
    P --> N
    O --> N
    N --> Q[Post-incident review within 72 hours]

    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style C fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style E fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style G fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style I fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style J fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style K fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style L fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style M fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style N fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style O fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style P fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style Q fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style F fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style H fill:#1e3d2f,stroke:#10B981,color:#e2e8f0

Testing Your Plan

A plan that has never been tested is a hypothesis. CERT-In's published best-practice guidelines recommend annual DR exercises at minimum. The two main test formats are:

Tabletop Exercises

A tabletop is a structured discussion: the facilitator presents a scenario ("It is 2 AM Friday, your database is encrypted by ransomware") and walks through the response step by step. No systems are touched. The goal is to surface gaps — missing runbook steps, role ambiguities, unknown dependencies. Takes 2–3 hours; run quarterly.

Failover Drills

A failover drill tests whether recovery procedures actually work. For a cloud database: take a snapshot, delete the primary instance, restore from snapshot, time it, and verify data integrity. Disruptive — schedule in a maintenance window. Run Tier 1 drills at least annually.

Cloud DR Options for Indian SMBs

Ransomware Resilience — Where BCP/DR Directly Applies

Ransomware is now the most common trigger for DR execution in India. Attackers stay dormant for weeks so your most recent clean backup predates their presence, then delete or encrypt backups before deploying the payload.

Your DR plan must address:

1. Backup immutability — object-lock or write-once storage so backups cannot be deleted by a compromised credential
2. Backup age audit — median attacker dwell time globally is 10 days per Mandiant M-Trends 2024; test restores from 30-day-old backups too
3. Network segmentation — DR infrastructure on a separate account and network segment, not reachable from production
4. Pre-negotiated vendor contacts — cloud account team, cyber insurance carrier, and a CERT-In empanelled incident response partner should all be in your runbook before you need them

DPDP and CERT-In Expectations

The Digital Personal Data Protection Act 2023 requires Data Fiduciaries to implement appropriate technical and organisational measures to safeguard personal data. If personal data is lost or made unavailable due to a preventable incident, the Data Fiduciary is liable. CERT-In's Cyber Security Framework for organisations recommends BCP/DR as a baseline control.

Practical compliance requirements:

1. DR plan must be documented, reviewed annually, and demonstrable to an auditor
2. Backup procedures for systems holding personal data must be explicitly documented
3. Any ransomware event where data may have been accessed triggers DPDP breach notification obligations — your BCP must include a notification workflow
4. CERT-In's April 2022 directions require reporting ransomware incidents within 6 hours of detection

Bachao.AI's automated VAPT identifies the external attack surface vulnerabilities most commonly exploited as ransomware entry points. If you have not run a free VAPT scan on your internet-facing assets, your DR plan is missing the threat intelligence it needs to be credible. Dhisattva AI Pvt Ltd builds tools that close this gap for resource-constrained Indian SMBs.

NIST's Contingency Planning Guide for Federal Information Systems (SP 800-34) remains the most comprehensive reference for building DR plans, adapted here for the Indian SMB context.