Recovery priorities: when every department is critical, what should you recover first?
How to compare impacts, dependencies and minimum capacity to decide what to resume first in business continuity.
⏱️ Estimated reading time: 7 minutes
In business continuity, recovery priorities are defined by comparing when the impacts of a disruption to each activity become unacceptable (MTPD) and identifying dependencies between activities. Recover first what is needed to prevent the impacts that become unacceptable earliest, including essential supporting activities. Recovery time objectives (RTOs) must provide for activities to resume at the defined minimum capacity before their respective MTPDs.
Imagine a business continuity planning meeting: the sales department believes it cannot stop, operations argue that they must recover immediately, and finance raises concerns about incoming and outgoing payments. Each has legitimate reasons. However, when resources do not allow everything to be recovered simultaneously, the question becomes more specific:
Recovery priorities are defined by activity
Labelling a department as “critical” does not settle the operational decision. Very different needs coexist within the same department: processing a payment that is due immediately does not have the same urgency as preparing a monthly report.
ISO 22301 therefore works at the level of prioritised activities, rather than departments. Instead of asking “is the finance department critical?”, the question should be: which financial activity cannot remain disrupted, for how long, and why?
Recovering one activity first does not mean the others matter less: it means that delaying its resumption leads to unacceptable consequences sooner or compromises the recovery of other activities.
How should recovery priorities be defined in the BIA?
The business impact analysis (BIA) required by ISO 22301 (Clause 8.2.2) should compare consequences using common criteria. Recovery priorities arise from how impacts develop over time, applicable obligations and dependencies between activities — not from each manager’s individual perception. The BIA guidance in ISO/TS 22317:2021 addresses these very elements in more detail.
Three questions make the comparison useful:
• What happens if this activity remains disrupted? Identify specific consequences for the organisation, customers and other interested parties.
• When do those consequences become intolerable? Distinguish an initial inconvenience from a consequence that exceeds the defined limits.
• What needs to be available for the activity to operate? Consider people, information, technology, premises and other activities.
Terms such as “substantial financial loss”, “reputational impact” or “breach of contract” are insufficient for comparing needs. They must be linked to identifiable situations and commitments and show how the consequences increase over time.
Example: recovery priorities with limited resources
Consider a company that provides technical support to business customers. Its administrative premises become unavailable. Once people’s safety has been ensured, the team moves to an alternative location.
Initially, only two workstations are available, with authorised access to the necessary information. Three activities need these resources.
The following scenario and time horizons are hypothetical and serve only to illustrate how to justify recovery priorities.
On smaller screens, scroll horizontally to view the table.
| Activity | How impacts develop in this scenario | Initial capacity required |
|---|---|---|
| Coordinate urgent interventions | After two hours without coordination, extended downtime at priority customers exceeds the limit considered acceptable. | Know which interventions are in progress, assign technicians and monitor urgent cases. |
| Receive and classify support requests | After four hours without processing, the backlog of unclassified requests becomes unacceptable. Some may require immediate intervention. | Receive requests, identify urgent ones and forward them for coordination, keeping a record. |
| Invoice completed services | The disruption becomes unacceptable after two working days. In this example, no applicable deadline falls before that limit. | On resumption, issue the invoices needed to meet the commitments considered in the analysis. Until then, preserve records of the services provided. |
MTPD and RTO in defining recovery priorities
The time horizons in the table correspond to the maximum tolerable period of disruption (MTPD): the point at which impacts become unacceptable. The recovery time objective (RTO) is the target time, measured from the onset of the disruption, for resuming the activity at the defined minimum capacity. It must be shorter than the MTPD, with an appropriate margin; it is not the deadline for starting recovery work. The practical guide to ISO 22301 explores these concepts in more detail.
What should be recovered first in this example?
Coordinating urgent interventions has the shortest MTPD. However, recovering it in isolation would leave a dependency unresolved: how would new urgent requests be identified and forwarded? The four-hour limit given for the accumulation of requests does not mean that urgent requests can wait to be triaged, because triage is needed to support coordination.
To put these recovery priorities into practice, a justified approach would be to allocate one workstation to coordination and the other to receiving and classifying requests, initially limiting request handling to what is needed to support the priority response. Invoicing would be deferred to a later stage, with an RTO to be set below the MTPD of two working days, allowing an appropriate margin. Meanwhile, records of services provided would need to be preserved.
The decision would not be “operations first, customer service next and finance last”. It would be more precise:
Recovery priorities do not impose a rigid sequence. Putting them into practice may require parallel actions, partial capacity and shared resources. An activity whose direct impact emerges later may need to operate from the outset precisely because it supports a more urgent one.
Recovery priorities: minimum capacity and full recovery
Customer service does not need to resume every task immediately: responding to sales enquiries does not have the same priority as identifying a case that is keeping a customer’s operations at a standstill.
The minimum business continuity objective (MBCO) should reflect the outcome that needs to be assured. It is not enough to state “two people available” or “one system running”: resources need to be linked to the intended level of service. In the example, this would mean receiving and classifying all urgent requests during the period, forwarding them within the defined time and retaining sufficient information to monitor each case.
Full recovery would follow later. This distinction allows the resources needed to implement recovery priorities to be discussed: what is needed to sustain the priority service now, and what can be restored progressively?
What if resources are insufficient to meet the RTOs?
Assume that only one alternative workstation is available and there is no approved way of receiving and forwarding new requests while coordination work is under way. The priority has been identified, but the solution is insufficient.
Extending the RTOs until they appear compatible with existing resources does not change the impacts caused by the disruption. The gap must be made explicit — what capacity is missing, what consequences may result and what decision is needed — and alternatives assessed: an additional prepared workstation, an alternative channel for receiving requests or a temporary working arrangement that supports both functions.
Documenting recovery priorities does not, in itself, create the capacity to implement them. This gap shows management where investment is needed.
Who should decide between competing recovery priorities?
Those responsible for activities understand their own needs, but consolidation requires a cross-functional perspective. ISO/TS 22317:2021 recommends that consolidated BIA results be submitted to top management for approval. The implementation of the priorities should follow the responsibilities and levels of authority defined within the organisation.
In the example, the decision on recovery priorities would make clear why the two workstations are allocated to urgent response, which work is deferred, who monitors the impacts and under what conditions the decision will be reviewed.
The management question changes from “which department is the most important?” to:
Frequently asked questions
What is the difference between RTO and MTPD?
The MTPD is the point at which the impacts of a disruption become unacceptable. The RTO is the target time for resuming the activity at the defined minimum capacity and must be shorter than the MTPD, with an appropriate margin.
Should a department considered critical be recovered as a whole?
No. Priorities are defined by activity, based on the impacts, obligations and dependencies identified in the BIA. Activities within the same department may have very different RTOs.
Who approves recovery priorities?
ISO/TS 22317:2021 recommends submitting the consolidated BIA results to top management for approval. Operational implementation follows the responsibilities and levels of authority defined within the organisation.
Developing the skills to implement business continuity
Defining recovery priorities and translating impacts and dependencies into strategies and plans are central tasks in implementing a Business Continuity Management System. Behaviour’s ISO 22301 Lead Implementer course develops these skills by bringing together the BIA, continuity strategies, resources, plans and system evaluation. The next course takes place from 16 to 19 November 2026, delivered Live Online.
Explore the ISO 22301 Lead Implementer course programme and the options for individual or team participation.
Behaviour Group® – Dedicated to Best Practice.
Would you like to develop your business continuity skills?
Explore the ISO 22301 Lead Implementer course and the options for individual participants and teams.
Date: 2 November 2026
Author: Behaviour Group
Copying or reproducing this article is not permitted.