Did you last test your Business Continuity and Incident Response capability, or did you review a document and assume it would hold under pressure?
A material proportion of organisations that suffer a major disruption do not recover. The failure is rarely the event itself. It is the absence of a tested capability to absorb and respond to it.
BCP and Incident Response plans are often present. They are less often exercised in a way that exposes whether they work.
If your answer is not recent, evidenced, and repeatable, you do not have assurance. You have documentation.
This article addresses the gap between the two. It focuses on where plans fail in practice, what testing actually proves, and how to establish a capability that stands up under scrutiny.
Understanding the Critical Difference re: BCP and Incident Response
BCP and Incident Response are structurally different. Treating them as interchangeable creates exposure.
Business Continuity Plan (BCP): Maintaining operational continuity
A BCP defines how the organisation continues to operate when disruption occurs.
Scope: Organisation-wide. Operations, people, facilities, suppliers, and supporting technology.
Objective: Maintain or restore critical services within defined tolerances.
Disruption profile: Physical, operational, and systemic events. Flood, power loss, supply chain failure, or a cyber event that impairs delivery.
Core components: Business Impact Analysis, recovery strategies, communication structure, defined ownership.
A BCP is not an IT artefact. It is an operating model under stress.
Incident Response (IR): Managing the event
An Incident Response plan addresses the event itself.
Scope: Typically technology, data, and security control failure.
Objective: Detect, contain, eradicate, and recover with controlled impact.
Incident profile: Ransomware, breach, denial of service, insider activity.
Core components: Detection, triage, containment, recovery, post-incident review.
IR is execution under time pressure. It is where decisions are made with incomplete information and immediate consequence.
The relationship
BCP answers: can the organisation continue to operate?
IR answers: can the organisation control the event causing disruption?
If these are not aligned, recovery becomes fragmented. One part of the organisation stabilises while another continues to degrade.
Why Testing Is Non-Negotiable
An untested plan does not fail gracefully. It fails at the point of reliance.
Testing does not validate documentation. It validates behaviour, decision-making, and system response under constraint.
Some typical failure modes are detailed below.
- Outdated structure
Contact points, vendors, and systems drift. Plans do not, provided they are kept up to date. - Assumed capability
Recovery times and resource availability are estimated, not proven. - Unclear ownership
Roles exist on paper. Under pressure, decisions stall or duplicate. - Technical fragility
Backups exist but are not recoverable within required timeframes, or systems restore, but dependencies are missing. - Communication failure
Channels are undefined or conflict. Internal and external messaging diverges. - Regulatory exposure
Testing is often an explicit requirement. Evidence is expected, not implied. - Financial consequence
Recovery time expands. Revenue impact follows. In some cases, viability is lost.
Testing is where these issues surface early enough to correct.
Types of BCP and IR Plan Tests
Testing should reflect the level of assurance required, not a compliance cycle.
Tabletop Exercises
Structured discussion against a defined scenario.
Value: Clarifies roles, exposes procedural gaps, tests decision flow.
Limitation: Does not validate execution capability.
Use: Frequent. Establishes baseline alignment.
Simulation Exercises
Controlled execution of specific components.
Value: Validates technical processes and coordination.
Limitation: Partial view of the overall response.
Use: Targeted assurance of critical functions.
Full-Scale Exercises
End-to-end scenario across multiple teams.
Value: Closest representation of real conditions. Tests coordination, escalation, and timing.
Limitation: Resource-intensive. Requires disciplined planning.
Use: Periodic validation where impact justifies the investment.
Component Testing
Focused validation of individual elements.
Value: Confirms critical dependencies operate as expected.
Limitation: Does not test integration.
Use: Frequent validation of key infrastructure.
How Often Should You Test?
Frequency is a function of exposure and change.
A baseline position:
- Tabletop: quarterly or semi-annual
- Simulation: annual for critical capabilities
- Full-scale: every one to three years
- Component testing: aligned to criticality
More important than cadence is trigger-based testing:
- Material system change
- Organisational restructuring
- Acquisition or integration
- Post-incident review
If the operating environment changes, the plan is no longer validated.
Building a Testing Capability
Testing is not a one-off exercise. It is an operating discipline.
Define what success looks like
Be explicit. Are you validating recovery time, decision ownership, or communication flow? Each requires different evidence.
Build scenarios from actual risk
Generic scenarios produce generic outcomes. Use your threat landscape, not a template.
Assign decision ownership
Roles must be clear before the exercise begins. Ambiguity during the test invalidates the outcome.
Execute and observe
Document decisions, delays, and deviations. These are the signal.
Conduct a structured debrief
What failed is more valuable than what worked. Capture it without dilution.
Translate findings into change
Assign ownership and deadlines. If findings are not implemented, testing becomes theatre.
Report at the right level
Senior stakeholders require clarity on exposure and remediation. Not narrative.
Common Barriers
The stated barriers are familiar. The underlying issue is prioritisation.
"We do not have time"
You will spend more time managing failure than testing for it.
"We cannot disrupt operations"
Unplanned disruption is materially worse.
"We meet the requirement"
Compliance does not equal capability.
"The scenario is unlikely"
Testing is not prediction. It is validation of response.
Embedding Testing Into the Organisation
Testing becomes effective when it is treated as part of how the organisation operates.
Leadership involvement
If leadership is not engaged, decision-making will not reflect reality.
Cross-functional participation
Incidents do not respect organisational boundaries. Neither should testing.
Continuous improvement
Every exercise should change the plan, the training, or the investment profile.
Training alignment
Testing is where training is validated. Without it, training remains theoretical.
BCP/IR Test Checklist Template
Test Name: _________________________
Date: _________________________
Scenario: _________________________
Objectives: _________________________
Participants: _________________________
Facilitator: _________________________
Phase 1: Planning & Preparation
[ ] Objectives defined[ ] Scenario aligned to risk profile
[ ] Participants and roles assigned
[ ] Test plan and timeline agreed
[ ] Resources confirmed
[ ] Test communications defined
[ ] Pre-brief completed
Phase 2: Execution
[ ] Test initiated as planned[ ] Scenario progression managed
[ ] Actions and decisions logged
[ ] Communication channels exercised
[ ] Critical decision points captured
[ ] Technical steps executed or simulated
[ ] Timings recorded
[ ] Test closed in line with plan
Phase 3: Evaluation & Follow-Up
[ ] Debrief completed[ ] Feedback collected
[ ] Gaps and failures identified
[ ] Technical issues documented
[ ] Communication effectiveness assessed
[ ] Report produced
[ ] Actions assigned with ownership
[ ] Actions tracked to completion
[ ] Plans updated and reissued
[ ] Findings reported to leadership
Case Study: Failure of Assumption
A software organisation maintained BCP and IR documentation that had not been exercised in several years.
A phishing attack led to widespread encryption of critical systems.
The response exposed structural weakness:
- Key contacts were no longer in role
- Backup recovery exceeded defined tolerances
- Communication fragmented across teams
- Continuity planning assumed physical relocation, not system isolation
The organisation recovered, but at material cost.
Testing that should have exposed these issues occurred after the event, not before.
The outcome was a full rebuild of the capability, including defined ownership, regular testing, and revised recovery strategies.
The incident did not create the problem. It revealed it.
Conclusion: Capability, Not Documentation
Resilience is not declared. It is demonstrated.
BCP and Incident Response plans are only credible when they have been exercised under conditions that resemble reality.
The question is not whether you have a plan.
It is whether you can evidence that it works.
If you cannot, you are operating on assumption. And assumption does not hold under analysis.
