Business continuity discussions in software companies concentrate on infrastructure — multi-zone deployment, backups, failover. Those matter and they are not what stops an Indian services firm working. What stops it is a flooded arterial road during monsoon, a building-wide power failure with a generator that was never load-tested, a fibre cut affecting the office park, or a civic disruption that makes commuting unsafe for a day.
The single most effective preparation is that work does not depend on the office. That is now largely true for engineering and largely untrue for everything else — the finance team's records, the signed contracts, the desktop that runs one licensed application, the landline the client calls, the person who holds the only copy of something. Auditing what genuinely requires physical presence, and removing each dependency deliberately, is a week of work that converts a lost day into a normal one.
Connectivity redundancy is cheap and rarely arranged properly. Two providers on genuinely different physical paths, not two connections from the same building riser, plus mobile fallback for critical people. In managed office space you may not control the physical routing, which is worth asking about before signing rather than discovering during an outage. Test the failover by unplugging the primary during working hours; a redundant link nobody has switched to is an assumption.
Power planning needs the same scepticism. A building generator exists on paper in most Indian office parks; whether it starts, how long its fuel lasts, and whether it powers your floor's air conditioning as well as its sockets are separate questions. UPS capacity for network equipment matters more than for laptops, which have their own batteries. Ask the facilities team when the generator was last run under load, and note that the answer is frequently that nobody knows.
For a services firm the client-facing dimension is what protects the relationship. Contracts frequently contain availability or response commitments that assume your team is reachable, and a client whose escalation goes unanswered during your local disruption experiences a supplier failure regardless of the cause. Having a way to tell every active client what is happening, from a channel that does not depend on the affected infrastructure, is worth more to the relationship than the recovery itself.
Then rehearse one scenario a year, properly. Pick something plausible — the office is inaccessible tomorrow, or the primary internet link is down for a day — and run it: who decides, how are people told, what cannot be done, what do clients hear. The findings are always mundane and always useful: a contact list that is out of date, a system only reachable from the office network, a person whose approval is needed who has no remote access. Those are cheap to fix once identified and expensive to discover on the day.
