Business Impact Analysis (BIA) Template: ISO 22301

Most recovery plans fail because their recovery targets were never derived from the business: IT guessed how fast systems should come back, and nobody checked what the organisation could actually tolerate. A business impact analysis (BIA) fixes that by measuring how the impact of a disruption grows over time for each activity, and turning that into agreed recovery objectives and priorities. This template gives you a BIA method and worksheet aligned with ISO 22301:2019 clause 8.2.2, ISO/TS 22317:2021 and NIST SP 800-34 Rev. 1, with cyber scenarios and identity dependencies built in. It is for business continuity, risk and IT leads who need recovery targets the business has signed.

How to use this template

Replace text in square brackets, such as [Organisation], [BC manager] and [4 hours], with your own terms and values.
"Must" is mandatory for every BIA; "should" is recommended and may be skipped with a recorded reason.
Copy the tables in sections 6 to 9 and 11 into a spreadsheet or your BCM tool and complete one set per process or activity. Section 5 scales are set once for the whole organisation.
Interview the people who run each process, not only system owners. NCSC's guidance on recovering from cyber attacks is direct: "The needs of the business must drive prioritisation for recovery, not solely IT considerations."
ISO/TS 22317 "does not prescribe a uniform process for performing a BIA", and the BCI Good Practice Guidelines note that organisations "do not have to undertake all four BIA types". Start at product and service level, then go to process and activity level only where the numbers justify it.
Feed the results into your continuity strategies and plans. See the Business Continuity and Disaster Recovery Guide.

1. Purpose

This document sets out how [Organisation] analyses the impact of disruption to its products, services and supporting activities. It establishes the impact over time of not delivering each activity, the maximum tolerable period of disruption (MTPD), recovery time and recovery point objectives (RTO and RPO), minimum acceptable service levels, and the people, sites, technology, data and suppliers each activity depends on. The results set recovery priorities and the requirements that [Organisation]'s business continuity, disaster recovery and cyber incident plans must meet.

2. Scope

This BIA covers:

The products and services listed in [service catalogue or register of important business services], and the processes and activities that deliver them.
Business units: [list], sites: [list], and the supporting functions they rely on.
Disruption from any cause, including loss of a site, loss of staff, loss of IT or data, supplier failure and cyber attack (including ransomware, destructive attacks and compromise of the identity provider).

Exclusions: [list any excluded entities or services and the reason]. The BIA is repeated every [12 months] and after any significant change to [Organisation], as ISO 22301:2019 requires review at planned intervals or when significant change occurs.

3. Roles and responsibilities

[Executive sponsor]: approves the impact scales, risk appetite and final recovery objectives.
[BC manager]: owns this template, runs the BIA cycle, consolidates results and reports gaps.
Process owners: complete sections 6 to 10 for their processes, provide evidence and sign off the results.
[CIO or IT service owners]: confirm achievable RTO and RPO for applications and infrastructure and report gaps.
[CISO]: provides cyber scenarios and confirms identity, security tooling and recovery-environment dependencies.
[Procurement and third-party risk]: confirms supplier recovery commitments and contract terms.
[Internal audit or second line risk]: challenges ratings and checks consistency across business units.

4. Definitions

Prioritised activity: an activity to which priority is given following a disruption in order to limit impact.
Maximum tolerable period of disruption (MTPD): in ISO 22301:2019 wording, "the time frame within which the impacts of not resuming activities would become unacceptable to the organization". NIST SP 800-34 calls the equivalent maximum tolerable downtime (MTD).
Recovery time objective (RTO): the time, set within the MTPD, by which a disrupted activity or resource must be resumed at a specified minimum capacity. NIST notes that "the RTO must normally be shorter than the MTD".
Recovery point objective (RPO): in the BCI's words, "the point to which information used by an activity must be restored to enable the activity to operate on resumption". NIST adds: "Unlike RTO, RPO is not considered as part of MTD."
Minimum business continuity objective (MBCO): "the minimum level of services and/or products that is acceptable to the organization to achieve its business objectives during a disruption" (BCI). ISO 22301:2019 no longer defines the term, but it remains useful for stating the capacity behind an RTO. NCSC uses minimum viable operations for "the lowest level of operational capability at which the organisation can continue to operate safely".
Impact tolerance: for UK financial services firms, the FCA's "maximum tolerable disruption" to an important business service. Where it applies, record it alongside the MTPD.

5. Impact categories and rating scale

ISO 22301:2019 requires [Organisation] to define the impact types and criteria relevant to its context before assessing impacts. NIST SP 800-34 advises expressing impacts in "values or units of measurement that are meaningful to the organization". Set the thresholds below once, approve them with [Executive sponsor], and align them with the enterprise risk matrix.

Category	1 Minimal	2 Minor	3 Moderate	4 Major	5 Severe
Financial (lost revenue, extra cost, penalties)	< [£10k]	[£10k to £100k]	[£100k to £1m]	[£1m to £10m]	> [£10m]
Customer and service	No noticeable effect	Some customers delayed	Many customers unable to transact	Vulnerable customers harmed or service unavailable	Widespread harm, customers leave
Legal and regulatory	None	Internal breach of policy	Reportable incident	Regulatory investigation or impact tolerance breached	Enforcement, licence at risk
Health, safety and welfare	None	Minor discomfort	Minor injury	Serious injury	Loss of life
Reputation	Internal only	Local or social media mentions	National media for [1 day]	Sustained national coverage	Lasting loss of trust
Operational and contractual	Absorbed by staff	Backlog cleared in [1 day]	SLA breaches	Key contracts breached	Contracts terminated
Data and confidentiality	None	Internal data affected	Personal data affected, low risk	Notifiable personal data breach	Large-scale breach of sensitive data

The overall rating at each time point is the highest category score, not the average. A rating of [4] or above in any category means the impact is unacceptable.

6. Process inventory

List every product, service and process in scope, then the activities that support those rated as critical. One row per process:

Field	Entry
Process ID and name	[BIA-FIN-03 Supplier payments]
Product or service supported	[Pay suppliers on time]
Process owner and deputy	[Name, role]; [Name, role]
Description and outputs	[What the process does and who receives the output]
Peak periods and deadlines	[Month end, payroll date, regulatory filing dates]
Normal volume and staff	[Transactions per day; FTE]
Manual workaround available	[Yes or no; how long it can be sustained; how data will be re-entered]
Upstream and downstream processes	[Process IDs]

7. Time-based impact assessment

For each process, rate each impact category at each interval, assuming the disruption starts at the worst realistic time (record which). Record the reason for ratings of [3] or above.

Category	[1 hour]	[4 hours]	[1 day]	[3 days]	[1 week]	[2 weeks]	[1 month]
Financial	[1]	[1]	[2]	[3]	[4]	[4]	[5]
Customer and service	[1]	[2]	[3]	[4]	[4]	[5]	[5]
Legal and regulatory	[1]	[1]	[2]	[3]	[4]	[4]	[5]
Health, safety and welfare	[1]	[1]	[1]	[1]	[2]	[2]	[2]
Reputation	[1]	[1]	[2]	[3]	[4]	[4]	[5]
Operational and contractual	[1]	[2]	[3]	[3]	[4]	[5]	[5]
Highest rating	[1]	[2]	[3]	[4]	[4]	[5]	[5]

Also estimate the cost of disruption per day at [1 day] and [1 week], showing the method (lost margin, overtime, penalties, customer compensation). NIST SP 800-34 frames the recovery decision as "balancing the cost of system inoperability against the cost of resources required for restoring the system"; this figure is the first half of that balance.

8. Recovery objectives

The MTPD must be set at the earliest interval in section 7 where the highest rating reaches [4]. In the example above, that is [3 days].
The RTO must be shorter than the MTPD, leaving time for detection, decision to invoke, validation of restored data and backlog recovery. [Organisation] uses a default margin of [50]% unless the process owner justifies otherwise.
The MBCO must state the capacity required at the RTO, for example [60% of normal payment volume, priority suppliers only].
The RPO must be set per data set from how much lost data can be re-created, and from where (paper records, partner files, payment provider reports).
Where a cyber attack could make backups or the identity system untrustworthy, the process owner should also record the tolerable time to operate on manual workarounds.

Process	MTPD	RTO	MBCO at RTO	RPO (per data set)	Impact tolerance (if regulated)
[BIA-FIN-03 Supplier payments]	[3 days]	[1 day]	[Priority suppliers and payroll]	[Payment files: 0; ledger: 4 hours]	[n/a]
[Process]	[ ]	[ ]	[ ]	[ ]	[ ]

9. Dependencies and resources

NIST SP 800-34 lists the resources to evaluate as "facilities, personnel, equipment, software, data files, system components, and vital records". Record each dependency with the time by which it is needed, which becomes its own recovery requirement.

Dependency type	What to record	Needed by	Single point of failure?
People and skills	Minimum staff, named key individuals, deputies, skills that only one person holds	[ ]	[ ]
Sites and equipment	Primary and alternate sites, specialist equipment, printers, phones	[ ]	[ ]
Applications and data	Application names, data sets, RPO, owning team, hosting (on-premises, cloud, SaaS)	[ ]	[ ]
Identity provider and access	IdP and directory, MFA service, privileged access tool, break-glass accounts, service accounts, API keys and certificates the process or its systems use	[ ]	[ ]
Infrastructure	Network, DNS, email, collaboration tools, endpoint management, backup platform	[ ]	[ ]
Third parties	Suppliers, outsourcers, cloud and SaaS providers, payment and telecoms providers; their stated recovery times and contract terms	[ ]	[ ]
Vital records	Contracts, authorisation lists, contact lists, paper forms needed for manual working	[ ]	[ ]

Identity deserves its own question in every interview: "if no one could sign in to any system, what could this process still do, and for how long?" In a cyber attack the directory may itself be compromised; NCSC advises that without a trusted identity source organisations must "agree how staff will be identified". See the Identity Provider and SSO Security Guide and the Break-Glass Account Guide. Supplier answers should be checked against contracts; see the Third-Party Access Guide.

10. Recovery priorities and gaps

[BC manager] must rank processes by RTO, then by highest impact rating at the RTO, to produce the recovery priority list.
Each application and infrastructure component inherits the shortest RTO and RPO of any prioritised process that depends on it.
[CIO or IT service owners] must state the currently achievable recovery time and data loss for each component, based on the last test, not design documents.
Any component whose achievable recovery is worse than its inherited RTO or RPO is a gap. Each gap must be recorded in [risk register] with an owner, a remediation option and cost, or a formal risk acceptance by [Executive sponsor].

11. Approval and sign-off

Role	Name	Confirms	Date
Process owner	[ ]	Inventory, impact ratings, MTPD, MBCO and dependencies are accurate	[ ]
[CIO or IT service owner]	[ ]	Achievable RTO and RPO and gaps are stated correctly	[ ]
[CISO]	[ ]	Cyber scenarios and identity dependencies are covered	[ ]
[BC manager]	[ ]	BIA follows this method and is consistent with other units	[ ]
[Executive sponsor]	[ ]	Recovery objectives and residual gaps are approved or accepted	[ ]

12. Review

This template and each completed BIA are reviewed at least every [12 months], and after a significant change to products, processes, sites, systems, suppliers or regulation, after any invocation of a continuity plan, and after exercises that show an objective cannot be met. Completed BIAs must be stored where they can be read during an outage; NCSC's Cyber Assessment Framework expects response plans to be "readily accessible, even when your organisations IT systems have been adversely affected by an incident".

13. Source references

Implementation guidance

Set the scales first: agree section 5 thresholds with the executive sponsor and finance before any interview, or ratings will not be comparable across units.
Pilot on two processes: pick one business process and one support function (for example payments and payroll), run the full template, and adjust intervals and questions before rolling out.
Interview, then validate: run workshops with each process owner, then check ratings against incident history and finance data.
Consolidate and challenge: compare MTPDs across units; similar processes with very different MTPDs usually mean the scale was applied inconsistently.
Test the IT numbers: confirm achievable RTO and RPO with restore tests, not vendor claims. See the Backup Security and Immutable Backup Guide.
Add the cyber lens: rerun the dependency questions for a ransomware or identity compromise scenario, where backups, the IdP and management consoles may all be untrusted. See the Ransomware Response and Recovery Guide.
Close the loop: turn gaps into funded remediation or signed risk acceptance, and use the downtime cost figures in cyber risk models. See the Cyber Risk Quantification Guide.

Small organisations can complete the template at service level only, in a single workshop with the leadership team, and keep one table per service. Large or regulated organisations should hold BIAs in a BCM or GRC tool, linked to the CMDB so application RTOs update automatically. Track four measures: the share of in-scope processes with a signed BIA less than [12 months] old, the number of open RTO and RPO gaps, the share of prioritised applications whose recovery has been tested against their RTO, and the time from a significant change to an updated BIA.

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Business Continuity and Disaster Recovery Guide · Incident Response Guide · Ransomware Response and Recovery Guide · DORA Guide

Business Impact Analysis Template