ISO/TS 22317:2021 gives organisations adaptable guidance for establishing and maintaining a formal, documented BIA process; the practitioner challenge is converting that guidance into consistent impact evidence and recovery requirements. The published 2021 second edition is guidance rather than a one-size-fits-all BIA form.
What the specification is for
Build a process appropriate to the organisation’s services, scale, resources and constraints. Define purpose, scope, roles, information sources, analysis method, approval and maintenance before sending questionnaires to business units.
Design the BIA around decisions
| Decision | Evidence needed | Output |
|---|---|---|
| What must be recovered first? | Impact over time and obligations | Prioritised activities/services |
| How quickly? | Threshold at which impact becomes unacceptable | Time objectives/tolerances |
| At what capacity? | Minimum acceptable service and backlog behaviour | Minimum continuity objective |
| With what? | People, technology, facilities, information, suppliers | Resource requirements |
| What must recover first? | Upstream/downstream dependencies | Dependency sequence |
Avoid questionnaire bias
Do not ask owners to choose an RTO before they have analysed consequences. First establish how financial, safety, legal/regulatory, customer, operational and reputational impacts develop across meaningful time intervals. Then derive the recovery requirement and validate feasibility separately. This prevents current technical capability from silently redefining business tolerance.
Calibrate and challenge results
Use cross-functional calibration so similar impact statements receive comparable treatment. Challenge unsupported “critical” classifications, contradictory dependencies and resource estimates that assume normal staffing. Finance, technology, procurement, legal/compliance and service owners should validate the evidence relevant to them.
Maintain the BIA as a living process
Define triggers for reassessment: material service changes, acquisitions, outsourcing, technology replacement, regulatory change, major incidents, exercise findings and dependency changes. Preserve rationale and approvals so a future reviewer can understand why an objective changed instead of seeing only the latest number.
Practitioner review checklist
- Confirm the scope, accountable owner and decision authority are explicit.
Design an analysis model before collecting data
Define the business-unit scope, service hierarchy, impact categories, time bands, rating scales, recovery terminology and approval workflow before launching interviews. Without common definitions, respondents will interpret “critical,” “maximum outage” and “minimum resources” differently, making the final portfolio inconsistent.
Use facilitation to improve evidence quality
A facilitator should challenge statements with follow-up questions. When an owner says that a service must recover in two hours, ask which unacceptable consequence occurs after two hours, what evidence supports it, what manual workaround exists and whether dependent technology can meet the same requirement. The objective is not to negotiate a lower criticality; it is to establish a defendable requirement.
Calibrate across the portfolio
After individual BIAs are complete, review them together. Look for identical services with materially different ratings, shared dependencies with conflicting priorities, extreme objectives unsupported by impact, and workarounds that rely on the same limited resources. Calibration turns individual interviews into an enterprise recovery view.
Trace results into continuity solutions
Each approved recovery requirement should feed a strategy decision. If a critical service requires minimum capacity in four hours, the selected people, workplace, technology and supplier solutions must collectively meet that requirement. Keep the traceability so later exercises can show whether the strategy actually satisfies the BIA.
Version and approval control
Keep the effective BIA result distinct from working notes. Record the approved values, approver, date and rationale for material changes. When a dependency or recovery objective changes, ensure downstream plans and strategies receive the update. This traceability prevents several conflicting versions of the same service requirement from circulating.
Use BIA to establish defensible priorities
A BIA should explain the consequence of disruption over time and convert that evidence into recovery requirements. Start with products and services or other outcomes important to the organization, then identify the activities and dependencies that enable them. Avoid beginning with a spreadsheet of every process and asking owners to choose a priority rating without context. That approach often produces inflated criticality and inconsistent recovery targets.
For each activity, capture the impact progression, the point at which the impact becomes unacceptable, minimum acceptable output, recovery dependencies and any time-specific constraints such as settlement windows, safety obligations, reporting deadlines or peak demand. Distinguish a business tolerance from a technical target: the BIA establishes what the business needs, while recovery architecture and strategy determine what can be delivered and at what cost.
Challenge the analysis before approving it
- Compare similar activities across departments to find inconsistent scoring or duplicated assumptions.
- Check whether upstream and downstream dependencies support the proposed recovery sequence.
- Confirm that resource requirements describe a minimum operating level at defined points in time, not normal staffing copied from an organization chart.
- Separate contractual or regulatory deadlines from internal preferences and document the evidence for each.
- Reconcile BIA requirements with application, supplier, facility and workforce recovery capabilities; unresolved differences should become explicit gaps.
The result should support concrete decisions: which services need continuity strategies, which applications belong in earlier recovery tiers, which suppliers require stronger commitments, and where management must accept or fund a capability gap. A BIA that cannot influence those decisions is probably collecting data rather than producing usable continuity analysis.
Applying ISO/TS 22317 without turning BIA into a form-filling exercise
The practical value of BIA comes from linking disruption consequences to prioritized recovery requirements. Define assessment criteria before interviews so business units are evaluated consistently, then capture the point at which impacts become unacceptable rather than merely asking respondents how quickly they would like recovery.
Cross-process calibration
After interviews, compare similar impact claims across processes. Challenge outliers, duplicate dependencies and recovery objectives that conflict with shared technology or supplier constraints. Calibration reduces the risk that organizational influence, rather than consequence, determines priority.
Traceable output
Approved results should connect impact progression, MTPD or MAO, prioritized activities, RTO/RPO where applicable, minimum resources and dependencies. Preserve reviewer comments and assumptions so later strategy decisions can show how the BIA informed them.
Related BCM.Center resources: Business Impact Analysis (BIA) Guide · Business Impact Analysis Questionnaire Template: Questions, Evidence and Review Rules.
ISO/TS 22317:2021 gives organisations adaptable guidance for establishing and maintaining a formal, documented BIA process; the practitioner challenge is. The public ISO/TS 22317:2021 material is a reference for documented business impact analysis; verify the particular recovery assumptions locally.