Roles and Decision Rights During a Disruptive Incident

Direct answer: A disruptive-incident response needs more than a continuity manager. It needs named authority for incident command, business priorities, technical containment and recovery, safety, legal and privacy decisions, supplier coordination, communications, finance and return to normal. Each critical role also needs a deputy and documented decision limits.

During a serious disruption, people usually know their everyday jobs but may not know who can stop a service, activate an alternate site, notify a regulator, purchase emergency capacity or accept residual risk. Ambiguity creates delay and unsafe workarounds.

An effective structure defines decisions before the event, then adjusts its size to the incident. The organisation does not need a large permanent crisis team, but it does need available authority and competent role holders.

Start with decisions, not job titles

List the decisions a plausible disruption will require. Then assign accountability, authority, evidence and deputies.

Critical decisions can include:

• classify and declare the incident;
• protect life, safety and physical assets;
• isolate systems or stop unsafe processing;
• preserve evidence and control information access;
• activate continuity or disaster-recovery arrangements;
• prioritise activities and scarce resources;
• approve emergency spending or supplier action;
• assess contractual, privacy and regulatory duties;
• communicate internally and externally;
• validate recovered services and data; and
• approve return to normal and closure.

The incident-management guide explains the response lifecycle. The role model should connect to that lifecycle and to continuity procedures.

A proportionate response structure

One person may hold several roles in a small organisation, but accountability should remain visible.

Role	Primary decisions	Evidence expected
Incident lead	Declares response level, coordinates work and sets operational rhythm	Incident record, objectives, decisions and action log
Business-continuity lead	Recommends and coordinates continuity activation	Trigger assessment, plan selection and recovery priorities
Business service owner	Sets acceptable outcome, minimum capacity and validation	BIA approval, priority decision and service acceptance
Technical recovery lead	Contains technical impact and restores services safely	Technical timeline, recovery procedure, test and validation records
Information-security lead	Advises on confidentiality, integrity, availability and threat	Security assessment, evidence preservation and control decisions
Legal/privacy adviser	Assesses obligations, privilege and notification	Decision rationale, deadlines and approved communications
Communication lead	Controls messages, channels, audiences and update rhythm	Approved message log, recipient record and corrections
Supplier coordinator	Maintains provider escalation and evidence	Contact log, commitments, status and contract actions
People/facilities lead	Coordinates workforce, welfare, access and locations	Accountability record, access decisions and alternate-site status
Recovery approver	Accepts service condition and authorises return	Business validation, unresolved risks and approval time

Use role names rather than personal names in the procedure, then maintain a controlled contact record for current primary and deputy holders.

Define authority limits

A role statement should explain what the holder can decide without further approval. Examples include:

• maximum emergency spending;
• authority to isolate a network or stop a service;
• authority to activate alternate operations;
• information classification and disclosure limits;
• customer or public communication approval;
• authority to accept degraded service temporarily; and
• authority to accept unresolved risk at restoration.

Where a decision requires two approvals, define the fallback when one approver is unavailable. Emergency delegation should be time-limited and recorded.

The RACI guide for ISO 27001 can support normal governance, but disruptive response also needs explicit command and escalation authority.

Separate command, advice and execution

Confusion occurs when advisers are treated as decision-makers or technical executors are assumed to own business acceptance.

For example, the security lead may advise that residual attacker access cannot be ruled out. The technical lead may propose restoring a restricted service. The business owner evaluates whether the restricted outcome is usable. The authorised incident or crisis leader chooses the next course within approved authority.

Record dissent and uncertainty when material. A decision log should show facts available at the time, options considered, advice received, decision owner, time and next review point.

Use lifecycle-based handoffs

Roles change as the incident moves from detection to recovery.

Detection and triage

The reporting or monitoring function records the event and transfers ownership to an authorised triage role. The handoff should preserve time, source, affected assets and immediate actions.

Containment and continuity decision

Security and technical roles may act urgently to limit harm. Business and continuity owners assess activity impacts, recovery limits and alternate operating needs. If containment disrupts a priority service, the trade-off should be explicit.

Recovery and validation

Technical teams restore components. Security verifies that required controls and monitoring are active. Data owners assess integrity. Business owners validate end-to-end processing and capacity before acceptance.

Return and improvement

The recovery approver authorises controlled reversion. Owners reconcile temporary records, remove emergency access and transfer improvements into corrective-action governance.

Worked role assignment for a supplier outage

A managed platform supporting customer appointments becomes unavailable. The provider forecasts four hours of disruption but confidence is low.

Decision	Accountable role	Consulted roles	Required record
Move to continuity standby	Continuity lead	Service owner, supplier coordinator, IT	Trigger assessment and review time
Protect affected integrations	Technical lead	Security and application owners	Change and monitoring record
Prioritise high-risk appointments	Service owner	Operations and clinical/safety adviser	Priority criteria and capacity decision
Send customer update	Communication lead under approved authority	Service owner, legal/privacy	Approved message and distribution evidence
Accept restored platform	Service owner	Technical, security, data and supplier leads	Transaction test, security status and acceptance

This prevents the supplier’s “service restored” notice from becoming the organisation’s only acceptance evidence.

Include suppliers and external responders

Cloud providers, managed security services, telecom operators, building management, emergency services and specialist responders may be essential. Document:

• escalation routes and service identifiers;
• available support level and response commitment;
• information that may be shared;
• decision boundaries between parties;
• evidence and status update expectations;
• backup contact channels; and
• exit or substitution options.

The supplier security lifecycle guide explains how to govern due diligence, contracts, monitoring and exit.

Make deputies operational

A name in a contact list does not prove deputy readiness. Deputies need access, authority, current information and practice.

Exercise scenarios with primary leaders deliberately unavailable. Verify that deputies can access plans, join alternate channels, obtain reliable status, approve required actions and document decisions. Rotate participation so the same specialists are not the only demonstrated capability.

Protect response information

Incident records may contain sensitive technical, personal, legal or commercial information. Apply need-to-know access, controlled sharing, reliable time records and retention rules. Define which channel is authoritative and how decisions from calls or messaging platforms enter the formal record.

Emergency access must remain attributable. Shared accounts or informal approvals weaken both security and later assurance. The Annex A control lookup provides practical context for access, incident and continuity controls.

Evidence of implementation and operation

Design evidence includes the role model, authority matrix, contact structure, escalation criteria, supplier responsibilities and communication approval process.

Operating evidence includes training, call tests, exercises, incident timelines, decision logs, approvals, deputy use, service validation and completed improvements.

NIST SP 800-34 Rev. 1 discusses contingency teams and responsibilities during plan activation. It is guidance for US federal information systems, not an ISO requirement, but its role-oriented planning concepts can inform an organisation’s approach.

Audit questions and sampling

Ask role holders, not only the continuity manager:

• What decision are you authorised to make?
• Who acts when you are unavailable?
• Where do you obtain trusted incident status?
• Which evidence must exist before you approve recovery?
• How are external messages authorised?
• What happens when a supplier or primary channel is unreachable?

A pass is supported when decisions have accountable roles, authority is explicit, deputies are functional and exercises show effective handoffs.

A partial result may exist when roles are named but authority, deputies or business validation are weak.

A fail is likely when every decision depends on one manager, technical restoration is accepted without business ownership or communication authority is improvised during the event.

For sampling, choose a high-impact service, an outsourced service and one scenario that removes a primary decision-maker. Trace the results into improvement actions and closure evidence.

Frequently asked questions

Must the BCM manager lead every disruptive incident?

No. Leadership should fit the incident and governance model. The continuity manager may coordinate the process while another authorised leader commands the response.

Can one person hold several roles?

Yes, when conflicts, workload and availability are considered. The procedure should still distinguish the decisions and identify deputy coverage.

Who approves return to normal?

An accountable business or service owner should normally accept the operational outcome, supported by technical, security, data and continuity evidence.