Search every question across sub-FAQs

Under ISO 22301, the BIA is the process that turns business disruption into concrete continuity priorities and requirements. It should start from the BCMS scope and the products or services the organization has decided to protect.

The output should tell a visitor, auditor, or internal owner which activities are prioritized, why they matter, when disruption becomes unacceptable, what minimum capacity is needed, and which resources and dependencies must be available for recovery. It is not limited to IT: activities may depend on people, facilities, information, data, equipment, logistics, finance, partners, and suppliers.

The BIA should assess impacts over time and identify the point where not resuming an activity becomes unacceptable. That point is commonly expressed as the maximum tolerable period of disruption, or MTPD.

The recovery time objective, or RTO, should sit inside that maximum tolerable period and state when the disrupted activity must resume at a defined minimum acceptable capacity. ISO 22301:2019 does not define or explicitly require RPO. For information- and ICT-dependent activities, an organization can add an RPO or equivalent data-loss tolerance when missing records or transactions would affect continuity.

A BIA is weak if it only ranks activities. It should also identify the resources needed to support prioritized activities and the dependencies and interdependencies that affect recovery.

The useful version names the people, facilities, information, data, technology, suppliers, partners, utilities, records, and decision forums needed to continue or recover the activity within the agreed time frame and capacity.

The BIA and risk assessment feed the selection of business continuity strategies and solutions. ISO 22301 requires selected strategies and solutions to meet the identified timeframes and agreed capacity. If current capability cannot do so, record the gap and change the solution, resources, or justified continuity requirement; risk acceptance alone does not establish conformity with the strategy-selection requirement.

Business continuity plans, recovery procedures, exercise scenarios, and post-exercise actions should all be traceable back to BIA outputs. Otherwise the organization may test convenient scenarios while leaving the most important recovery assumptions unproven. For example, if order fulfilment must resume within eight hours at 40 percent capacity, the selected solution should name the minimum staff, system access, inventory data, carrier dependency, and manual fallback needed to meet that result; the exercise should test those same conditions.

Good BIA evidence shows both the analysis and the operating process around it. Keep the approved BIA, criteria, assumptions, owner approvals, dependency records, resource decisions, strategy links, exercise results, audit findings, corrective actions, and management-review inputs together.

Review the BIA at planned intervals and when significant changes affect the organization or its context. Practical triggers include a new product, site, supplier, system, legal obligation, customer commitment, incident lesson, exercise failure, major staffing model change, or recovery target change.

Certification evidence includes documented information that ISO 22301 explicitly requires the organization to retain or maintain, plus other records needed to show that BCMS processes were carried out as planned. A policy folder alone cannot show operation: reviewers need traceability across scope, objectives, BIA, risk assessment, strategies, plans, exercises, evaluation, internal audit, management review, and corrective action.

Start with the BCMS boundary. The scope record must identify the included parts of the organization and products and services, and it must document and explain exclusions. Supporting dependency, location, outsourced-process, and interested-party records help show how that scope was determined and whether exclusions affect the organization's continuity ability or responsibility.

The core operating evidence should show how the organization determined continuity priorities and selected recovery arrangements. That means business impact analysis records, risk assessment records, continuity requirements, strategy and solution decisions, resource requirements, plans, procedures, warning and communication steps, response structure, and recovery processes.

The BIA and risk assessment should be fresh enough to represent the current organization. ISO 22301 expects these processes to be reviewed at planned intervals and when significant changes occur, so the evidence pack should show the last review, change trigger, approval, and resulting updates.

Exercises and tests show whether strategies, solutions, plans, communications, teams, and suppliers can perform over time. Keep the scenario, aims, objectives, participants, assumptions, results, recommendations, action owners, due dates, and closure proof together with the plan or capability being tested.

Internal audit and management review close the evidence loop. Audit records should show criteria, scope, auditor independence, findings, reported results, and follow-up. Management review records should show inputs, decisions, scope changes, BIA or risk updates, plan updates, resource decisions, and improvement opportunities.

Keep an evidence map instead of a last-minute audit folder. Each evidence item should have a record owner, storage location, review frequency, change trigger, retention rule, and status. When the scope, product, service, site, supplier, system, incident pattern, legal requirement, or continuity objective changes, update the affected evidence and show what changed.

Corrective-action records show whether the organization reacts to nonconformities, evaluates their causes and possible recurrence, implements needed action, reviews effectiveness, changes the BCMS where necessary, and retains evidence of the nonconformity, subsequent action, and results.

Treat the review as a top-management decision meeting for the BCMS. The agenda should start with open actions from the previous review, then move through changes in internal and external context, interested-party feedback, BCMS performance, audit results, nonconformities, corrective actions, and monitoring results.

The review should also use business impact analysis and risk-assessment information, evaluation of business continuity documentation and capabilities, lessons from near misses and disruptions, and opportunities for continual improvement. If those inputs are missing, the review record will look complete but will not prove that leadership reviewed the real continuity system.

Use a short decision log that separates decisions from the meeting transcript. Each decision should say what will change, why it matters to continuity, who owns it, when it is due, and which evidence will prove completion.

Typical outputs include changes to the BCMS scope, updates to the BIA or risk assessment, revisions to continuity strategies and solutions, updates to business continuity plans, modifications to procedures and controls, and decisions about how control effectiveness will be measured.

Retain the management-review record with enough detail for a later auditor, customer reviewer, or executive sponsor to reconstruct the decision. At minimum, keep the agenda, attendance or approval record, input pack, decision log, assigned actions, communication record, and follow-up status.

Good evidence links back to live BCMS records: exercise and test reports, post-incident reports, internal audit results, monitoring and measurement data, nonconformity and corrective-action records, BIA and risk-assessment updates, documentation capability reviews, and prior management-review actions.

ISO 22301 requires management review at planned intervals but does not prescribe an annual or other fixed frequency. Set the interval so top management receives the required inputs and can act before unresolved issues undermine the BCMS; do not let the certification-audit calendar determine the only review date.

A material change, disruption, near miss, serious exercise gap, systemic audit finding, or blocked continuity objective can justify an additional full or targeted leadership review. This event-based review is a practical governance choice, while the explicit ISO 22301 requirement is review at planned intervals.

MTPD is the name ISO 22301 permits for the timeframe within which the impacts of not resuming an activity would become unacceptable. This is more precise than treating MTPD as elapsed outage time alone: the decision depends on impact types, impact criteria, the affected activity, and how impacts develop over time.

A useful MTPD record names the activity, the product or service it supports, the impact criteria used, the point where impact becomes unacceptable, and the person or forum that accepted that tolerance. Without that context, the number is hard to defend during an audit, supplier review, or real disruption.

MTPD is the unacceptable-impact boundary. RTO is the prioritized timeframe for resuming the disrupted activity at a specified minimum acceptable capacity, and it should sit inside the MTPD. ISO 22301:2019 does not define or explicitly require RPO; an organization can use RPO as a supporting data-loss or transaction-rework target where information recovery affects continuity.

If an activity has a 48-hour MTPD, setting a 48-hour RTO leaves no margin for activation delays, failed recovery steps, supplier dependencies, or management escalation. The BIA should therefore show why the selected RTO and resource strategy can recover the activity before the MTPD is reached.