Business Impact Analysis Dependencies Guide 2026

Business impact analysis dependencies are the people, technology, information, suppliers and facilities that each critical activity relies on to keep running. A business impact analysis that stops at impact ratings and recovery times gives you a list of what matters but not what it would take to restore it. Mapping dependencies is what turns the analysis into something a recovery team can act on.

This guide explains why business impact analysis dependencies matter, what the standard expects, how to collect them, how to record them and how to use the map to find weak points before an incident does.

What ISO 22301 says about business impact analysis dependencies

ISO 22301:2019 sets out the business impact analysis in clause 8.2.2. The organization must identify activities that support the provision of products and services, assess the impacts over time of those activities being disrupted, set prioritized time frames for resuming them, and identify dependencies and supporting resources for those activities, including suppliers, outsourcing partners and other relevant interested parties. In other words, dependencies are a named part of the analysis, not an optional extra. You can see the official listing at ISO 22301:2019 on iso.org. Our guide to the ISO 22301 business impact analysis walks through the whole clause.

Why business impact analysis dependencies change your recovery plan

A recovery time objective of four hours is meaningless if the activity depends on a supplier whose own recovery takes two days. Dependencies expose these mismatches. They also reveal that several activities share the same application, the same small team or the same single supplier, which means one failure can stop many things at once. See our article on RTO and RPO for how recovery targets should be checked against what supports them.

The same map also improves prioritization. Two activities with similar impact ratings can deserve different attention if one has three fragile dependencies and the other has none.

Categories of business impact analysis dependencies

Ask about each category in turn, because people naturally remember systems and forget everything else.

Category	What to capture	Example question
People	Roles, skills, minimum staffing	How many people are needed to run this at a reduced level?
Technology	Applications, infrastructure, networks, devices	Which systems does this activity stop without?
Information	Data sets, records, documents	What data is needed, and where are the copies?
Suppliers	Vendors, outsourcers, utilities	Who provides inputs we cannot replace quickly?
Facilities	Sites, workspace, equipment	Can this be done from anywhere, or only in one place?
Other activities	Upstream and downstream processes	What must happen before and after this step?

How to collect business impact analysis dependencies

Use a structured questionnaire, ideally a short set of questions per activity, followed by a conversation with the process owner. Questionnaires alone tend to produce shallow answers, while interviews alone are hard to compare. Our business impact analysis questionnaire guide shows a format that combines both.

1. Start with the prioritized activities. Do not map everything, only what the impact assessment showed to be time-critical.
2. Ask for the minimum resources to operate. The dependency at the level of a reduced service is often very different from normal operations.
3. Ask for the recovery of each dependency. What is its own recovery time, and who provides it?
4. Verify against records. Compare answers with the application inventory, supplier list, contracts and organization charts.
5. Validate with the owners. Play the map back and confirm it reads correctly.

Watch for hidden and indirect dependencies

The dependencies people forget are usually the ones that hurt. Examples include an identity or single sign-on service that every application needs, a payment provider embedded in a website, a spreadsheet maintained by one person, a shared mailbox, and a telecoms link routed through one exchange. Ask each owner what would stop them if one specific service went down for a day, and follow the answer another step: what does that service depend on?

Recording business impact analysis dependencies

Record dependencies in a structure that can be queried, not only in narrative. A register with one row per activity and columns for each dependency category lets you sort by shared supplier, shared application or shared site. Include owner, contact details, recovery time of the dependency and the source of that figure. Mark the date of the last check, because a dependency map decays quickly as systems and contracts change.

Avoid over-engineering. A well maintained spreadsheet beats an abandoned tool. Add a diagram for the top few activities, since a picture of an activity and its supports is easier to discuss in a workshop than a table.

A worked example of a dependency record

Consider an order processing activity in a distribution company. Its maximum tolerable outage is one working day. The dependency record lists a small team of order handlers and a supervisor, with a minimum of three people needed to run at reduced volume. It lists the order management application, the warehouse system it feeds, the single sign-on service and the internet link at the main site. It lists a payment provider and a carrier booking service as suppliers, and it names the warehouse as the only site with the label printers.

Reading that record against the recovery times shows immediately where the trouble lies. The warehouse system has a recovery target of two days, longer than the activity can tolerate, and the label printers exist only at one site. Neither problem would be visible from the impact ratings alone. The team can now choose between shortening the system recovery, adding a manual process for labels, or agreeing a longer tolerance with the business, and it can record the decision and its owner.

Common mistakes when mapping dependencies

Teams repeat a small number of errors. They map only technology and ignore people and suppliers. They record the normal state rather than the minimum needed to operate. They accept a supplier’s own statement of recovery time without evidence. They fail to record who confirmed each entry and when. And they treat the map as a one-off deliverable for the certification audit instead of a working record that recovery teams will open under pressure. Each of these is easy to avoid if the review dates, owners and evidence columns are built into the register from the start.

Finding single points of failure with the dependency map

Once the register exists, sort and count. Any dependency that appears under many critical activities, or that has no alternative, is a candidate single point of failure. Compare its recovery time with the recovery objectives of the activities it supports. Where it is slower, you have a gap that needs treatment: a second supplier, a manual workaround, a stock of critical items, cross-training or a change to the objective. Our guide to single point of failure analysis covers the method in more depth.

Supplier business impact analysis dependencies

Suppliers deserve a specific step, because their failures are outside your control. For each critical supplier, record what they provide, which activities rely on it, whether an alternative exists and how quickly you could switch. Ask the supplier for its own continuity arrangements and check that contractual notice, service levels and exit terms match what you need. Our article on supplier business continuity assessment explains how to gather that assurance.

Keeping the dependency map current

Set review triggers: new systems, new suppliers, reorganizations, office moves, acquisitions and after every exercise or real incident. An exercise is one of the best ways to test the map, since the team quickly discovers what was missing. Review the whole register at least annually, and assign an owner for each entry so that updates do not depend on one person remembering.

Using a finished structure for your analysis

To avoid building the templates yourself, the Business Impact Analysis Report and Workbook includes a structured report and a working register that captures activities, impacts, recovery times and supporting resources together. If you want to see what a completed record looks like, our business impact analysis example shows a filled-in version. Whichever format you use, the discipline is the same: capture business impact analysis dependencies while the analysis is fresh, and keep them tied to the recovery objectives they support.

Business impact analysis dependencies FAQ

What are business impact analysis dependencies?

They are the people, technology, information, suppliers, facilities and other activities that a critical activity needs in order to operate, recorded as part of the business impact analysis.

Does ISO 22301 require them?

Yes. Clause 8.2.2 requires the organization to identify dependencies and supporting resources for the activities it analyzes, including suppliers, outsourcing partners and other relevant interested parties.

How detailed should the dependency map be?

Detailed enough to plan recovery for the time-critical activities. Map those in depth and treat lower-priority activities at a summary level, then add detail if an exercise or incident shows a gap.

Who provides the dependency information?

The process owners provide most of it, checked against technical inventories, supplier records and contracts. IT and procurement teams usually need to contribute for systems and suppliers.

How often should dependencies be reviewed?

Review them at least annually and whenever systems, suppliers, sites or organization structure change materially. Exercises and incidents should also trigger a review of the affected entries.