How to Define Business Continuity Activities for ISO 22301

The quality of a business continuity programme depends on how the organisation divides work for analysis and recovery. Define activities too broadly and important differences disappear. Define them too narrowly and business impact analysis becomes unmanageable, dependencies are duplicated and people face multiple conflicting plans during disruption.

ISO 22301 uses activities as a practical unit within the business continuity management system. An activity is work performed by or for the organisation that contributes to products and services. The organisation decides the right level of detail for its size, complexity and operating model.

Direct answer: Define activities around coherent outcomes that can be assigned an owner, assessed for impact, mapped to dependencies and recovered through usable arrangements. Start from products and services, follow value delivery across departments, and choose boundaries that preserve cross-functional reality without creating excessive detail.

Do not confuse activities with departments

A department is an organisational structure. A process is a sequence of work. An activity is the practical unit the BCMS uses to understand impact, priority and recovery.

Sometimes the three align. Payroll may sit mainly within one people function and can be managed as one continuity activity. In other cases, a customer onboarding activity crosses sales, compliance, technology, finance and operations. Treating each department separately can hide the end-to-end service and its handoffs.

Use departments as a convenient starting point only when the resulting activity still has a clear outcome, owner, dependencies and recovery approach.

Begin with products and services

List the products and services within the BCMS scope. For each, ask:

• Which customer or stakeholder outcome is delivered?
• What work must happen for that outcome to continue?
• Where does the work start and end?
• Which teams, sites, technologies, information and suppliers contribute?
• Which inputs and outputs connect it to other work?
• Who can approve recovery priority and minimum capacity?

This top-down path reduces the risk of analysing internal tasks that have no clear connection to scope or stakeholder need.

The business impact analysis guide explains how activity definitions feed impact, recovery time and dependency decisions.

Choose the right level of granularity

An activity boundary should be detailed enough to expose different impacts and recovery needs, but broad enough to support coherent ownership and planning.

Split an activity when:

• parts have materially different maximum tolerable disruption or recovery time;
• one part supports a different product, service or obligation;
• dependencies, locations or suppliers differ substantially;
• recovery can be activated independently; or
• one owner cannot make meaningful decisions for the whole boundary.

Merge items when:

• they share the same outcome, owner, priority and recovery approach;
• separating them repeats identical dependencies and actions;
• the parts have no useful independent recovery decision; or
• the detail would overwhelm analysis without changing treatment.

Do not use employee counts as a universal split rule. A two-person regulatory reporting activity can be highly time-critical, while a large activity may share one coherent recovery strategy.

Compare three modelling approaches

Approach	Advantage	Main risk	Best use
Process-based	Preserves end-to-end value and handoffs	Ownership may cross several functions	Mature process organisations and customer journeys
Department-based	Aligns with managers and response teams	Can fragment products and hide interdependence	Smaller or strongly functional organisations
Hybrid	Combines service view with accountable teams	Requires disciplined mapping between views	Complex organisations and shared services

A hybrid model often works best. Define a prioritised end-to-end activity for impact analysis, then assign recovery actions to the departments and service owners that control its resources.

Create an activity register

For each activity, record:

Field	Evidence purpose
Activity ID and name	Stable reference across records
Outcome	Product, service or obligation supported
Scope and boundary	Included work and exclusions
Accountable owner	Approval and recovery authority
Performing teams and locations	Operating footprint
Inputs and outputs	Handoffs and sequence
Information and applications	Data and technology dependency
People and skills	Minimum staffing and specialist knowledge
Facilities and equipment	Physical dependency
Suppliers and utilities	External dependency
Peak periods	Time-sensitive operating conditions
BIA and plan references	Traceability to analysis and response
Review trigger and date	Maintenance evidence

Use stable identifiers so a renamed department does not break the chain between the activity, BIA, risk assessment, strategy, plan, exercise and improvement action.

Map dependencies in both directions

Ask each activity owner what they need and who needs their output. Reconcile the answers. A supplier, identity platform or shared operations team may be rated noncritical by its own owner while supporting several critical activities.

Record at least:

• upstream provider and input;
• downstream consumer and output;
• required timing and minimum capacity;
• alternate source or workaround;
• single points of failure;
• owner responsible for the dependency; and
• evidence that the assumption was confirmed.

The ICT recovery readiness guide shows how business dependencies should connect to technical recovery design.

Run the BIA at the activity level

Use the activity definition as the boundary for assessing impact over time. Identify the point at which disruption becomes unacceptable, minimum service level, recovery time, data need and resource dependencies. Keep impacts distinct from causes; the same activity may be disrupted by many scenarios.

If the BIA produces one recovery time for an activity containing very different work, revisit the boundary. If dozens of near-identical activities produce the same answers and plan, consider consolidation.

Use the free ISO 27001 Risk Score Calculator for a consistent qualitative view of information-security scenarios. Its scores do not replace business impact analysis or ISO 22301 continuity requirements.

Translate activities into usable plans

The activity model should make response simpler. During disruption, a role holder needs one clear set of priorities and actions, even if the activity supports several processes.

Plans should state:

• activation conditions and authority;
• the minimum outcome to maintain;
• dependencies and their fallback arrangements;
• staffing, site and technology needs;
• sequence and coordination points;
• information-security controls during degraded operation;
• communication and escalation; and
• return-to-normal and backlog reconciliation.

The business continuity plan guide explains how to turn requirements into executable arrangements. The plan activation guide addresses triggers and decision records.

Maintain definitions through change

Activity registers become stale when products, outsourcing, technology, locations or organisation structures change. Link reviews to change management rather than relying only on an annual date.

Useful triggers include:

• launch or retirement of a product or service;
• merger, restructuring or location change;
• major supplier or platform change;
• changed legal or contractual obligation;
• exercise evidence that reveals a missing dependency; and
• an incident that crosses an assumed boundary.

Record the previous definition and effective date where changes affect recovery evidence. This preserves audit traceability.

Audit the activity model with vertical and horizontal samples

For a vertical sample, select one critical activity and trace from product or service through BIA, dependencies, strategy, plan, exercise and actions.

For a horizontal sample, select a shared dependency—such as identity, telecom, premises or a supplier—and identify every critical activity that relies on it. Compare required timing with the provider’s proven capability.

Sample audit questions

• Why was this boundary chosen?
• Does the activity have one meaningful outcome and accountable owner?
• Which cross-department handoffs are required for recovery?
• Are upstream and downstream dependency records consistent?
• Would splitting or merging change impact or strategy decisions?
• Did recent organisational changes update the activity model?
• Can the plan be used without reading several conflicting documents?

Judge pass, partial and fail conditions

Pass: Activities trace to scoped products and services, boundaries support meaningful impact and recovery decisions, dependencies are reconciled across owners, and changes flow into analysis, plans and exercises.

Partial: An activity list exists, but it mirrors the organisation chart, cross-functional handoffs are incomplete, or repeated BIA records provide little decision value.

Fail: Activities have no clear outcome or owner, critical shared services are omitted, plan scope conflicts with BIA scope, or restructuring has broken traceability.

A good activity model makes complexity manageable without hiding it. It gives the organisation a stable line from stakeholder outcome to impact, dependency, recovery action and evidence.