Business Impact Analysis: A Complete Guide for UK SMEs

Ask most business owners which of their activities they would recover first after a serious disruption, and you get a confident answer. Ask them how they know, and the confidence usually fades. A business impact analysis is how you replace that gut feel with something you can defend, plan around and act on when it matters. It is the single most valuable piece of business continuity work an SME can do, and it is the part most guides rush.

This is a complete, practical guide to the business impact analysis (BIA) for UK SMEs. It goes well beyond the summary in our main Business Continuity Plan guide: here we work through the whole method, from listing your services to approving the results and turning them into a plan. There is a free BIA workbook that puts all of this into a structured spreadsheet you can complete for your own business.

What a business impact analysis actually is

A business impact analysis is a structured way of answering two questions for every important thing your business does: how badly would it hurt if this stopped, and how quickly does that hurt grow? From those answers you derive which activities to recover first, how fast, and what they depend on. The internationally recognised business continuity standard ISO 22301 treats the BIA as the foundation of the whole management system, and for good reason: everything downstream, your recovery objectives, your continuity strategies, your plan, is only as sound as the analysis underneath it.

The most common failure is to treat the BIA as an IT asset list. It is not. A BIA is about business activities and outcomes, and the resources they consume are only relevant because they support those outcomes. “We have twelve servers” is inventory. “We must be able to invoice within two days of month-end or we breach a covenant” is a business impact analysis finding. The first tells you what you own; the second tells you what to protect and how urgently.

Why a BIA is not a risk assessment

These two are constantly confused, and keeping them apart makes both far more useful. A BIA asks what happens if an activity becomes unavailable, regardless of the cause. A risk assessment asks what could make it unavailable, and how likely and controllable that is. The BIA does not care whether the cause is a flood, a cyber attack or a burst pipe; it cares about the consequence of the activity stopping. You do the BIA first, because it tells you which activities are important enough to be worth assessing risks and building defences for. Spending your risk-assessment effort on an activity the business could lose for a fortnight without noticing is effort wasted.

Step one: list your business activities and services

Start at the top, with what your business delivers to its customers, then break each service into the activities that produce it. Keep the language in business terms. A professional firm might list “responding to client instructions”, “producing and issuing work”, “billing and collecting payment”, “paying staff and suppliers”. A distributor might list “taking orders”, “picking and packing”, “dispatch”, “restocking”, “customer support”. Aim for a manageable number of genuinely distinct activities, not a hundred micro-tasks.

For each activity, record the basics that frame everything else: who owns it, who the customers and stakeholders are, its normal operating hours, and its busy or critical periods. Timing matters more than people expect. A payroll run is trivially interruptible for three weeks of the month and business-critical for the two days around payday. A BIA that ignores timing produces recovery targets that are either needlessly expensive or dangerously slack.

Customers, contracts and commitments

Before you score the pain, capture what you are actually on the hook for. For each important activity, note the customer expectations, contractual commitments, service levels, and any deadlines that carry a penalty or a lost-order consequence. These are the hard edges that turn a vague “customers would be annoyed” into a concrete “we have a contractual four-hour response commitment with two clients”. Contractual obligations frequently set tighter recovery targets than the business would otherwise choose, so they belong in the analysis, not in a separate legal folder nobody reads during a disruption.

The consequences you need to assess

Impact is not one thing, and scoring it as a single “how bad” number hides the detail that drives good decisions. Assess each important activity across several distinct consequence types. A given outage might be mild financially but severe reputationally, or trivial operationally but serious for safety. Looking at each separately is what stops a BIA collapsing into hand-waving.

You do not need a scientific model. A simple Low, Medium, High, Critical rating per consequence type, with a sentence of justification, is more useful than a false-precision weighted score that nobody can explain. The point is to understand why an activity is a priority, not to generate a number.

Impact grows over time, so measure it over time

This is the idea that turns a BIA from a static list into a planning tool. The impact of losing an activity is not a fixed value; it is a curve that rises the longer the outage lasts. Ten minutes without your order system is an irritation. Half a day is a problem. Three days is a business event with lasting customer damage. So instead of asking “how bad is it”, ask “how bad is it after one hour, after four hours, after a day, after a week”.

Score the impact across a set of time bands. A workable default, which you should adapt to your business, is: under 1 hour, 1 to 4 hours, 4 to 8 hours, 8 to 24 hours, 1 to 3 days, 3 to 7 days, 1 to 2 weeks, and more than 2 weeks. A bakery cares about hours; a project-based consultancy might think in days. The band where impact tips from tolerable to serious is the maximum tolerable period of disruption for that activity, the point beyond which the damage may become irreversible. Terminology varies between frameworks, so do not chase false precision; the value is in identifying roughly where the cliff edge is, so your recovery target can sit comfortably before it.

From impact to recovery priorities

Once you know how quickly impact grows for each activity, a recovery order falls out almost automatically. Activities whose impact becomes serious within hours are your top priority; those you could lose for days without lasting harm sit lower. The discipline here is honesty: everything cannot be priority one. If your BIA marks every activity as critical, it has failed, because your team will freeze trying to recover everything at once. A useful model, adaptable to your business, runs from a top band of safety and emergency obligations, through services needed within hours, within a business day, tolerable for several days, and finally those that can wait until core operations are back. The recovery target you set for each activity, its recovery time objective, comes straight from where its impact crosses the line. We cover setting those targets properly in our companion guide, RTO vs RPO explained.

Capture the dependencies while you are there

A recovery target is meaningless unless you know what the activity depends on, so the BIA is the natural place to capture dependencies. For each priority activity, note what it relies on across people, premises, technology, communications, data, suppliers, utilities and equipment. Look especially for single points of failure, the one person, supplier, system or line whose loss stops the activity with no alternative, and for the indirect dependencies that catch businesses out. “Our finance system is in the cloud” hides a chain of internet, identity, multi-factor authentication, the user’s device, power and a bank portal, any of which can take the “resilient” cloud service offline. The dependency work you do in the BIA becomes the raw material for your continuity strategies.

Minimum viable operations and workarounds

For each priority activity, the BIA should also ask: what is the smallest, safe level at which we could keep this going while we recover? This minimum viable operation, a term the NCSC uses in its recovery guidance, is what you aim for first in a real disruption, before full service. Alongside it, note any manual workaround, and be honest about its limits: how much volume it can handle, and, crucially, how you would reconcile the work once systems return without creating duplicates, missed orders or double invoices. A workaround with no reconciliation plan is a problem deferred, not solved.

Gathering the information: talk to the people who do the work

A BIA written at a desk by one person is a guess in a spreadsheet. The people who actually run each activity know things the org chart does not: the informal workaround, the one supplier nobody documented, the report that only one person can produce. Interview them. A short, structured conversation with each process owner is worth more than any template.

• Ask what they actually do, in order, on a normal day, and what they need to do it.
• Ask what breaks it. “What has stopped you working in the past, even for an hour?” surfaces real dependencies fast.
• Ask about timing. When in the week, month or year would an outage hurt most?
• Ask who else is affected upstream and downstream, to find the knock-on dependencies.
• Ask what they would do if the usual system were unavailable. Their answer is your workaround, or the evidence that there isn’t one.

Review, challenge and approve the results

A BIA is a set of business judgements, so it needs business sign-off. Pull the findings together, look across the whole organisation rather than one area at a time, and challenge the outliers: is that activity really critical within an hour, or does it just feel that way to its owner? Does the recovery order make sense when you read it end to end? Then have it approved by someone with the authority to commit to the priorities and, later, to the spending they imply. Recording who approved the BIA and when matters, because these priorities will drive real decisions during a disruption, and you want them owned, not improvised.

Turning BIA findings into a continuity plan

The BIA is not the destination; it is the foundation the plan is built on. Its findings feed directly into the continuity plan: the priority activities become your recovery sequence, the time bands become your recovery time objectives, the dependencies drive your continuity strategies, and the minimum viable operations shape your first response. Work the BIA through the full method in our Business Continuity Plan guide, and keep the BIA itself as a living document, reviewed whenever the business changes materially, so the plan never drifts away from reality.

Worked example: a fictional 25-person firm

To show that a BIA is about the whole business and not just IT, here is a short, clearly fictional example for a 25-person UK architecture practice. Its main services are responding to client instructions, producing and issuing drawings and reports, and billing. Running a BIA across people, premises, suppliers, communications, technology and information produces a picture no IT asset list would give:

The BIA’s conclusion for this fictional practice is not “protect the servers”. It is: identity and client communication are the most time-critical, issuing is constrained by a two-person bottleneck, the cloud design platform is the dominant single point of failure, and current project data needs a much tighter recovery point than the archive. A distributor or a manufacturer running the same method would reach an entirely different set of priorities. That is the point: the BIA finds your priorities, not a generic list.

Frequently asked questions

Related reading: the full Business Continuity Plan guide, RTO vs RPO explained, the free Business Continuity & BIA Toolkit, and the Downtime Cost Calculator. If a cyber attack is what causes a disruption, our Incident Response Toolkit handles containing the threat while continuity keeps the business running.