How detailed should a business impact analysis be?
A business impact analysis needs enough detail to justify a recovery time objective for each critical process, and no more than that. Depth is set by decision usefulness, not by template completeness. Most analyses go too granular on process mapping and too shallow on the dependency and recovery data that decisions are actually made from. If two entries would carry an identical recovery time objective, recovery resources and escalation owner, they belong in one line, not two.
Published · Updated
Maximilian Bazzi, Founder and CEOWhat level of process detail is actually useful?
A process is worth analysing on its own when a disruption to it would require a distinct recovery decision. If two processes always recover together and share the same dependencies, splitting them into separate line items adds volume without adding a decision that anyone will make differently. A useful rule: if the recovery time objective, the recovery resources and the escalation owner would be identical for two processes, they belong in one entry, not two.
This is where most business impact analyses drift. A template with two hundred rows looks rigorous, but if a hundred of those rows share an identical answer, the extra detail has made the document harder to maintain and no more decision-useful.
What data actually drives a recovery time objective?
Three things determine whether a recovery time objective is defensible: the point at which a disruption becomes a financial, regulatory or safety problem, the dependencies (systems, third parties, people, facilities) that have to be restored before the process can run, and the current recovery capability against those dependencies. A recovery time objective set without reference to actual dependency recovery capability is an aspiration, not a plan. This is the detail worth spending time on, more than the process inventory itself.
Where teams commonly run into difficulty
Two failure patterns show up repeatedly. The first is scope creep in the opposite direction from what is useful: exhaustive process mapping paired with a one-line dependency section, so the document cannot actually be used to plan recovery. The second is a business impact analysis built once and never revisited against organisational change, so it accurately describes an organisation that no longer exists by the time an incident tests it.
Both are usually a design problem, not an effort problem. The taxonomy the analysis is built against, and the cadence for revisiting it, matter more than how many workshops were run to produce the first version.
How Bazzi Consulting helps
We design the business impact analysis around the recovery decisions your organisation actually needs to make, then set the cadence and ownership so it stays current rather than becoming a one-off deliverable. See risk and resilience advisory for how this fits into a wider programme.