ISO 22301 Business Impact Analysis Template

Start with a stable activity inventory. Each BIA row should name the product or service supported, the activity being analyzed, the accountable business owner, the location or delivery model, the systems and data used, and the customer, legal, safety, financial, operational, and reputational impacts that could follow a disruption.

ISO 22301 expects the business impact analysis process to determine business continuity priorities and requirements. That means the template should not stop at a description of the process. It should produce enough information to decide which activities are prioritized and what is needed to continue or recover them.

For each activity, capture how impacts change as disruption duration increases. A single severity score is usually too weak for continuity planning because the same activity can be tolerable for hours, damaging after a day, and unacceptable after several days.

Use time bands that fit the organization, then record the impact at each band and the evidence behind it. The important output is the point where impact becomes unacceptable and the earlier point where recovery must begin to meet minimum acceptable capacity.

The BIA should make dependencies visible enough for continuity strategies to be selected. Ask each process owner what the activity needs at minimum acceptable capacity, then separate internal dependencies from third-party and infrastructure dependencies.

The result should be a resource profile for each prioritized activity. That profile is what continuity planners use to decide whether the organization needs alternate sites, manual workarounds, supplier arrangements, technology recovery, staffing cover, communications procedures, or other solutions.

The template should end with strategy inputs, not only impact analysis. For each prioritized activity, capture the recovery target, minimum capacity, dependencies, resource gaps, and decision owner so the continuity strategy can be selected and implemented.

A clean handoff also helps audit readiness. Auditors and customers can see why an activity was prioritized, what evidence supports the recovery target, which continuity solution was selected, and whether the selected solution was later exercised or tested.

The most common failure is treating the BIA as a survey instead of a decision record. If the template does not produce prioritized activities, recovery time frames, required resources, dependencies, evidence, and open gaps, it will be hard to use for strategy selection or audit review.

Another failure is copying generic recovery targets across activities. Recovery expectations should be justified by impact over time and dependency evidence, not inherited from an old plan or chosen because they sound conservative.

Set both a planned review cadence and change triggers. Planned review keeps the BCMS current; trigger-based review catches material changes such as new products, new suppliers, major system changes, acquisitions, site moves, changed customer commitments, exercises that fail assumptions, or incidents that reveal a recovery gap.

The review output should be practical: updated BIA rows, changed continuity strategies, updated plans, corrective actions, risk acceptance, management-review input, or supplier follow-up.