Keeping the business running

When the order system goes down, IT’s job is to get it back. Everyone else’s question is different: what do we do until then? Customers still phone, staff still need paying on Friday, and the van still arrives at four. Business continuity is the plan for that.

The international standard for it, ISO 22301, describes a management system to “protect against, reduce the likelihood of the occurrence of, prepare for, respond to and recover from disruptions”. In a small business, that comes down to three questions, asked before anything breaks:

1. What matters, and how fast does it hurt?
2. What does each part depend on? People, suppliers and IT systems.
3. What do we do by hand while it’s down, and who tells whom?

Business impact analysis

The first question has a formal name: a business impact analysis (BIA). NIST’s contingency planning guide ships a BIA template, and the core of it is simple. For each business process, ask how bad it gets if the process stops for four hours, a day, three days, a week. The last checkpoint before it turns severe is its limit, the maximum tolerable downtime, defined by NIST as “the amount of time mission/business process can be disrupted without causing significant harm”.

That limit sets the recovery order: the processes with the least tolerance come back first. It usually surprises people. The thing that feels important (the website newsletter that marketing loves) can wait a week, while the thing nobody thinks about (paying the flour supplier) can’t wait a week.

1. 1Start with what the business does, not with the IT systems: take orders, ship, pay staff, pay suppliers.
2. 2For each, how bad is it after four hours, a day, three days, a week? Ask the people who run it.
3. 3The last point before it turns severe is how long it can be down. Least tolerance comes back first.
4. 4Whatever cannot wait gets a workaround that does not need the broken thing. Then walk through a scenario and see what breaks.

Dependencies, workarounds and the phone list

Each process depends on things: people with particular knowledge, suppliers, IT systems, a building. A plan names them, and for anything that can’t wait, it names a workaround that doesn’t depend on whatever has failed. Workarounds are usually low-tech: paper order forms, the carrier’s website for labels, paying staff last month’s amounts from the bank’s site.

The plan also needs a communication plan: who declares that the plan is in effect, who calls staff, customers and suppliers, and what they say. Keep the contact list somewhere that doesn’t depend on the systems that might be down. A phone list that lives only on the file server is no help when the file server is the problem.

Test it on paper first

A plan nobody has tried has the same problem as a backup nobody has restored. The cheap test is a tabletop exercise: the people involved sit round a table, someone reads out a scenario (“the order system is down for two days”), and everyone says what they’d actually do, step by step. CISA publishes free tabletop exercise packages so organisations can “initiate discussions within their organizations about their ability to address a variety of threat scenarios” and then update their plans.

Do one now, for a small online bakery.