Should a business impact analysis be scoped at business service or business process level?

Why the level of scoping is not a detail

A business impact analysis scoped at business service level asks how long the organisation can be without a named service, such as payments processing or claims settlement, before harm becomes unacceptable, and what has to recover for that service to run again. Scoped at process level, it asks the same question about a much finer unit of work, one that a board member would rarely recognise as something the organisation either has or does not have.

This is not a matter of taste. FINMA Circular 2023/1 and DORA both define the unit of resilience governance as the business service or critical function, and impact tolerance is set and reported at that level. A process-scoped analysis can be technically complete and still fail to answer the question a regulator or a board actually asks.

Why process level is the tempting choice anyway

Process-level scoping feels closer to how the business actually describes its work. People know their processes; a service definition can look like an abstraction imposed from outside by a risk or resilience function. Building the analysis around processes is also, in the short term, less work: it maps more directly onto existing process documentation and organisational charts.

The cost of that choice arrives later, not immediately. A process-scoped analysis is usable for departmental continuity planning. It becomes a structural barrier the moment the organisation needs to state an impact tolerance the board can own, or needs to demonstrate operational resilience the way a regulator expects, because neither of those is naturally expressed at process granularity. Remapping a mature process-scoped analysis onto services afterwards is expensive enough, in practice, that most organisations that discover the mismatch do not do it and instead run a second, parallel exercise.

What this looks like in practice

The service layer is what the regulator and the board both reason in. Processes do not disappear: they sit beneath the service, mapped as the activities that deliver it, unchanged from how the organisation already understands its own work. The reframing is in what the analysis states an answer for, not in the underlying process knowledge the organisation already holds.

The most common reason organisations avoid starting at service level is an immature asset inventory, on the assumption that a service cannot be properly defined without a complete, system-verified map of what supports it. That assumption is avoidable. Service definitions can be manually maintained at first, by the people who already know how the organisation delivers each service, and synced against a formal inventory progressively as that inventory matures, rather than waiting for the inventory to be complete before scoping the analysis correctly.

Where teams commonly run into difficulty

The recurring failure mode is an analysis that looks complete, with tolerances and recovery objectives recorded, none of which the board would recognise as describing a service it actually cares about. If the analysis cannot produce an impact tolerance for a named service the board would recognise, it is scoped at the wrong level, whatever the process documentation underneath it looks like.

How Bazzi Consulting helps

We scope the business impact analysis at the level your board and your regulator actually need it stated at, and bring existing process-level work forward as input rather than starting again. See risk and resilience advisory.