Business Impact Analysis: How to Do One That Holds Up

The business impact analysis is the foundation of a business continuity management
system. Everything downstream — strategies, plans, resourcing, exercise scenarios — is
derived from it, so a weak BIA quietly invalidates the rest. This guide covers what clause 8.2
requires, the numbers you must produce, and the mistakes auditors find every time.

What a business impact analysis is for

Clause 8.2 of ISO 22301:2019 requires both a
business impact analysis and a risk assessment. They answer different questions and are routinely
conflated. The BIA asks what happens over time if this activity stops. The risk assessment
asks what could make it stop, and how likely is that. The BIA is impact-over-time analysis
and is deliberately indifferent to cause — which is exactly why it survives contact with
disruptions nobody predicted.

That is the strongest practical argument for doing it properly. A continuity capability designed
around a list of anticipated threats fails when something unlisted happens. One designed around how
long each activity can be down works regardless of the cause.

The numbers a business impact analysis must produce

• Prioritized activities — ISO 22301’s term for the activities that must be
  resumed first. Note it is activities, not departments and not systems.
• Impacts over time, assessed against categories you define: financial, legal and
  regulatory, reputational, contractual, and harm to people. Impact is assessed at intervals, because
  the point is that it grows.
• MTPD — the maximum tolerable period of disruption, the point beyond which
  the consequences become unacceptable.
• RTO — the recovery time objective, the target for resuming the activity.
  It must sit inside the MTPD, with margin. An RTO equal to the MTPD leaves no room for the recovery
  itself to go wrong.
• RPO — the recovery point objective, how much data loss is tolerable, which
  drives backup frequency and replication design.
• MBCO — the minimum acceptable level at which the activity must run during
  disruption. Not full service; the minimum that avoids unacceptable impact.
• Dependencies and resource requirements — people and skills, premises,
  technology, information, suppliers and partners, for each prioritized activity at its RTO.

How to run a business impact analysis in practice

Define impact categories and a consistent scale first, and get them agreed before any interviews.
The most common cause of an unusable BIA is that twelve managers each applied their own idea of
“severe”. Then work through prioritized activities with the people who own them, at a level of
granularity you can actually manage — thirty to eighty activities is workable for most
mid-sized organisations, and three hundred is a project that never finishes.

Then validate upward. Every RTO is a resourcing commitment, and the person who
owns the activity is not usually the person who pays for the recovery capability. Have senior
management confirm the priorities, because clause 8.2 outputs feed the strategy decisions in 8.3 and
those cost money. A business impact analysis signed off only by the continuity manager is the single
most common structural weakness.

ISO publishes ISO/TS 22317:2021 as
dedicated guidance on the BIA process. It is a technical specification rather than a requirements
standard, so nothing in it is auditable, but it is the most detailed source available on doing this
well.

Mistakes auditors find in a business impact analysis

• Everything is critical. If two thirds of activities have a four-hour RTO, no
  prioritisation has occurred and the plans cannot be executed as written.
• RTOs with no resource behind them. A one-hour RTO with no standby capacity is an
  aspiration, and clause 8.3 requires strategies that actually meet the requirements the BIA sets.
• Analysis by department rather than by activity, which hides cross-functional
  dependencies — usually the ones that fail.
• Dependencies stopping at the organisation’s boundary. Suppliers and outsourced
  services are where modern disruption originates.
• A one-off exercise never refreshed. The BIA must be reviewed when the business
  changes, and an eighteen-month-old BIA at a company that reorganised last quarter is worthless.
• No link to exercise scenarios. If exercises never test the shortest RTOs, the
  capability is untested where it matters most.

Where the business impact analysis feeds the rest of the system

The BIA is not a deliverable, it is an input. Its outputs select the continuity strategies under
8.3, size the resources those strategies need, define what the plans in 8.4 must achieve, set the
scenarios worth exercising under 8.5, and give clause 9.1 something measurable to monitor. When
auditors test a business continuity management system, tracing one activity from the BIA through
strategy, plan and exercise is the fastest way to find out whether it is real — which is a good
reason to run that trace yourself first. Our guide to the
business continuity plan covers the next step.

References

• ISO 22301:2019 — the standard itself on iso.org.
• ISO 22313:2020 — guidance on the use of ISO 22301.
• ISO/TS 22317:2021 — guidelines for business impact analysis.
• ISO 22301:2019/Amd 1:2024 — the climate action amendment.

More on ISO 22301 and business continuity

• ISO 22301 certification
• ISO 22301 implementation guide
• ISO 22301 mandatory documents
• business impact analysis — you are here
• business continuity plan
• ISO 22301 internal audit checklist

All of these are covered by the ISO 22301 Toolkit. To score where you stand first, use the ISO 22301 Assessment Tool, or start with the free ISO 22301 templates.