A business impact analysis is the exercise that establishes which of your activities matter most, what would happen if each one stopped, and how quickly it has to be back. It produces the recovery priorities and timeframes that every continuity and recovery plan is then built to meet. Done properly it is the most useful piece of work in continuity planning, because everything downstream inherits its judgements. Done badly it quietly misdirects the entire programme.
- Activities ranked by the harm caused if they stop, not by how important the department feels.
- A recovery timeframe for each one, derived from when the harm becomes unacceptable.
- The dependencies each activity relies on, including the ones nobody had written down.
- The minimum level of service that would do at first, rather than assuming full capacity.
- Sign off from the people accountable for the consequences, so the priorities hold under pressure.
What is a business impact analysis?
A business impact analysis, usually shortened to BIA, is a structured assessment of the consequences of interruption. You take each activity the organisation performs, ask what would happen if it stopped, and track how that harm grows over time. The output is not a document for its own sake. It is a ranked list of activities with a recovery timeframe attached to each, which is the input every other continuity decision depends on.
The distinction that matters is between risk assessment and impact analysis. A risk assessment asks what might happen and how likely it is. A BIA does not care about likelihood. It assumes the interruption has occurred and asks how much it hurts and how fast. That is why the two are complementary and why substituting one for the other leaves a gap: you end up either protecting against causes you can name while ignoring the consequences, or the reverse.
The BIA sits at the analysis stage of the wider cycle set out under business continuity, and the priorities it produces feed the plans described there.
What does a business impact analysis produce?
Four outputs, and a plan that is missing any of them is working from assumption rather than analysis. The recovery metrics are the part people struggle with, because they look like technical parameters and are actually business judgements.
| Output | What it means | How it is decided |
|---|---|---|
| MTPD | Maximum tolerable period of disruption. The point at which the harm from losing an activity becomes unacceptable to the organisation. | A business judgement about consequences, made by the people accountable for them. |
| RTO | Recovery time objective. The target for having the activity working again, set inside the MTPD so there is margin. | Derived from the MTPD, never set independently of it. |
| RPO | Recovery point objective. How much recent data you can afford to lose, expressed as a period of time. | Determined by how much rework or reconstruction the business can absorb. |
| MBCO | Minimum business continuity objective. The reduced level of service that is good enough while you recover. | Agreed with the activity owner, who usually finds it is lower than assumed. |
The relationship between MTPD and RTO is where most analyses go wrong. If the recovery time objective equals the maximum tolerable period, any delay at all breaches it. The RTO should sit comfortably inside the MTPD, and the gap between them is the margin you are buying.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
How do you run a business impact analysis?
The sequence below is deliberately front-loaded. Getting the scope and the activity list right takes longer than people expect and makes the rest straightforward.
- Agree the scope: which parts of the organisation, which locations and which timeframe. An analysis that quietly expands never finishes.
- List the activities: describe what the business does in terms someone outside the department would recognise. Departments are not activities, and neither are systems.
- Trace the dependencies: for each activity, the people, systems, data, suppliers, premises and equipment it needs. This is where undocumented reliance surfaces.
- Assess the impact over time: ask what happens after an hour, a day, a week. Impact is rarely linear, and the shape of the curve is what sets the timeframe.
- Set the timeframes: derive the MTPD from where the harm becomes unacceptable, then set an RTO inside it, an RPO from tolerable data loss and an MBCO for reduced running.
- Get it approved: the priorities need formal ownership. Without it the analysis becomes a document that everyone can quietly disagree with later.
Interview rather than circulate a form. A form gets you the answer the respondent thinks you want, and every activity comes back as critical. A conversation lets you ask what the customer would actually notice and when, which produces a defensible ranking.
The outputs then have to be inherited rather than re-invented. The recovery timeframes set here are what a contingency plan commits to for a specific named risk, and what a disaster recovery plan has to hit when restoring the systems behind the activity. A plan that sets its own timeframes independently of the analysis is protecting something at a speed nobody agreed.
Where do business impact analyses go wrong?
The failures are consistent and they are mostly about how the analysis was gathered rather than how it was documented.
- Everything comes back critical: with no forced ranking, every owner rates their own activity highest and the output cannot prioritise anything.
- Recovery targets set by IT capability: timeframes derived from what the current infrastructure can deliver rather than from the harm, which produces targets that are always met and never meaningful.
- Departments treated as activities: analysing finance rather than paying suppliers and collecting cash hides the fact that the two have very different urgencies.
- Dependencies stopping at the system boundary: naming the application but not the supplier hosting it, the data feed it needs or the one person who knows how to restart it.
- Impact assessed at a single point in time: asking what happens if this stops, rather than what happens after an hour, a day and a week.
- Never revisited: an analysis from three years ago describes an organisation that has since changed its systems, suppliers and structure.
A useful test of whether the analysis is real: ask what got ranked lowest. If nobody can answer, the exercise did not prioritise, and every plan built on it will compete for the same resources at the same moment.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
How does the analysis connect to resilience?
A business impact analysis tells you what to protect and how fast. It does not tell you how to protect it, and it says nothing about whether the controls underneath are working. That is the connection to resilience: the same activities the analysis prioritises depend on access management, backup, supplier assurance and incident response, and those controls are what make a recovery timeframe achievable rather than aspirational.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system. The dependency mapping done for a BIA is the same mapping those standards ask for, so the work counts more than once. Continuity itself is specified and certifiable under ISO 22301, which requires a business impact analysis and defines what it has to establish. The wider structure is set out in the business resilience framework.
How do you keep a business impact analysis current?
A BIA decays faster than most continuity artefacts because it is tied to how the organisation is arranged, and that changes constantly. A new supplier, a migrated system, a restructure or an acquisition can all invalidate a dependency map without anyone noticing, and the analysis will still look complete.
Reviewing annually catches some of it. Tying the review to change instead catches more: when a system is replaced, when a supplier is onboarded, when an activity moves between teams. The version that stays current is the one connected to the asset and supplier records rather than living in a separate spreadsheet. That approach is set out in how to evidence resilience, and the Resilience Score gives you a baseline to start from.
Why choose ISMS.online for business impact analysis?
The value of a BIA is in whether the plans built on it still match the organisation. ISMS.online keeps the two connected.
- Activities linked to what they depend on: connect each activity to the assets, suppliers and controls behind it, so a change in one is visible in the other.
- Recovery targets held with the plans: MTPD, RTO, RPO and MBCO recorded against the activity and inherited by the plans that have to meet them.
- One control set, every framework: the dependency work is mapped once and reused across ISO 22301, ISO 27001, ISO 27701 and ISO 42001.
- Review that actually happens: owners, review dates and reminders, so the analysis is revisited when things change rather than annually at best.
- Evidence on demand: show an auditor a current analysis with its approval trail instead of reconstructing one.
- Informed by deep expertise: guided implementation from specialists who have run these exercises in regulated organisations.
- Built for UK and regulated markets: designed for organisations that have to prove resilience to win and keep contracts.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is the difference between a business impact analysis and a risk assessment?
A risk assessment asks what could go wrong and how likely it is. A business impact analysis assumes something has already gone wrong and asks how badly it hurts and how quickly the activity has to be back. You need both, because a risk assessment alone tells you nothing about recovery priorities, and a BIA alone tells you nothing about which causes to guard against.
What is the difference between MTPD and RTO?
The maximum tolerable period of disruption is the point at which the harm becomes unacceptable to the business. The recovery time objective is the target you set for being operational again, and it should sit inside the MTPD rather than equal to it. If the two are the same figure, any slippage at all means the tolerable limit has been breached, so the gap between them is the safety margin.
Who should be involved in a business impact analysis?
The people who run the activities, because they know the dependencies, and the people accountable for the consequences, because they own the judgement about what is tolerable. Technical teams contribute what is achievable but should not set the timeframes. Someone independent should facilitate, since activity owners naturally rate their own work as critical and a forced ranking needs a neutral hand.
How long does a business impact analysis take?
For a mid-sized organisation with a clear scope, a few weeks of elapsed time, most of it spent interviewing activity owners rather than writing. The variable is scope discipline. Analyses that expand to cover every activity in every location take months and are usually out of date before they are approved, which is why a narrower first pass over the genuinely critical activities is more useful than a comprehensive one.
Is a business impact analysis required by ISO 22301?
Yes. ISO 22301 requires the organisation to carry out a business impact analysis and sets out what it has to establish, including the activities that support the products and services, the impacts of disruption over time, and the prioritised timeframes for resuming them. Working to the standard also means the analysis has to be reviewed rather than performed once.
