Monsoon Flooding in Nepal: A Digital Preparedness Checklist for Businesses

Monsoon disruption is a recurring feature of operating in Nepal. Rivers rise, roads close, power goes out for extended periods and staff cannot reach an office. None of that is a surprise, which is exactly why so much of the damage is avoidable. The following is the checklist we work through with clients before the season, not during it.

One framing point before the list. The disruption that costs a small business money is rarely the dramatic one. It is more often a week in which the office is unreachable, the accountant's laptop is in a flooded building, the person who knows the hosting password is stuck in their district, and orders keep arriving that nobody can see. Almost every item below exists to remove one of those single points of failure.

Know where your business actually lives

• List every system the business needs to take an order and fulfil it.
• For each, record where the data physically sits and who can restore it.
• Flag anything that exists only on one machine in one building.
• Note which supplier you would have to phone if that machine were underwater.
• Write down who holds the credentials, and make sure that is more than one person.

That last item is the one that catches people. Domain registrar logins, hosting panels, the payment gateway account, the business phone number's SIM, the social pages: these are usually held by one person, often on one device, sometimes on a personal email address that nobody else can reach. Put them in a shared password manager with at least two people holding access, and check that recovery codes are stored somewhere that is not the same device. This costs an afternoon and it is the highest-value item on this page.

Backups you have actually restored

An untested backup is a belief, not a plan. Once before the season, restore a real backup into a scratch environment and confirm the business could run from it. The number of teams that discover a broken backup chain during a flood, rather than in a quiet week in spring, is the reason this item is first among equals.

Two failure modes recur. The first is a backup that runs but omits something critical, most often the database, the uploaded files, or the environment configuration that makes the application boot. The second is a backup stored in the same building or the same account as the original, which means one incident takes both. Aim for at least one copy that is off-site, one that is offline or otherwise not deletable by whoever has the main account, and a written note of how long a restore takes. That last number is the one to tell the owner, because it converts an abstract risk into a business decision about whether four hours of downtime is acceptable.

Power and connectivity

Extended outages are a certainty rather than a risk. Battery capacity for the router matters as much as for the laptops. A mobile data plan on a second network provides a fallback when one operator's local infrastructure is affected. Keep the numbers written down offline, because the contact list is usually on the device that ran out of charge.

• A small UPS or battery pack for the router and the ONT, not just the computers, since a laptop with no internet is a paperweight.
• A tested mobile hotspot on a different operator from the office line.
• Enough power bank capacity to keep two phones alive for a day without mains.
• A printed one-page contact sheet: staff, key suppliers, the hosting provider, the bank, the landlord.
• A known place to work from if the office is unreachable, agreed in advance rather than negotiated by message on the day.

The plan you can execute on a dead battery is the only plan you have.

Move what you can off the ground floor and out of the building

If a server, a NAS or the only copy of the accounts sits on a ground floor in a flood-prone area, the monsoon is not the time to discover it. Physical measures are cheap and unfashionable: raise equipment above the likely water line, keep it off the floor and away from the wall, and move anything that does not have to be on site to a hosted service. Whether a particular building is exposed is a question you can partly answer yourself from open elevation and settlement data, using the method and the caveats in mapping flood risk with open data.

Moving systems to a hosted provider is not automatically the answer, and it is worth being honest about the trade. A cloud service removes the flooded-server-room risk and replaces it with a dependency on connectivity and on somebody paying the bill on time. For most small Nepali businesses that trade is clearly worth making, particularly for email, accounting and the website. The practical approach to doing it without overspending is covered in DevOps on a budget for startups, and the day-to-day upkeep it still requires in what website maintenance actually involves.

Communicating when you are disrupted

• Prepare a short holding message in Nepali and English before you need it.
• Decide in advance who is authorised to publish it.
• Know how to update your website, social pages and any listing without office access, and confirm someone can do it from a phone.
• Give staff a single channel to check, Viber group or otherwise, so information does not fragment across five threads.
• Commit to an update time in the message itself, and meet it even if the update is that nothing has changed.

The most common communications failure is silence followed by a long explanation a week later. Customers forgive disruption and do not forgive being ignored. A two-line notice saying what is affected, what still works and when you will next post is enough, and it takes five minutes if it was written in advance and thirty if it was not.

Know where the official warnings come from

Before the season, find out which official channels cover your location and put them in front of the person who makes the decision to close early or move stock. That is the Department of Hydrology and Meteorology for river and rainfall warnings, the national and district emergency operations structure for response, and your own ward office for local instructions. Do not build your own forecasting, and do not rely on forwarded messages of uncertain origin, which circulate freely every monsoon. If you want to understand how those warnings are produced and where the chain typically breaks, we have written a plain explanation in how flood early-warning systems work.

Rehearse one thing, badly, before June

A full drill is unrealistic for a small business. A partial one is not. Pick a single scenario, the office is unreachable for three days, and walk through it in a meeting: who publishes the notice, where do orders get recorded, how does the accountant get to the books, who has the router password. An hour of this finds more gaps than any document, and it produces the specific list of things to fix while there is still time.

Afterwards

Write down what broke while it is fresh, including the small operational frictions. Those notes are the whole value of a bad week, and they are also what makes next year's checklist shorter. The recovery sequence itself, in the order it has to happen, is covered separately in getting a business running again after a flood.

A note on scope

This is business continuity, not disaster response. For warnings and evacuation, follow the guidance of the national authorities and local officials. Technology plans should route people to those sources rather than compete with them. The wider regional picture, including who pays for adaptation infrastructure and why so much of it stalls after the pilot, is in climate tech in South Asia.