Business Impact Analysis for Services

Business impact analysis asks a grounded question: if this service stops, who is harmed, how, and how quickly does that harm become serious. It looks beyond lost transactions to customers unable to access money, obligations that cannot be met, records that become uncertain, and vulnerable customers who have fewer alternatives. The analysis then identifies which steps of the service matter most, which dependencies support them, and where continuity effort should go earliest. Under DORA in the EU, which applies from 17 January 2025, and under the separate UK regime in FCA PS21/3 and PRA PS6/21, the surrounding duties differ, so the analysis should label which regime it supports and avoid presenting one regime as if it were the other.

A useful analysis begins with the customer, not with the system diagram. It describes the service as customers experience it, then traces each step to the people, systems, data and suppliers that make it possible. Interviews with service staff, frontline teams and suppliers often reveal dependencies that diagrams miss, such as a manual check, a shared mailbox, a specialist who alone knows a process, or a data feed that arrives through an informal route. Those hidden dependencies matter because they are the points where disruption spreads in unexpected ways. An analysis built only from architecture documents can look tidy while missing the step that actually stops the service.

Consider an illustrative mortgage servicing service. Customers may need to make payments, ask about arrears, or receive accurate balances. A disruption that blocks online access is inconvenient, but a disruption that leaves balances uncertain or prevents vulnerable customers from contacting the firm carries a different kind of harm. The analysis should therefore distinguish inconvenience from harm, and harm that grows over time from harm that is immediate. It should also consider timing and context: a disruption during a payment peak, a market stress period, or a period when alternative channels are also under strain may affect customers differently from the same disruption at a quiet time. Those distinctions help planners prioritise recovery in a way that reflects customer experience rather than technical convenience.

Impact analysis also shapes tolerance. Tolerance is not chosen in isolation; it emerges from understanding what disruption does to customers and to the firm, and from deciding what level of harm is intolerable. If the analysis shows that customers quickly lose access to essential funds, tolerance should reflect that urgency. If it shows that a service can be paused safely while customers are given clear information and an alternative route, the recovery sequence can reflect that too. The analysis should record its reasoning, including uncertainties and disagreements, so that a later reviewer can see why a service was prioritised in a particular way. A tolerance without that reasoning looks arbitrary and is hard to defend when disruption tests it.

Good analysis avoids two common distortions. The first is scoring every impact with neat ratings that hide judgement behind numbers, giving a false sense of precision. Qualitative descriptions, supported by examples and by evidence from past incidents, often convey harm more honestly. The second distortion is treating all services as if they matter equally. A firm has limited recovery capacity, and impact analysis exists to make difficult choices explicit: this service step returns earliest because its harm grows fastest, while another step waits because customers can use an alternative or because the harm is contained. Those choices should be owned, challenged and revisited, not buried in a spreadsheet that nobody reads after it is produced.

Analysis should stay alive. Services change, customer groups change, suppliers change, and data flows change, often without a formal project to announce the change. A useful discipline is to revisit the analysis whenever a service, dependency or customer route changes materially, and after every test or incident that reveals an impact the analysis missed. The update should focus on what changed in harm, dependency or priority, rather than rewriting the whole document for its own sake. Over time, that discipline builds a record of judgement that continuity planners, service owners and reviewers can trust. Without it, a plan may recover the service as it was described long ago, not the service customers use today.