Business impact analysis: deciding what has to come back first

A business impact analysis is the exercise of working out, process by process, what it costs you when that process stops and how long you can tolerate it being down. It sits underneath continuity planning and is the part most often skipped, which is why so many continuity plans read as a list of everything the company does with no order to it. Without the analysis, the plan cannot say what comes back first, and on the day it matters that is the only question anyone is asking.

What a business impact analysis produces

• A list of business processes, not systems — "processing payroll", not "the HR server".
• The impact of losing each one, over time: an hour, a day, a week. Most processes are harmless for a day and serious by Friday, and the shape of that curve is the useful output.
• A maximum tolerable outage per process, agreed with someone who can actually accept the consequence.
• A recovery time objective, which is the target you plan to, and a recovery point objective, which is how much data you can afford to lose.
• The dependencies each process needs: systems, people, suppliers, premises, data.
• The peak periods when the tolerance is much lower — a month-end, a seasonal trading week, a regulatory deadline.

Stopping everything from being critical

Ask each department how quickly they need to be back and every answer is one hour. The analysis is worth doing only if it produces a ranking, which means the question has to be asked in a way that has a cost attached.

1. Ask what actually happens if this stops — who notices, what breaks, what it costs, who complains — rather than how important it feels.
2. Force a comparison: if only three processes can be recovered on day one, which three? Ranking is easier than rating and much harder to game.
3. Put a number on it where you can, even a rough one. A process that costs nothing for three days will not win an argument against one that costs a customer.
4. Test the answers against real history — the last outage, the last supplier failure — because memory is more honest than the form.
5. Have the ranking approved by someone senior enough to defend it, since the day it is used is the day people will dispute it.

The recovery time objective is a decision, not a measurement. Setting a four-hour target for a system that takes two days to rebuild is not planning, it is wishing — and it is worse than an honest two-day target, because everyone downstream plans around a number that was never achievable.

Where the analysis goes wrong

• Done once and never revisited, so it describes a company that no longer exists.
• Built around systems rather than processes, which hides the manual workarounds that often make short outages survivable.
• Dependencies stopping at your own boundary, when the actual constraint is a single supplier — the same third-party question your vendor management should already be asking.
• People treated as interchangeable, when several processes in reality depend on one individual, which is a succession planning problem as much as a continuity one.
• Kept separate from the plan it exists to inform, so the business continuity plan is written without reference to the ranking.

Where the analysis lives

Ettex Sheets suits this well: a row per process with impact over time, the tolerable outage, the recovery objectives and the dependencies as columns, sortable so the ranking is visible rather than asserted. Keeping it as a table rather than a document is what makes the annual review a half-day instead of a rewrite. It feeds directly into the business continuity plan and the disaster recovery plan, which should not be restating the same facts in prose. Ettex does not model outage costs and cannot tell you what your tolerable downtime is — that number belongs to the business, not to a tool.