How to perform a Business Impact Analysis and Risk Assessment

A business impact analysis (BIA) under ISO 22301 is used to pinpoint which operations matter most during disruption—and then translate that insight into a risk assessment with clear recovery expectations. The core workflow starts by listing business activities and judging how severe the impact would be if each activity failed, including the maximum tolerable downtime and the recovery time objective (RTO). Criticality is then determined using a priority-for-recovery scale: activities with a priority rating greater than two are treated as “critical” and become the focus of the continuity strategy.

The transcript walks through a practical example: 24/7 Managed IT services. If those services are disrupted, the impact is framed as serious—core service provision would be interrupted, breach of SLA penalties could be triggered, and clients could be lost. The maximum tolerable period of disruption is set to 1 hour, while the RTO is 30 minutes, meaning restoration to an acceptable client-facing level (not necessarily full peak performance) is the target. Recovery priority is rated on a 1-to-5 scale, with a score of five indicating the highest urgency. This activity is also checked for dependencies—external suppliers whose failure could undermine recovery. The example names fictitious dependencies such as Hardware Support Services Limited (for hardware failure) and Telecom Services Limited (for network failure), with guidance to avoid single-supplier dependency by having multiple suppliers for critical activities.

Dependencies aren’t just listed; they must be managed. The approach is to put business continuity management arrangements in place with suppliers, typically by requiring them to provide their own business continuity plans for review before onboarding. The BIA also specifies how recovery would happen: in the example, switching to a mirrored data center in Scotland if issues can’t be resolved within the 30-minute RTO. Stakeholder management is addressed too, including who would coordinate decisions during disruption—either the CEO or the COO, depending on the scenario. Finally, the BIA identifies the resources needed to resume operations within the RTO, such as the Chief Technical Officer and relevant technical staff working with the named suppliers.

Once critical activities are defined, the process moves to risk assessment. For each critical activity, the organization identifies plausible incidents that could disrupt it—examples given include severe weather and epidemic influenza. Likelihood is assessed using estimates based on experience. Each risk is then assigned a risk response category: tolerated (accepted with no additional action beyond acknowledgment), treated (mitigated through specific actions), transferred (handled via third parties such as outsourcing or insurance), or terminated (ending the activity when risk is too high). The final step is to document the proposed risk treatment for every identified risk, ensuring continuity planning is tied directly to measurable recovery needs and realistic threat scenarios.

Overall, the method links business impact to operational recovery targets and then to risk treatment decisions, so continuity strategy isn’t built on assumptions—it’s built on prioritized activities, dependencies, and defined tolerances for disruption that drive concrete mitigation choices.